On Mar 17, 2006 17:26 -0500, Stephen C. Tweedie wrote: > I reckon they are safe enough for general use. The only question mark > in my mind is over the change in behaviour for people who dual-boot or > swap data between newer and older distros. Well, both DIR_INDEX and RESIZE_INODE are COMPAT features, so if they are dual booting it shouldn't matter a bit. FC3/FC4/RHEL4 have all been using RESIZE_INODE and it is very unlikely that it would introduce a bug. The only thing I can imagine it causing problems with is if the e2fsprogs are old, but even then it isn't fatal as the filesystem is still writable and an updated e2fsck can be installed if needed. > One way around that that I've been wondering about would be to wait > until we have accumulated enough new features (extent maps/64-bit, > increase the default inode size etc.) and give the new feature set its > own explicit flag in mke2fs. IMHO, "bundling" changes like this is counter productive. We've had DIR_INDEX and RESIZE_INODE around for a long time already, and no point in lumping them in with code that is much less-well tested or supported (e.g. only 2.6.something kernels can even mount large inodes, which is a far cry from being read-write compatible). Also, if there ends up being a problem there is a lot more code to look at for changes. I'm more a fan of smaller incremental changes. > It might be something we could call ext4 (ie. enable it if mke2fs is > called as "mke4fs"); we might just add a separate flag. Whatever way > we chose, it would want to be something that would stand out as an > obviously non-backwards-compatible formatting option. Interesting. I thought we were against calling new feature sets ext(n+1), but that would be one way of doing it. I'm also not sure why you would consider these two features as non-backwards-compatible format options? For sure, they would only be enabled in conjunction with "-j", since ext2 doesn't support them. At worst they will be ignored by older kernels. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
