[LSF/MM/BPF TOPIC] Block storage copy offloading

[Viacheslav Dubeyko]

On Tue, 2026-01-27 at 11:11 -0800, Bart Van Assche wrote:
> On 1/27/26 10:03 AM, Viacheslav Dubeyko wrote:
> > So, frankly speaking, currently, I don't see the generic technique
> > that
> > can work for all LFS file systems.
> If I change my topic proposal such that it says "some LFS can benefit
> from copy offloading" instead of "all LFS can benefit from copy
> offloading", is that sufficient to agree?
> 
> 

I assume that your approach is based on suggestion of capability to
move one or several physical sectors as it is in background and, then,
correct file system metadata on new location of user data (or
metadata). So, you need to do this as part of GC operations because a
file system uses Copy-On-Write (COW) policy. This file system can be
LFS (log-structured) file system or not LFS file system. If file system
based on log concept, then we cannot simply move physical sectors as it
is because we need to extract valid blocks from the log and prepare the
new log. If we can offload this logic into storage device, then we can
use this approach for LFS file systems. Otherwise, we cannot talk about
LFS file systems. If file system uses COW policy, it has GC, but it
doesn't use the log-structured concept, then we can use the suggested
approach. Because, we can move physical sectors as it is in the
background. However, if file system uses compression or encryption,
then situation can be complicated again. Because, logical block could
be smaller than physical sector and some metadata structure needs to
keep the knowledge of the size and location of a particular logical
block. So, again, moving physical sectors as it is could move the
invalidated logical blocks.

Potentially, it needs to talk about COW policy and non-compressed/non-
encrypted data? But it limits the approach significantly. And real
business case should be ready for compression and encryption.

Thanks,
Slava.