On Thu, Feb 06, 2025 at 08:31:23PM -0800, Darrick J. Wong wrote: > On Thu, Feb 06, 2025 at 07:44:50AM +0100, Christoph Hellwig wrote: > > While the zoned on-disk format supports reflinks, the GC code currently > > always unshares reflinks when moving blocks to new zones, thus making the > > feature unusuable. Disable reflinks until the GC code is refcount aware. > > It might be worth mentioning that I've been working on a refcount-aware > free space defragmenter that could be used for this kind of thing, > albeit with the usual problems of userspace can't really stop the > kernel from filling its brains and starving our defragc process. > > It would be interesting to load up that adversarial thread timing > sched_ext thing that I hear was talked about at fosdem. Not sure waht sched_ext thing and how it's relevant. It's just that refcount awareness is a bit of work and not really required for the initial use cases. It might also have fun implications for the metabtree reservations, but otherwise I don't think it's rocket science. Even more so with a pre-existing implementation to steal ideas from. Talking about stealing ideas - the in-kernel GC flow should mostly work for a regular file system as well. I don't think actually sharing much code is going to be useful because the block reservations work so differently, but I suspect doing it in-kernel using the same "check if the mapping change at I/O completion time" scheme use in GC would work very well for a freespace defragmenter on a regular file system. And doing it in the kernel will be more efficient at operation time and probably also be a lot less code than doing it with a whole bunch of userspace to kernel roundtrips.
