On Fri, Jun 09, 2006 at 04:00:44PM -0400, Jeff Garzik wrote: > 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." If is very much a matter of taste, why are you trying to dictate to the ext2 developers how they choose to do things? As long as it works, and we haven't screwed up yet, I'd argue this is falls into the category of letting each subsystem decide how they best work. The way DaveM and the networking team works is quite different from how the SCSI developers work or the XFS team work --- it's not a one-size-fits-all sort of thing. And I'd also dispute with your "weren't really suited for the original ext2-style design" comment. Ext2/3 was always designed to be extensible from the start, and we've successfully added features quite successfully for quite a while. > 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... I don't think it will be another decade, but yes, regardless of whether we do a code fork or not, it will take time. Basically, you and the ext2 developers have a disagreement about whether or not a code fork will actually move the process along more quickly or not. Either way, we will be releasing early and often, so people can test it out and comment on it. Releasing patches to LKML is just the first step in this process. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
