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

[Viacheslav Dubeyko]

On Mon, 2026-01-26 at 11:12 -0800, Bart Van Assche wrote:
> On 1/26/26 10:18 AM, Viacheslav Dubeyko wrote:
> > I am not completely sure that copy offloading to the storage device
> > can
> > reduce energy consumption. The storage device needs to spend energy
> > for
> > executing this operation, anyway. Do you have any numbers that can
> > prove your point?
> 
> Yes, we have measurements that prove this point but unfortunately the
> vendor that collected this data does not allow us to publish that
> data.

I see.

> 
> Reducing energy consumption matters for mobile devices. There are
> other
> applications for copy offloading, e.g. in data centers and in
> enterprise
> applications. I don't think that these other users care as much about
> reducing energy consumption as we do.
> 
> > Which file system have you considered as working model of your
> > approach?
> Every LFS for zoned storage has to perform garbage collection, isn't
> it?
> I think that we can discuss copy offloading without having to discuss
> filesystem implementation details.
> 
> 

It is not exactly correct. :) Unfortunately, we have to discuss the
file system implementation details.

First of all, not every LFS file system needs GC. Because, SSDFS uses
migration scheme instead of classical GC. And migration scheme is not
GC based technique because the regular file system operations moves
valid blocks from exhausted erase block (segment) into clean one.

Even if GC must to be used, then (1) valid blocks needs to be taken
from the logs of exhausted segment (victim segment in GC terminology),
(2) log needs to be prepared and (3) stored into clean or current
segment. And log starts from metadata header and describes location of
other metadata structures in the log, and user data portions. For
example, NILFS2 contains b-tree + other metadata + user data in the
log. SSDFS's log starts from header that describes locations in the log
of block bitmap, offsets translation table. Finally, offsets
translation table contains offsets to compressed portions of logical
blocks with user data or other metadata (like inodes b-tree, etc).

And even if we are talking about F2FS, then offloaded copy operations
needs to be accounted in metadata portion of the file system.

So, frankly speaking, currently, I don't see the generic technique that
can work for all LFS file systems. But, maybe, I simply don't see your
point. :) And this is why I am asking explanation of details how this
suggested technique can work for LFS file systems. Because, GC is
integrated subsystem of any LFS file system.

Thanks,
Slava.