[PATCHBOMB 6.14 v6.0] xfs: realtime rmap and reflink

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi everyone,

Christoph and I have been working on getting the long-delayed port of
reverse mapping and reflink to the realtime device into mergeable shape.
With these changes, the realtime volume finally reaches feature parity
with the data device.  This is the base for building more functionality
into xfs, such as the zoned storage support that Christoph posted the
other day.

The first couple of patchsets are all cleanups and refactoring so that
we can fully support having btrees rooted in an inode's data fork.  This
is necessary because the generic btree code only supports using the
immediate area as an internal tree node -- conversion from extents to
bmbt format only happens when there are too many leaf records to fit in
the immediate area.  Therefore, we need to remodel it to support storing
records in the immediate area.  We also need to be able to reserve
space for future btree expansion, so the second patchset enables
tracking per-inode reservations from the free space.

The third patchset ports reverse mapping btree to the realtime device,
which mainly consists of constructing a btree in an inode, linking the
inode into the metadata directory tree, and updating the log items to
handle rt rmap update log intent items.

The fourth patchset ports the refcount btree, block sharing, and copy on
write to the realtime device.

The fifth and final patchset is still RFC status -- it enables reflink
and out of place COW writes when the rt extent size is larger than a
single fsblock.  This part is sketchy -- I want to avoid needing to
change a lot of the bmap code to handle the case where an rt extent's
worth of logical file blocks map to multiple rt extents, so I mandated
that sharing and COW must happen on rt extent boundaries.  To make this
happen I had to fiddle around with the generic remap functions and
writeback control so that we always dirty an entire rt extent's worth of
pages, and we always try to schedule writeback in units of rt extents.
I suspect this might be racy.  We might be better off never picking up
support for non-power-of-two rt extent sizes with reflink; or never
adding support for rtextsize > 1 at all.

Please have a look at the git tree links for code changes:

https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=realtime-reflink-extsize_2024-12-12
https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=realtime-reflink-extsize_2024-12-12
https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=realtime-reflink-extsize_2024-12-03

(fstests is behind because I haven't rebased atop the parallel fstests
work)

--D




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux