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

Kyle Moffett
2006-06-10T19:11:29Z

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