XFS – A success story on the design and implementation process

Upstream acceptance of patches

Having a non-trivial patch accepted upstream usually takes multiple iterations with folks providing feedback at each revision until an acceptable solution has been hammered out. This can take months (or even years for complex ones). However, this does not have to be the only way.

XFS Community

The XFS community tried a different process – with the intention to get feedback much quicker.

Specifically, the v6.7 recent merge pulls by Chandan Babu included a neat feature developed by Catherine Hoang. The description explains the problem succinctly:

xfs: allow read IO and FICLONE to run concurrently

One of our VM cluster management products needs to snapshot KVM image
files so that they can be restored in case of failure. Snapshotting is
done by redirecting VM disk writes to a sidecar file and using reflink
on the disk image, specifically the FICLONE ioctl as used by
"cp --reflink". Reflink locks the source and destination files while it
operates, which means that reads from the main vm disk image are blocked,
causing the vm to stall. When an image file is heavily fragmented, the
copy process could take several minutes. Some of the vm image files have
50-100 million extent records, and duplicating that much metadata locks
the file for 30 minutes or more...

But the story of how this patch came about started weeks before. Initially, Catherine posted a design document to solicit ideas before starting on the implementation.

A week of discussion and Catherine was off to implement code and three weeks later a patch was posted, and went straight to v6.7 tree – all within a two months allowing enough time to land in v6.7 (Linus releases are usually done every three months)!

This new path of hammering out a design is a fresh way forward in the Linux community and I hope that success stories like Catherine’s will be picked up by other Linux communities and replicated successfully.