On Sun, May 25, 2025 at 10:18:27PM -0700, Christoph Hellwig wrote: > Well, I'd expect most uses cases of things like GC to use the "fallback" > for now - because copy isn't actually that often supported, and when it > is performance might not be good enough. So we'll need to optimize > for both cases. Maybe a fallback code is useful, but I'd leave the > buffer management for it to the caller so that it can reuse them. Or > maybe don't bother given how trivial the code is anyway. The use case > for common code would be strong if it refactored existing code and > showed that existing callers actually have enough common logic that > it's worth the effort. Just fyi, the initial user I was planning to target with the block layer's copy fallback isn't in kernel yet. Just an RFC at this moment on btrfs: https://lore.kernel.org/linux-btrfs/20250515163641.3449017-10-maharmstone@xxxxxx/ The blk-lib function could easily replace that patch's "do_copy()" without to much refactoring on the btrfs side.
