Messages in this thread | | | Date | Thu, 27 Jul 2006 19:28:52 +0200 | From | Matthias Andree <> | Subject | Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion |
| |
On Thu, 27 Jul 2006, Grzegorz Kulewski wrote:
> Sorry for my stupid question, but could you tell me why starting to make > incompatible changes to reiserfs3 now (when reiserfs3 "technology" is > rather old) and making reiserfs3 unstable (again), possibly for several > months or even years is better than fixing big issues with reiser4 (if > there are any really big left) merging it and trying to stabilize it? > > For end user both ways will result in mkfs so...
ext2fs and ext3fs, without "plugins", added dir_index as a compatible upgrade, with an e2fsck option (that implies optional) to build indices for directories without them.
ext3fs is a compatible upgrade from ext2fs, it's as simple as unmount, tune2fs -j, mount.
reiserfs 3.6 could deal with 3.5 file systems, and "mount -o conv" with a 3.6 driver would convert a 3.5 file system to 3.6 level (ISTR it had to do with large file support and perhaps NFS exportability, but don't quote me on that).
I wonder what makes the hash overflow issue so complicated (other than differing business plans, that is) that upgrading in place isn't possible. Changes introduce instability, but namesys were proud of their regression testing - so how sustainable is their internal test suite?
Instead, we're told reiser4 would fix this (quite likely) and we should wait until it's ready (OK, we shouldn't be using experimental stuff for production but rather for /tmp, but the file system will take many months to mature after integration) and it will be "mkfs" time - so reiser4 better be mature before we go that way if there's no way back short of "amrecover", "restore" or "tar -x".
Smashing out most of the Cc:s in order not to bore people.
-- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |