Re: [PATCH V2] xfs: make src file readable during reflink

[Dave Chinner <david@fromorbit.com>]

On Tue, Jul 05, 2022 at 11:37:54AM -0700, Darrick J. Wong wrote:
> On Tue, Jun 28, 2022 at 11:07:55PM -0700, Wengang Wang wrote:
> > During a reflink operation, the IOLOCK and MMAPLOCK of the source file
> > are held in exclusive mode for the duration. This prevents reads on the
> > source file, which could be a very long time if the source file has
> > millions of extents.
> > 
> > As the source of copy, besides some necessary modification (say dirty page
> > flushing), it plays readonly role. Locking source file exclusively through
> > out the full reflink copy is unreasonable.
> > 
> > This patch downgrades exclusive locks on source file to shared modes after
> > page cache flushing and before cloning the extents. To avoid source file
> > change after lock downgradation, direct write paths take IOLOCK_EXCL on
> > seeing reflink copy happening to the files.
.....

> I /do/ wonder if range locking would be a better solution here, since we
> can safely unlock file ranges that we've already remapped?

Depends. The prototype I did allowed concurrent remaps to run on
different ranges of the file. The extent manipulations were still
internally serialised by the ILOCK so the concurrent modifications
were still serialised. Hence things like block mapping lookups for
read IO still serialised. (And hence my interest in lockless btrees
for the extent list so read IO wouldn't need to take the ILOCK at
all.)

However, if you want to remap the entire file, we've still got to
start with locking the entire file range and draining IO and writing
back all dirty data. So cloning a file is still a complete
serialisation event with range locking, but we can optimise away
some of the tail latencies by unlocking ranges remapped range by
remapped range...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com