Re: [RFC 0/13] extents and 48bit ext3

[Kyle Moffett <mrmacman_g4@mac.com>]

On Jun 9, 2006, at 11:25:31, Jeff Garzik wrote:
> Overall, I'm surprised that ext3 developers don't see any of the  
> problems related to progressive, stealth filesystem upgrades.
>
> Users are never given a clear indication of when their metadata is  
> being upgraded, there is no clear "line of demarcation" they cross,  
> when they start using extents.
>
> Since there is no user-visible fs upgrade event, users do not have  
> a clear picture of what features are being used -- which means they  
> are kept in the dark about which kernels are OK to use on their data.
>
> Do you guys honestly expect users to keep track of which kernels  
> added specific ext3 features?
>
> This is why other enterprise filesystems have clear "fs version 1",  
> "fs version 2" points across which a user migrates.  ext3's feature- 
> flags approach just means that there are a million combinations of  
> potential old-and-new features, in-tree and third party, all of  
> which must be supported.

One possible solution to the version-confusion that would avoid  
duplicating features would be to merge the fs/ext{2,3} to fs/ext,  
then make fs/ext register itself as a filesystem under "ext2",  
"ext3", and "ext4".  Then have each name imply a specific set of  
features and compatibility.  That would allow the same performance  
optimizations to affect all 3 even as you make metadata changes in  
the latest version.  I've heard quite some griping about the amount  
of duplicated code between ext2 and ext3; why cause those problems  
again with an "ext4"?  There would probably be some fs/ext/ext{2,3,4} 
_foo.c files that could be compiled in or out depending on configured  
FS support, but I would guess that would make it easier on users and  
developers alike.

Cheers,
Kyle Moffett

-
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/