An error occurred fetching the project authors.
  1. 22 Apr, 2024 1 commit
  2. 15 Apr, 2024 1 commit
    • Kent Overstreet's avatar
      bcachefs: bch_member.btree_allocated_bitmap · 27c15ed2
      Kent Overstreet authored
      This adds a small (64 bit) per-device bitmap that tracks ranges that
      have btree nodes, for accelerating btree node scan if it is ever needed.
      
      - New helpers, bch2_dev_btree_bitmap_marked() and
        bch2_dev_bitmap_mark(), for checking and updating the bitmap
      
      - Interior btree update path updates the bitmaps when required
      
      - The check_allocations pass has a new fsck_err check,
        btree_bitmap_not_marked
      
      - New on disk format version, mi_btree_mitmap, which indicates the new
        bitmap is present
      
      - Upgrade table lists the required recovery pass and expected fsck error
      
      - Btree node scan uses the bitmap to skip ranges if we're on the new
        version
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      27c15ed2
  3. 14 Apr, 2024 2 commits
    • Kent Overstreet's avatar
      bcachefs: Disable merges from interior update path · 3f100489
      Kent Overstreet authored
      There's been a bug in the btree write buffer where it wasn't triggering
      btree node merges - and leaving behind a bunch of nearly empty btree
      nodes.
      
      Then during journal replay, when updates to the backpointers btree
      aren't using the btree write buffer (because we require synchronization
      with journal replay), we end up doing those merges all at once.
      
      Then if it's the interior update path running them, we deadlock because
      those run with the highest watermark.
      
      There's no real need for the interior update path to be doing btree node
      merges; other code paths can handle that at lower watermarks.
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      3f100489
    • Kent Overstreet's avatar
      bcachefs: Run merges at BCH_WATERMARK_btree · 9054ef2e
      Kent Overstreet authored
      This fixes a deadlock where the interior update path during journal
      replay ends up doing a ton of merges on the backpointers btree, and
      deadlocking.
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      9054ef2e
  4. 12 Apr, 2024 1 commit
  5. 11 Apr, 2024 1 commit
  6. 06 Apr, 2024 1 commit
    • Kent Overstreet's avatar
      bcachefs: JOURNAL_SPACE_LOW · 6088234c
      Kent Overstreet authored
      "bcachefs; Fix deadlock in bch2_btree_update_start()" was a significant
      performance regression (nearly 50%) on multithreaded random writes with
      fio.
      
      The reason is that the journal watermark checks multiple things,
      including the state of the btree write buffer, and on multithreaded
      update heavy workloads we're bottleneked on write buffer flushing - we
      don't want kicknig off btree updates to depend on the state of the write
      buffer.
      
      This isn't strictly correct; the interior btree update path does do
      write buffer updates, but it's a tiny fraction of total accounting
      updates and we're more concerned with space in the journal itself.
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      6088234c
  7. 04 Apr, 2024 1 commit
  8. 03 Apr, 2024 1 commit
  9. 02 Apr, 2024 3 commits
  10. 01 Apr, 2024 5 commits
  11. 19 Mar, 2024 1 commit
  12. 18 Mar, 2024 4 commits
  13. 14 Mar, 2024 2 commits
  14. 10 Mar, 2024 2 commits
  15. 14 Feb, 2024 1 commit
  16. 21 Jan, 2024 1 commit
    • Kent Overstreet's avatar
      bcachefs: Prep work for variable size btree node buffers · ec4edd7b
      Kent Overstreet authored
      bcachefs btree nodes are big - typically 256k - and btree roots are
      pinned in memory. As we're now up to 18 btrees, we now have significant
      memory overhead in mostly empty btree roots.
      
      And in the future we're going to start enforcing that certain btree node
      boundaries exist, to solve lock contention issues - analagous to XFS's
      AGIs.
      
      Thus, we need to start allocating smaller btree node buffers when we
      can. This patch changes code that refers to the filesystem constant
      c->opts.btree_node_size to refer to the btree node buffer size -
      btree_buf_bytes() - where appropriate.
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      ec4edd7b
  17. 06 Jan, 2024 2 commits
  18. 01 Jan, 2024 10 commits