Thank you Dave and Darrick, I will think more on this. Thanks, Wengang > On Jul 5, 2022, at 6:35 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > 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
