| |||||||||||||
Get your facts straightGet your facts straightPosted Jan 26, 2012 8:27 UTC (Thu) by khim (subscriber, #9252)In reply to: XFS2? by sandeen Parent article: XFS: the filesystem of the future? Well, original extfs was eventually deprecated and we had no way to deprecate ext2 and/or ext3 till ext4 was mature enough. In fact ext2/ext3 switch shows perfectly why such changes are better to do that way: when you introduce disk format change you usually do that to provide some new features and if people don't need these features they can continue to use old format and old, stable, codebase.
(Log in to post comments)
Get your facts straight Posted Jan 27, 2012 1:07 UTC (Fri) by dgc (subscriber, #6611) [Link]
> In fact ext2/ext3 switch shows perfectly why such changes are better
> to do that way: when you introduce disk format change you usually do > that to provide some new features and if people don't need these > features they can continue to use old format and old, stable, codebase.
Actually, the ext2/3/4 splits show exactly why this model doesn't work. Instead of having a single code base to maintain, you have independent code bases that have to be maintained and fixes ported across all trees. What has really happened is that the "old stable" code bases have become "old stale" code bases as ext4 has moved on.
IOWs, history has already shown that we (developers) are poor at pushing fixes made in the ext4 code base back to the ext3 and ext2 code bases,and that's often because the person that made the fix is completely unaware that the problem also exists in ext2/3. There's a reason that the "use ext4 for ext2/3" config option exists - so that one code base can be used to support all three different filesystem types.
That's a big reason for not forking or renaming XFS just for changing 1% of the code base - ongoing maintenance is far simpler and less burdensome when only one code base is used for all different versions of the filesystem....
Dave.
|
|||||||||||||