Re: [PATCH] fuse: skip destination updates for zero-byte copy

[Yichong Chen]

Hi Amir,

Thanks for taking a look.

My concern is about the destination-side effects when the daemon returns a
zero-byte success.  In that case copy_file_range() returns 0 and no data has
been copied to the destination, so treating the destination as modified looks
wrong to me.

One visible effect is the timestamp update.  With writeback_cache enabled, I
can reproduce a non-zero-length FUSE_COPY_FILE_RANGE request for which the
daemon returns 0, and the kernel still sends utimens() for the destination.
This can make userspace tools such as sync, backup or build tools observe the
destination as modified even though no data was copied.  In many cases this
may only cause extra work, but it is still an observable metadata change for
a zero-byte result.

Another effect is the destination page-cache invalidation.  For a zero-byte
copy there is no copied range to invalidate, but the current range calculation
can still invalidate destination cache unnecessarily.  For example, when
pos_out is 0, the calculated range becomes
truncate_inode_pages_range(mapping, 0, -1), so it may invalidate the
destination mapping from the beginning.  This can cause extra FUSE read I/O
later.

I agree that the stale source size is a separate issue, but the current
destination updates do not fix that.  They operate on inode_out, so they do
not make inode_in's cached size consistent with the lower source file.

That said, my current patch is not complete because file_modified(file_out)
is called before the daemon reply is known and can already update the
destination timestamps.  I am doing a bit more testing around the zero-byte
case.  If you think this behavior is worth fixing, I can send a v2 with the
timestamp/cache update part corrected.

Thanks,
Yichong