New tricks for XFS

Posted Feb 22, 2018 20:50 UTC (Thu) by clump (subscriber, #27801)
In reply to: New tricks for XFS by dgc
Parent article: New tricks for XFS

Forgive me if this has been covered. Would creating "XFS2" with perhaps incompatible changes make some of your work easier than modifying the exiting XFS codebase?

New tricks for XFS

Posted Feb 23, 2018 17:05 UTC (Fri) by wazoox (subscriber, #69624) [Link] (5 responses)

There have already been incompatible changes in XFS in the past, quite recently in fact with the addition of metadata checksumming. As long as there are available bit flags to warn of new incompatible features, there is no reason to create such a radical change.

New tricks for XFS

Posted Feb 23, 2018 19:45 UTC (Fri) by clump (subscriber, #27801) [Link] (4 responses)

If you create a new version, you're free to add features like shrinking, subvolumes, etc, without a hodgepodge of arcane mount options and compatibility hacks. Users averse to change could stay on the original XFS. Witness the migration from ext3 to ext4, the latter of which happened to implement features found in XFS.

I also wish there was something akin to an ext5 with an upstream COW implementation.

New tricks for XFS

Posted Feb 23, 2018 21:15 UTC (Fri) by wazoox (subscriber, #69624) [Link]

Well, different filesystems with different philosophies. ext2/3/4 touts compatibility, XFS touts performance. For many years XFS has graduallly added incompatible features (but with options to make compatible filesystems in xfsprogs).

New tricks for XFS

Posted Feb 23, 2018 21:23 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

The way this is done with XFS is that unlike ext4, old filesystems are rarely dynamically upgradable to add new features: to gain reflinks or the reverse-mapping btree you must re-mkfs, and until the feature is declared stable (4.15 for those features) it gets a warning at mount time and requires non-default mkfs options at mkfs time. After that, the new feature becomes the default.

So old filesystems mostly continue to use older codepaths, or aspects of newer codepaths which are heavily tested by virtue of the weight of existing filesystems out there. Only people willing to take the significant plunge of re-mkfsing are affected by the potential bug load (and, obviously, don't even do this with test filesystems on important machines until you're confident it won't oops :) ).

(The unusual thing about this set of features is that it doesn't seem to need new xfs features at all: any fs with the existing reflink and rmapbt features can take advantage of it! That's *very* impressive to me.)

New tricks for XFS

Posted Feb 23, 2018 22:01 UTC (Fri) by dgc (subscriber, #6611) [Link] (1 responses)

> (The unusual thing about this set of features is that it doesn't seem to need new xfs features
> at all: any fs with the existing reflink and rmapbt features can take advantage of it! That's
> *very* impressive to me.)

No, that's not the case. I think I showed the list of experimental features that the demo used in the talk. Sure, reflink and rmapbt are no longer experimental (as of 4.16-rc1), but I added a new "thinspace" feature for thin provisioning awareness and another for "subvol" support, because that also requires special flags in inodes and other such things to mark the filesystem as a subvol.

Overall, there's remarkably little change for the subvol feature - about 1400 lines of new kernel code and ~300 lines of userspace code were needed for the demo I gave during the talk. Compare that to the data-COW feature in XFS that it relies on - we added about 20,000 lines of code for that between kernel and userspace....

New tricks for XFS

Posted Mar 3, 2018 13:58 UTC (Sat) by nix (subscriber, #2304) [Link]

Ah right, a few small additions then: still surprisingly little. A couple of new flags doesn't sound like the kind of thing that would require a v6 filesystem and a new mkfs, unlike the massive addition which was rmapbt and all that it implies.