1. 29 7月, 2020 3 次提交
  2. 20 5月, 2020 2 次提交
  3. 03 3月, 2020 12 次提交
  4. 10 1月, 2020 2 次提交
  5. 23 11月, 2019 2 次提交
  6. 31 8月, 2019 3 次提交
    • D
      xfs: allocate xattr buffer on demand · ddbca70c
      Dave Chinner 提交于
      When doing file lookups and checking for permissions, we end up in
      xfs_get_acl() to see if there are any ACLs on the inode. This
      requires and xattr lookup, and to do that we have to supply a buffer
      large enough to hold an maximum sized xattr.
      
      On workloads were we are accessing a wide range of cache cold files
      under memory pressure (e.g. NFS fileservers) we end up spending a
      lot of time allocating the buffer. The buffer is 64k in length, so
      is a contiguous multi-page allocation, and if that then fails we
      fall back to vmalloc(). Hence the allocation here is /expensive/
      when we are looking up hundreds of thousands of files a second.
      
      Initial numbers from a bpf trace show average time in xfs_get_acl()
      is ~32us, with ~19us of that in the memory allocation. Note these
      are average times, so there are going to be affected by the worst
      case allocations more than the common fast case...
      
      To avoid this, we could just do a "null"  lookup to see if the ACL
      xattr exists and then only do the allocation if it exists. This,
      however, optimises the path for the "no ACL present" case at the
      expense of the "acl present" case. i.e. we can halve the time in
      xfs_get_acl() for the no acl case (i.e down to ~10-15us), but that
      then increases the ACL case by 30% (i.e. up to 40-45us).
      
      To solve this and speed up both cases, drive the xattr buffer
      allocation into the attribute code once we know what the actual
      xattr length is. For the no-xattr case, we avoid the allocation
      completely, speeding up that case. For the common ACL case, we'll
      end up with a fast heap allocation (because it'll be smaller than a
      page), and only for the rarer "we have a remote xattr" will we have
      a multi-page allocation occur. Hence the common ACL case will be
      much faster, too.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      ddbca70c
    • D
      xfs: move remote attr retrieval into xfs_attr3_leaf_getvalue · e3cc4554
      Dave Chinner 提交于
      Because we repeat exactly the same code to get the remote attribute
      value after both calls to xfs_attr3_leaf_getvalue() if it's a remote
      attr. Just do it in xfs_attr3_leaf_getvalue() so the callers don't
      have to care about it.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      e3cc4554
    • D
      xfs: make attr lookup returns consistent · 728bcaa3
      Dave Chinner 提交于
      Shortform, leaf and remote value attr value retrieval return
      different values for success. This makes it more complex to handle
      actual errors xfs_attr_get() as some errors mean success and some
      mean failure. Make the return values consistent for success and
      failure consistent for all attribute formats.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      728bcaa3
  7. 29 6月, 2019 1 次提交
  8. 30 4月, 2019 1 次提交
    • D
      xfs: always rejoin held resources during defer roll · 710d707d
      Darrick J. Wong 提交于
      During testing of xfs/141 on a V4 filesystem, I observed some
      inconsistent behavior with regards to resources that are held (i.e.
      remain locked) across a defer roll.  The transaction roll always gives
      the defer roll function a new transaction, even if committing the old
      transaction fails.  However, the defer roll function only rejoins the
      held resources if the transaction commit succeedied.  This means that
      callers of defer roll have to figure out whether the held resources are
      attached to the transaction being passed back.
      
      Worse yet, if the defer roll was part of a defer finish call, we have a
      third possibility: the defer finish could pass back a dirty transaction
      with dirty held resources and an error code.
      
      The only sane way to handle all of these scenarios is to require that
      the code that held the resource either cancel the transaction before
      unlocking and releasing the resources, or use functions that detach
      resources from a transaction properly (e.g.  xfs_trans_brelse) if they
      need to drop the reference before committing or cancelling the
      transaction.
      
      In order to make this so, change the defer roll code to join held
      resources to the new transaction unconditionally and fix all the bhold
      callers to release the held buffers correctly.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      710d707d
  9. 12 2月, 2019 1 次提交
  10. 18 10月, 2018 3 次提交
  11. 29 9月, 2018 1 次提交
    • B
      xfs: remove last of unnecessary xfs_defer_cancel() callers · d5a2e289
      Brian Foster 提交于
      Now that deferred operations are completely managed via
      transactions, it's no longer necessary to cancel the dfops in error
      paths that already cancel the associated transaction. There are a
      few such calls lingering throughout the codebase.
      
      Remove all remaining unnecessary calls to xfs_defer_cancel(). This
      leaves xfs_defer_cancel() calls in two places. The first is the call
      in the transaction cancel path itself, which facilitates this patch.
      The second is made via the xfs_defer_finish() error path to provide
      consistent error semantics with transaction commit. For example,
      xfs_trans_commit() expects an xfs_defer_finish() failure to clean up
      the dfops structure before it returns.
      Signed-off-by: NBrian Foster <bfoster@redhat.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      
      d5a2e289
  12. 03 8月, 2018 3 次提交
  13. 27 7月, 2018 3 次提交
  14. 12 7月, 2018 3 次提交