1. 12 May, 2022 16 commits
    • Dave Chinner's avatar
    • Dave Chinner's avatar
      xfs: can't use kmem_zalloc() for attribute buffers · 45ff8b47
      Dave Chinner authored
      Because heap allocation of 64kB buffers will fail:
      
      ....
       XFS: fs_mark(8414) possible memory allocation deadlock size 65768 in kmem_alloc (mode:0x2d40)
       XFS: fs_mark(8417) possible memory allocation deadlock size 65768 in kmem_alloc (mode:0x2d40)
       XFS: fs_mark(8409) possible memory allocation deadlock size 65768 in kmem_alloc (mode:0x2d40)
       XFS: fs_mark(8428) possible memory allocation deadlock size 65768 in kmem_alloc (mode:0x2d40)
       XFS: fs_mark(8430) possible memory allocation deadlock size 65768 in kmem_alloc (mode:0x2d40)
       XFS: fs_mark(8437) possible memory allocation deadlock size 65768 in kmem_alloc (mode:0x2d40)
       XFS: fs_mark(8433) possible memory allocation deadlock size 65768 in kmem_alloc (mode:0x2d40)
       XFS: fs_mark(8406) possible memory allocation deadlock size 65768 in kmem_alloc (mode:0x2d40)
       XFS: fs_mark(8412) possible memory allocation deadlock size 65768 in kmem_alloc (mode:0x2d40)
       XFS: fs_mark(8432) possible memory allocation deadlock size 65768 in kmem_alloc (mode:0x2d40)
       XFS: fs_mark(8424) possible memory allocation deadlock size 65768 in kmem_alloc (mode:0x2d40)
      ....
      
      I'd use kvmalloc() instead, but....
      
      - 48.19% xfs_attr_create_intent
        - 46.89% xfs_attri_init
           - kvmalloc_node
      	- 46.04% __kmalloc_node
      	   - kmalloc_large_node
      	      - 45.99% __alloc_pages
      		 - 39.39% __alloc_pages_slowpath.constprop.0
      		    - 38.89% __alloc_pages_direct_compact
      		       - 38.71% try_to_compact_pages
      			  - compact_zone_order
      			  - compact_zone
      			     - 21.09% isolate_migratepages_block
      				  10.31% PageHuge
      				  5.82% set_pfnblock_flags_mask
      				  0.86% get_pfnblock_flags_mask
      			     - 4.48% __reset_isolation_suitable
      				  4.44% __reset_isolation_pfn
      			     - 3.56% __pageblock_pfn_to_page
      				  1.33% pfn_to_online_page
      			       2.83% get_pfnblock_flags_mask
      			     - 0.87% migrate_pages
      				  0.86% compaction_alloc
      			       0.84% find_suitable_fallback
      		 - 6.60% get_page_from_freelist
      		      4.99% clear_page_erms
      		    - 1.19% _raw_spin_lock_irqsave
      		       - do_raw_spin_lock
      			    __pv_queued_spin_lock_slowpath
      	- 0.86% __vmalloc_node_range
      	     0.65% __alloc_pages_bulk
      
      .... this is just yet another reminder of how much kvmalloc() sucks.
      So lift xlog_cil_kvmalloc(), rename it to xlog_kvmalloc() and use
      that instead....
      
      We also clean up the attribute name and value lengths as they no
      longer need to be rounded out to sizes compatible with log vectors.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarAllison Henderson <allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      45ff8b47
    • Dave Chinner's avatar
      xfs: detect empty attr leaf blocks in xfs_attr3_leaf_verify · 51e6104f
      Dave Chinner authored
      xfs_repair flags these as a corruption error, so the verifier should
      catch software bugs that result in empty leaf blocks being written
      to disk, too.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarAllison Henderson <allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      51e6104f
    • Dave Chinner's avatar
      xfs: ATTR_REPLACE algorithm with LARP enabled needs rework · fdaf1bb3
      Dave Chinner authored
      We can't use the same algorithm for replacing an existing attribute
      when logging attributes. The existing algorithm is essentially:
      
      1. create new attr w/ INCOMPLETE
      2. atomically flip INCOMPLETE flags between old + new attribute
      3. remove old attr which is marked w/ INCOMPLETE
      
      This algorithm guarantees that we see either the old or new
      attribute, and if we fail after the atomic flag flip, we don't have
      to recover the removal of the old attr because we never see
      INCOMPLETE attributes in lookups.
      
      For logged attributes, however, this does not work. The logged
      attribute intents do not track the work that has been done as the
      transaction rolls, and hence the only recovery mechanism we have is
      "run the replace operation from scratch".
      
      This is further exacerbated by the attempt to avoid needing the
      INCOMPLETE flag to create an atomic swap. This means we can create
      a second active attribute of the same name before we remove the
      original. If we fail at any point after the create but before the
      removal has completed, we end up with duplicate attributes in
      the attr btree and recovery only tries to replace one of them.
      
      There are several other failure modes where we can leave partially
      allocated remote attributes that expose stale data, partially free
      remote attributes that enable UAF based stale data exposure, etc.
      
      TO fix this, we need a different algorithm for replace operations
      when LARP is enabled. Luckily, it's not that complex if we take the
      right first step. That is, the first thing we log is the attri
      intent with the new name/value pair and mark the old attr as
      INCOMPLETE in the same transaction.
      
      From there, we then remove the old attr and keep relogging the
      new name/value in the intent, such that we always know that we have
      to create the new attr in recovery. Once the old attr is removed,
      we then run a normal ATTR_CREATE operation relogging the intent as
      we go. If the new attr is local, then it gets created in a single
      atomic transaction that also logs the final intent done. If the new
      attr is remote, the we set INCOMPLETE on the new attr while we
      allocate and set the remote value, and then we clear the INCOMPLETE
      flag at in the last transaction taht logs the final intent done.
      
      If we fail at any point in this algorithm, log recovery will always
      see the same state on disk: the new name/value in the intent, and
      either an INCOMPLETE attr or no attr in the attr btree. If we find
      an INCOMPLETE attr, we run the full replace starting with removing
      the INCOMPLETE attr. If we don't find it, then we simply create the
      new attr.
      
      Notably, recovery of a failed create that has an INCOMPLETE flag set
      is now the same - we start with the lookup of the INCOMPLETE attr,
      and if that exists then we do the full replace recovery process,
      otherwise we just create the new attr.
      
      Hence changing the way we do the replace operation when LARP is
      enabled allows us to use the same log recovery algorithm for both
      the ATTR_CREATE and ATTR_REPLACE operations. This is also the same
      algorithm we use for runtime ATTR_REPLACE operations (except for the
      step setting up the initial conditions).
      
      The result is that:
      
      - ATTR_CREATE uses the same algorithm regardless of whether LARP is
        enabled or not
      - ATTR_REPLACE with larp=0 is identical to the old algorithm
      - ATTR_REPLACE with larp=1 runs an unmodified attr removal algorithm
        from the larp=0 code and then runs the unmodified ATTR_CREATE
        code.
      - log recovery when larp=1 runs the same ATTR_REPLACE algorithm as
        it uses at runtime.
      
      Because the state machine is now quite clean, changing the algorithm
      is really just a case of changing the initial state and how the
      states link together for the ATTR_REPLACE case. Hence it's not a
      huge amount of code for what is a fairly substantial rework
      of the attr logging and recovery algorithm....
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarAllison Henderson <allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      fdaf1bb3
    • Dave Chinner's avatar
      xfs: use XFS_DA_OP flags in deferred attr ops · e7f358de
      Dave Chinner authored
      We currently store the high level attr operation in
      args->attr_flags. This field contains what the VFS is telling us to
      do, but don't necessarily match what we are doing in the low level
      modification state machine. e.g. XATTR_REPLACE implies both
      XFS_DA_OP_ADDNAME and XFS_DA_OP_RENAME because it is doing both a
      remove and adding a new attr.
      
      However, deep in the individual state machine operations, we check
      errors against this high level VFS op flags, not the low level
      XFS_DA_OP flags. Indeed, we don't even have a low level flag for
      a REMOVE operation, so the only way we know we are doing a remove
      is the complete absence of XATTR_REPLACE, XATTR_CREATE,
      XFS_DA_OP_ADDNAME and XFS_DA_OP_RENAME. And because there are other
      flags in these fields, this is a pain to check if we need to.
      
      As the XFS_DA_OP flags are only needed once the deferred operations
      are set up, set these flags appropriately when we set the initial
      operation state. We also introduce a XFS_DA_OP_REMOVE flag to make
      it easy to know that we are doing a remove operation.
      
      With these, we can remove the use of XATTR_REPLACE and XATTR_CREATE
      in low level lookup operations, and manipulate the low level flags
      according to the low level context that is operating. e.g. log
      recovery does not have a VFS xattr operation state to copy into
      args->attr_flags, and the low level state machine ops we do for
      recovery do not match the high level VFS operations that were in
      progress when the system failed...
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarAllison Henderson <allison.henderson@oracle.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      e7f358de
    • Dave Chinner's avatar
      xfs: remove xfs_attri_remove_iter · 59782a23
      Dave Chinner authored
      xfs_attri_remove_iter is not used anymore, so remove it and all the
      infrastructure it uses and is needed to drive it. THe
      xfs_attr_refillstate() function now throws an unused warning, so
      isolate the xfs_attr_fillstate()/xfs_attr_refillstate() code pair
      with an #if 0 and a comment explaining why we want to keep this code
      and restore the optimisation it provides in the near future.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      59782a23
    • Dave Chinner's avatar
      xfs: switch attr remove to xfs_attri_set_iter · 4b9879b1
      Dave Chinner authored
      Now that xfs_attri_set_iter() has initial states for removing
      attributes, switch the pure attribute removal code over to using it.
      This requires attrs being removed to always be marked as INCOMPLETE
      before we start the removal due to the fact we look up the attr to
      remove again in xfs_attr_node_remove_attr().
      
      Note: this drops the fillstate/refillstate optimisations from
      the remove path that avoid having to look up the path again after
      setting the incomplete flag and removing remote attrs. Restoring
      that optimisation to this path is future Dave's problem.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarAllison Henderson <allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      4b9879b1
    • Dave Chinner's avatar
      xfs: introduce attr remove initial states into xfs_attr_set_iter · e5d5596a
      Dave Chinner authored
      We need to merge the add and remove code paths to enable safe
      recovery of replace operations. Hoist the initial remove states from
      xfs_attr_remove_iter into xfs_attr_set_iter. We will make use of
      them in the next patches.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      e5d5596a
    • Dave Chinner's avatar
      xfs: xfs_attr_set_iter() does not need to return EAGAIN · 4e3d96a5
      Dave Chinner authored
      Now that the full xfs_attr_set_iter() state machine always
      terminates with either the state being XFS_DAS_DONE on success or
      an error on failure, we can get rid of the need for it to return
      -EAGAIN whenever it needs to roll the transaction before running
      the next state.
      
      That is, we don't need to spray -EAGAIN return states everywhere,
      the caller just check the state machine state for completion to
      determine what action should be taken next. This greatly simplifies
      the code within the state machine implementation as it now only has
      to handle 0 for success or -errno for error and it doesn't need to
      tell the caller to retry.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      4e3d96a5
    • Dave Chinner's avatar
      xfs: clean up final attr removal in xfs_attr_set_iter · b11fa61b
      Dave Chinner authored
      Clean up the final leaf/node states in xfs_attr_set_iter() to
      further simplify the high level state machine and to set the
      completion state correctly. As we are adding a separate state
      for node format removal, we need to ensure that node formats
      are collapsed back to shortform or empty correctly.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      b11fa61b
    • Dave Chinner's avatar
      xfs: remote xattr removal in xfs_attr_set_iter() is conditional · 2e7ef218
      Dave Chinner authored
      We may not have a remote value for the old xattr we have to remove,
      so skip over the remote value removal states and go straight to
      the xattr name removal in the leaf/node block.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      2e7ef218
    • Dave Chinner's avatar
      xfs: XFS_DAS_LEAF_REPLACE state only needed if !LARP · 411b434a
      Dave Chinner authored
      We can skip the REPLACE state when LARP is enabled, but that means
      the XFS_DAS_FLIP_LFLAG state is now poorly named - it indicates
      something that has been done rather than what the state is going to
      do. Rename it to "REMOVE_OLD" to indicate that we are now going to
      perform removal of the old attr.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      411b434a
    • Dave Chinner's avatar
      xfs: split remote attr setting out from replace path · 7d035336
      Dave Chinner authored
      When we set a new xattr, we have three exit paths:
      
      	1. nothing else to do
      	2. allocate and set the remote xattr value
      	3. perform the rest of a replace operation
      
      Currently we push both 2 and 3 into the same state, regardless of
      whether we just set a remote attribute or not. Once we've set the
      remote xattr, we have two exit states:
      
      	1. nothing else to do
      	2. perform the rest of a replace operation
      
      Hence we can split the remote xattr allocation and setting into
      their own states and factor it out of xfs_attr_set_iter() to further
      clean up the state machine and the implementation of the state
      machine.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
      Reviewed-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      7d035336
    • Dave Chinner's avatar
      xfs: consolidate leaf/node states in xfs_attr_set_iter · 251b29c8
      Dave Chinner authored
      The operations performed from XFS_DAS_FOUND_LBLK through to
      XFS_DAS_RM_LBLK are now identical to XFS_DAS_FOUND_NBLK through to
      XFS_DAS_RM_NBLK. We can collapse these down into a single set of
      code.
      
      To do this, define the states that leaf and node run through as
      separate sets of sequential states. Then as we move to the next
      state, we can use increments rather than specific state assignments
      to move through the states. This means the state progression is set
      by the initial state that enters the series and we don't need to
      duplicate the code anymore.
      
      At the exit point of the series we need to select the correct leaf
      or node state, but that can also be done by state increment rather
      than assignment.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      251b29c8
    • Dave Chinner's avatar
      xfs: kill XFS_DAC_LEAF_ADDNAME_INIT · 2157d169
      Dave Chinner authored
      We re-enter the XFS_DAS_FOUND_LBLK state when we have to allocate
      multiple extents for a remote xattr. We currently have a flag
      called XFS_DAC_LEAF_ADDNAME_INIT to avoid running the remote attr
      hole finding code more than once.
      
      However, for the node format tree, we have a separate state for this
      so we never reenter the state machine at XFS_DAS_FOUND_NBLK and so
      it does not need a special flag to skip over the remote attr hold
      finding code.
      
      Convert the leaf block code to use the same state machine as the
      node blocks and kill the  XFS_DAC_LEAF_ADDNAME_INIT flag.
      
      This further points out that this "ALLOC" state is only traversed
      if we have remote xattrs or we are doing a rename operation. Rename
      both the leaf and node alloc states to _ALLOC_RMT to indicate they
      are iterating to do allocation of remote xattr blocks.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      2157d169
    • Dave Chinner's avatar
      xfs: separate out initial attr_set states · e0c41089
      Dave Chinner authored
      We current use XFS_DAS_UNINIT for several steps in the attr_set
      state machine. We use it for setting shortform xattrs, converting
      from shortform to leaf, leaf add, leaf-to-node and leaf add. All of
      these things are essentially known before we start the state machine
      iterating, so we really should separate them out:
      
      XFS_DAS_SF_ADD:
      	- tries to do a shortform add
      	- on success -> done
      	- on ENOSPC converts to leaf, -> XFS_DAS_LEAF_ADD
      	- on error, dies.
      
      XFS_DAS_LEAF_ADD:
      	- tries to do leaf add
      	- on success:
      		- inline attr -> done
      		- remote xattr || REPLACE -> XFS_DAS_FOUND_LBLK
      	- on ENOSPC converts to node, -> XFS_DAS_NODE_ADD
      	- on error, dies
      
      XFS_DAS_NODE_ADD:
      	- tries to do node add
      	- on success:
      		- inline attr -> done
      		- remote xattr || REPLACE -> XFS_DAS_FOUND_NBLK
      	- on error, dies
      
      This makes it easier to understand how the state machine starts
      up and sets us up on the path to further state machine
      simplifications.
      
      This also converts the DAS state tracepoints to use strings rather
      than numbers, as converting between enums and numbers requires
      manual counting rather than just reading the name.
      
      This also introduces a XFS_DAS_DONE state so that we can trace
      successful operation completions easily.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      e0c41089
  2. 11 May, 2022 16 commits
  3. 09 May, 2022 2 commits
  4. 04 May, 2022 6 commits
    • Allison Henderson's avatar
      xfs: Set up infrastructure for log attribute replay · fd920008
      Allison Henderson authored
      Currently attributes are modified directly across one or more
      transactions. But they are not logged or replayed in the event of an
      error. The goal of log attr replay is to enable logging and replaying
      of attribute operations using the existing delayed operations
      infrastructure.  This will later enable the attributes to become part of
      larger multi part operations that also must first be recorded to the
      log.  This is mostly of interest in the scheme of parent pointers which
      would need to maintain an attribute containing parent inode information
      any time an inode is moved, created, or removed.  Parent pointers would
      then be of interest to any feature that would need to quickly derive an
      inode path from the mount point. Online scrub, nfs lookups and fs grow
      or shrink operations are all features that could take advantage of this.
      
      This patch adds two new log item types for setting or removing
      attributes as deferred operations.  The xfs_attri_log_item will log an
      intent to set or remove an attribute.  The corresponding
      xfs_attrd_log_item holds a reference to the xfs_attri_log_item and is
      freed once the transaction is done.  Both log items use a generic
      xfs_attr_log_format structure that contains the attribute name, value,
      flags, inode, and an op_flag that indicates if the operations is a set
      or remove.
      
      [dchinner: added extra little bits needed for intent whiteouts]
      Signed-off-by: default avatarAllison Henderson <allison.henderson@oracle.com>
      Reviewed-by: default avatarChandan Babu R <chandanrlinux@gmail.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      fd920008
    • Allison Henderson's avatar
      xfs: Return from xfs_attr_set_iter if there are no more rmtblks to process · 9a39cdab
      Allison Henderson authored
      During an attr rename operation, blocks are saved for later removal
      as rmtblkno2. The rmtblkno is used in the case of needing to alloc
      more blocks if not enough were available.  However, in the case
      that no further blocks need to be added or removed, we can return as soon
      as xfs_attr_node_addname completes, rather than rolling the transaction
      with an -EAGAIN return.  This extra loop does not hurt anything right
      now, but it will be a problem later when we get into log items because
      we end up with an empty log transaction.  So, add a simple check to
      cut out the unneeded iteration.
      Signed-off-by: default avatarAllison Henderson <allison.henderson@oracle.com>
      Reviewed-by: default avatarChandan Babu R <chandanrlinux@gmail.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      9a39cdab
    • Allison Henderson's avatar
      xfs: Fix double unlock in defer capture code · 7b3ec2b2
      Allison Henderson authored
      The new deferred attr patch set uncovered a double unlock in the
      recent port of the defer ops capture and continue code.  During log
      recovery, we're allowed to hold buffers to a transaction that's being
      used to replay an intent item.  When we capture the resources as part
      of scheduling a continuation of an intent chain, we call xfs_buf_hold
      to retain our reference to the buffer beyond the transaction commit,
      but we do /not/ call xfs_trans_bhold to maintain the buffer lock.
      This means that xfs_defer_ops_continue needs to relock the buffers
      before xfs_defer_restore_resources joins then tothe new transaction.
      
      Additionally, the buffers should not be passed back via the dres
      structure since they need to remain locked unlike the inodes.  So
      simply set dr_bufs to zero after populating the dres structure.
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarAllison Henderson <allison.henderson@oracle.com>
      Reviewed-by: default avatarChandan Babu R <chandan.babu@oracle.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      7b3ec2b2
    • Dave Chinner's avatar
    • Dave Chinner's avatar
      Merge tag 'reflink-speedups-5.19_2022-04-28' of... · 166afc45
      Dave Chinner authored
      Merge tag 'reflink-speedups-5.19_2022-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-5.19-for-next
      
      xfs: fix reflink inefficiencies
      
      As Dave Chinner has complained about on IRC, there are a couple of
      things about reflink that are very inefficient.  First of all, we
      limited the size of all bunmapi operations to avoid flooding the log
      with defer ops in the worst case, but recent changes to the defer
      ops code have solved that problem, so get rid of the bunmapi length
      clamp.
      
      Second, the log reservations for reflink operations are far far
      larger than they need to be.  Shrink them to exactly what we need to
      handle each deferred RUI and CUI log item, and no more.  Also reduce
      logcount because we don't need 8 rolls per operation.  Introduce a
      transaction reservation compatibility layer to avoid changing the
      minimum log size calculations.
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      166afc45
    • Dave Chinner's avatar
      Merge tag 'rmap-speedups-5.19_2022-04-28' of... · 956f1b8f
      Dave Chinner authored
      Merge tag 'rmap-speedups-5.19_2022-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into xfs-5.19-for-next
      
      xfs: fix rmap inefficiencies
      
      Reduce the performance impact of the reverse mapping btree when
      reflink is enabled by using the much faster non-overlapped btree
      lookup functions when we're searching the rmap index with a fully
      specified key.  If we find the exact record we're looking for,
      great!  We don't have to perform the full overlapped scan.  For
      filesystems with high sharing factors this reduces the xfs_scrub
      runtime by a good 15%%.
      
      This has been shown to reduce the fstests runtime for realtime rmap
      configurations by 30%%, since the lack of AGs severely limits
      scalability.
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      956f1b8f