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

[Linus Torvalds]

On Sat, 10 Jun 2006, Kyle Moffett wrote:
> 
> Why not: "extX_ops.do_something_useful();", then have fs/ext/ext{2,3,4}_ops.c

I think that kind of setup is hugely preferable to conditionals in the 
code, if only because it tends to force people to do the abstractions 
right, and make the code sequences independent.

I just don't think it's necessarily very realistic - it's _hard_ to 
refactor code well. It also doesn't buy you hardly anything at all, since 
the people who are interested in ext2 are usually not very interested in 
sharing code with ext3. The filesystems simply aren't that similar, apart 
from the layout. 

ext2 is half the size of ext3, and that's ignoring JBD entirely.

That constant growth, btw, is one reason why splitting off legacy 
filesystems is often a good idea. What do you want to bet that the 2000+ 
line difference RIGHT NOW in ext3/ext4 will grow in the future? Splitting 
things off means that people who don't care about the new features can 
just stay with a stable base and also avoid the bloat. Exactly the way you 
can stay with ext2 on an old machine, and avoid the bloat of ext3.

There's also nothign that says that legacy filesystems cannot be 
simplified. For example, it's perfectly realistic to say that ext3 (as a 
legacy filesystem) doesn't support resizing, and simply ripping that part 
out of it. The people who don't want the bloat will be happy. The people 
who want the feature can move to ext4.

See? Splitting development is what allows you to make choices that you 
simply otherwise don't _have_. 

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/