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@xxxxxxxxxxxxx
