1. 28 Apr, 2022 3 commits
    • Darrick J. Wong's avatar
      xfs: stop artificially limiting the length of bunmap calls · 4ed6435c
      Darrick J. Wong authored
      In commit e1a4e37c, we clamped the length of bunmapi calls on the
      data forks of shared files to avoid two failure scenarios: one where the
      extent being unmapped is so sparsely shared that we exceed the
      transaction reservation with the sheer number of refcount btree updates
      and EFI intent items; and the other where we attach so many deferred
      updates to the transaction that we pin the log tail and later the log
      head meets the tail, causing the log to livelock.
      
      We avoid triggering the first problem by tracking the number of ops in
      the refcount btree cursor and forcing a requeue of the refcount intent
      item any time we think that we might be close to overflowing.  This has
      been baked into XFS since before the original e1a4 patch.
      
      A recent patchset fixed the second problem by changing the deferred ops
      code to finish all the work items created by each round of trying to
      complete a refcount intent item, which eliminates the long chains of
      deferred items (27dad); and causing long-running transactions to relog
      their intent log items when space in the log gets low (74f4d).
      
      Because this clamp affects /any/ unmapping request regardless of the
      sharing factors of the component blocks, it degrades the performance of
      all large unmapping requests -- whereas with an unshared file we can
      unmap millions of blocks in one go, shared files are limited to
      unmapping a few thousand blocks at a time, which causes the upper level
      code to spin in a bunmapi loop even if it wasn't needed.
      
      This also eliminates one more place where log recovery behavior can
      differ from online behavior, because bunmapi operations no longer need
      to requeue.  The fstest generic/447 was created to test the old fix, and
      it still passes with this applied.
      
      Partial-revert-of: e1a4e37c ("xfs: try to avoid blowing out the transaction reservation when bunmaping a shared extent")
      Depends: 27dada07 ("xfs: change the order in which child and parent defer ops ar finished")
      Depends: 74f4d6a1 ("xfs: only relog deferred intent items if free space in the log gets low")
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      4ed6435c
    • Darrick J. Wong's avatar
      xfs: count EFIs when deciding to ask for a continuation of a refcount update · c47260d4
      Darrick J. Wong authored
      A long time ago, I added to XFS the ability to use deferred reference
      count operations as part of a transaction chain.  This enabled us to
      avoid blowing out the transaction reservation when the blocks in a
      physical extent all had different reference counts because we could ask
      the deferred operation manager for a continuation, which would get us a
      clean transaction.
      
      The refcount code asks for a continuation when the number of refcount
      record updates reaches the point where we think that the transaction has
      logged enough full btree blocks due to refcount (and free space) btree
      shape changes and refcount record updates that we're in danger of
      overflowing the transaction.
      
      We did not previously count the EFIs logged to the refcount update
      transaction because the clamps on the length of a bunmap operation were
      sufficient to avoid overflowing the transaction reservation even in the
      worst case situation where every other block of the unmapped extent is
      shared.
      
      Unfortunately, the restrictions on bunmap length avoid failure in the
      worst case by imposing a maximum unmap length of ~3000 blocks, even for
      non-pathological cases.  This seriously limits performance when freeing
      large extents.
      
      Therefore, track EFIs with the same counter as refcount record updates,
      and use that information as input into when we should ask for a
      continuation.  This enables the next patch to drop the clumsy bunmap
      limitation.
      
      Depends: 27dada07 ("xfs: change the order in which child and parent defer ops ar finished")
      Depends: 74f4d6a1 ("xfs: only relog deferred intent items if free space in the log gets low")
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      c47260d4
    • Darrick J. Wong's avatar
      xfs: speed up write operations by using non-overlapped lookups when possible · 1edf8056
      Darrick J. Wong authored
      Reverse mapping on a reflink-capable filesystem has some pretty high
      overhead when performing file operations.  This is because the rmap
      records for logically and physically adjacent extents might not be
      adjacent in the rmap index due to data block sharing.  As a result, we
      use expensive overlapped-interval btree search, which walks every record
      that overlaps with the supplied key in the hopes of finding the record.
      
      However, profiling data shows that when the index contains a record that
      is an exact match for a query key, the non-overlapped btree search
      function can find the record much faster than the overlapped version.
      Try the non-overlapped lookup first when we're trying to find the left
      neighbor rmap record for a given file mapping, which makes unwritten
      extent conversion and remap operations run faster if data block sharing
      is minimal in this part of the filesystem.
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      1edf8056
  2. 27 Apr, 2022 3 commits
  3. 21 Apr, 2022 34 commits