Messages in this thread | | | Date | Fri, 09 Jun 2006 16:00:44 -0400 | From | Jeff Garzik <> | Subject | Re: [Ext2-devel] [RFC 0/13] extents and 48bit ext3 |
| |
Gerrit Huizenga wrote: > On Fri, 09 Jun 2006 14:55:56 EDT, Jeff Garzik wrote: >> Because it's called backwards compat, when it isn't? >> Because it is very difficult to find out which set of kernels you are >> locked out of? >> Because the filesystem upgrade is stealthy, occurring as it does on the >> first data write? > > Actually, the *only* point being contended here is running older > kernels on some newer filesystems (created originally with a newer > kernel), right? > > Or do you have examples of where current kernels could not deal > with an ext3 feature at some point in time? > > I would argue that 0.001% of all Linux *users* actually worry about > this - most of them are right here on the development mailing list. > So, that group is more vocal, for sure. But, if it works for 99.99+% > users, aren't we still on the good path, from the point of view of > those people who actually *use* Linux the most?
The overall objection is to treating ext3 as a highly mutable, one-size-fits-all filesystem.
Maybe there is value in moving some reiser4 concepts -- a set of metadata+algorithm plugins -- to the VFS level. I dunno.
But for ext3 specifically, it seems like bolting on extents, 48bit, delayed allocation, and other new features weren't really suited for the original ext2-style design. Outside of the support (and marketing, because that's all version numbers are in the end) issues already mentioned, I think it falls into the nebulous realm of "taste."
Rather than taking another decade to slowly fix ext2 design decisions, why not move the process along a bit more rapidly? Release early, release often...
Jeff
- 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/
| |