1. 09 6月, 2021 1 次提交
  2. 04 6月, 2021 2 次提交
  3. 02 6月, 2021 3 次提交
  4. 08 4月, 2021 1 次提交
  5. 04 2月, 2021 3 次提交
  6. 02 2月, 2021 2 次提交
  7. 23 1月, 2021 1 次提交
  8. 10 12月, 2020 1 次提交
  9. 07 10月, 2020 1 次提交
    • D
      xfs: periodically relog deferred intent items · 4e919af7
      Darrick J. Wong 提交于
      There's a subtle design flaw in the deferred log item code that can lead
      to pinning the log tail.  Taking up the defer ops chain examples from
      the previous commit, we can get trapped in sequences like this:
      
      Caller hands us a transaction t0 with D0-D3 attached.  The defer ops
      chain will look like the following if the transaction rolls succeed:
      
      t1: D0(t0), D1(t0), D2(t0), D3(t0)
      t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0)
      t3: d5(t1), D1(t0), D2(t0), D3(t0)
      ...
      t9: d9(t7), D3(t0)
      t10: D3(t0)
      t11: d10(t10), d11(t10)
      t12: d11(t10)
      
      In transaction 9, we finish d9 and try to roll to t10 while holding onto
      an intent item for D3 that we logged in t0.
      
      The previous commit changed the order in which we place new defer ops in
      the defer ops processing chain to reduce the maximum chain length.  Now
      make xfs_defer_finish_noroll capable of relogging the entire chain
      periodically so that we can always move the log tail forward.  Most
      chains will never get relogged, except for operations that generate very
      long chains (large extents containing many blocks with different sharing
      levels) or are on filesystems with small logs and a lot of ongoing
      metadata updates.
      
      Callers are now required to ensure that the transaction reservation is
      large enough to handle logging done items and new intent items for the
      maximum possible chain length.  Most callers are careful to keep the
      chain lengths low, so the overhead should be minimal.
      
      The decision to relog an intent item is made based on whether the intent
      was logged in a previous checkpoint, since there's no point in relogging
      an intent into the same checkpoint.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      4e919af7
  10. 16 9月, 2020 2 次提交
  11. 07 9月, 2020 1 次提交
  12. 29 7月, 2020 8 次提交
  13. 07 7月, 2020 1 次提交
    • D
      xfs: redesign the reflink remap loop to fix blkres depletion crash · 00fd1d56
      Darrick J. Wong 提交于
      The existing reflink remapping loop has some structural problems that
      need addressing:
      
      The biggest problem is that we create one transaction for each extent in
      the source file without accounting for the number of mappings there are
      for the same range in the destination file.  In other words, we don't
      know the number of remap operations that will be necessary and we
      therefore cannot guess the block reservation required.  On highly
      fragmented filesystems (e.g. ones with active dedupe) we guess wrong,
      run out of block reservation, and fail.
      
      The second problem is that we don't actually use the bmap intents to
      their full potential -- instead of calling bunmapi directly and having
      to deal with its backwards operation, we could call the deferred ops
      xfs_bmap_unmap_extent and xfs_refcount_decrease_extent instead.  This
      makes the frontend loop much simpler.
      
      Solve all of these problems by refactoring the remapping loops so that
      we only perform one remapping operation per transaction, and each
      operation only tries to remap a single extent from source to dest.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      Reported-by: NEdwin Török <edwin@etorok.net>
      Tested-by: NEdwin Török <edwin@etorok.net>
      00fd1d56
  14. 20 5月, 2020 2 次提交
  15. 27 3月, 2020 2 次提交
  16. 18 3月, 2020 3 次提交
    • D
      xfs: support bulk loading of staged btrees · 60e3d707
      Darrick J. Wong 提交于
      Add a new btree function that enables us to bulk load a btree cursor.
      This will be used by the upcoming online repair patches to generate new
      btrees.  This avoids the programmatic inefficiency of calling
      xfs_btree_insert in a loop (which generates a lot of log traffic) in
      favor of stamping out new btree blocks with ordered buffers, and then
      committing both the new root and scheduling the removal of the old btree
      blocks in a single transaction commit.
      
      The design of this new generic code is based off the btree rebuilding
      code in xfs_repair's phase 5 code, with the explicit goal of enabling us
      to share that code between scrub and repair.  It has the additional
      feature of being able to control btree block loading factors.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      60e3d707
    • D
      xfs: introduce fake roots for inode-rooted btrees · 349e1c03
      Darrick J. Wong 提交于
      Create an in-core fake root for inode-rooted btree types so that callers
      can generate a whole new btree using the upcoming btree bulk load
      function without making the new tree accessible from the rest of the
      filesystem.  It is up to the individual btree type to provide a function
      to create a staged cursor (presumably with the appropriate callouts to
      update the fakeroot) and then commit the staged root back into the
      filesystem.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      349e1c03
    • D
      xfs: introduce fake roots for ag-rooted btrees · e06536a6
      Darrick J. Wong 提交于
      Create an in-core fake root for AG-rooted btree types so that callers
      can generate a whole new btree using the upcoming btree bulk load
      function without making the new tree accessible from the rest of the
      filesystem.  It is up to the individual btree type to provide a function
      to create a staged cursor (presumably with the appropriate callouts to
      update the fakeroot) and then commit the staged root back into the
      filesystem.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      e06536a6
  17. 03 3月, 2020 4 次提交
  18. 19 12月, 2019 1 次提交
    • D
      xfs: don't commit sunit/swidth updates to disk if that would cause repair failures · 13eaec4b
      Darrick J. Wong 提交于
      Alex Lyakas reported[1] that mounting an xfs filesystem with new sunit
      and swidth values could cause xfs_repair to fail loudly.  The problem
      here is that repair calculates the where mkfs should have allocated the
      root inode, based on the superblock geometry.  The allocation decisions
      depend on sunit, which means that we really can't go updating sunit if
      it would lead to a subsequent repair failure on an otherwise correct
      filesystem.
      
      Port from xfs_repair some code that computes the location of the root
      inode and teach mount to skip the ondisk update if it would cause
      problems for repair.  Along the way we'll update the documentation,
      provide a function for computing the minimum AGFL size instead of
      open-coding it, and cut down some indenting in the mount code.
      
      Note that we allow the mount to proceed (and new allocations will
      reflect this new geometry) because we've never screened this kind of
      thing before.  We'll have to wait for a new future incompat feature to
      enforce correct behavior, alas.
      
      Note that the geometry reporting always uses the superblock values, not
      the incore ones, so that is what xfs_info and xfs_growfs will report.
      
      [1] https://lore.kernel.org/linux-xfs/20191125130744.GA44777@bfoster/T/#m00f9594b511e076e2fcdd489d78bc30216d72a7dReported-by: NAlex Lyakas <alex@zadara.com>
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      13eaec4b
  19. 27 11月, 2019 1 次提交
    • P
      ftrace: Rework event_create_dir() · 04ae87a5
      Peter Zijlstra 提交于
      Rework event_create_dir() to use an array of static data instead of
      function pointers where possible.
      
      The problem is that it would call the function pointer on module load
      before parse_args(), possibly even before jump_labels were initialized.
      Luckily the generated functions don't use jump_labels but it still seems
      fragile. It also gets in the way of changing when we make the module map
      executable.
      
      The generated function are basically calling trace_define_field() with a
      bunch of static arguments. So instead of a function, capture these
      arguments in a static array, avoiding the function call.
      
      Now there are a number of cases where the fields are dynamic (syscall
      arguments, kprobes and uprobes), in which case a static array does not
      work, for these we preserve the function call. Luckily all these cases
      are not related to modules and so we can retain the function call for
      them.
      
      Also fix up all broken tracepoint definitions that now generate a
      compile error.
      Tested-by: NAlexei Starovoitov <ast@kernel.org>
      Tested-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20191111132458.342979914@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      04ae87a5