An error occurred fetching the project authors.
  1. 28 May, 2024 1 commit
  2. 09 May, 2024 3 commits
  3. 08 May, 2024 6 commits
    • Kent Overstreet's avatar
    • Kent Overstreet's avatar
    • Kent Overstreet's avatar
      bcachefs: member helper cleanups · 2f724563
      Kent Overstreet authored
      Some renaming for better consistency
      
      bch2_member_exists	-> bch2_member_alive
      bch2_dev_exists		-> bch2_member_exists
      bch2_dev_exsits2	-> bch2_dev_exists
      bch_dev_locked		-> bch2_dev_locked
      bch_dev_bkey_exists	-> bch2_dev_bkey_exists
      
      new helper - bch2_dev_safe
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      2f724563
    • Kent Overstreet's avatar
      bcachefs: bch2_btree_node_header_to_text() · 9089376f
      Kent Overstreet authored
      better btree node read path error messages
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      9089376f
    • Kent Overstreet's avatar
      7423330e
    • Kent Overstreet's avatar
      bcachefs: Fix needs_whiteout BUG_ON() in bkey_sort() · 5dfd3746
      Kent Overstreet authored
      Btree nodes are log structured; thus, we need to emit whiteouts when
      we're deleting a key that's been written out to disk.
      
      k->needs_whiteout tracks whether a key will need a whiteout when it's
      deleted, and this requires some careful handling; e.g. the key we're
      deleting may not have been written out to disk, but it may have
      overwritten a key that was - thus we need to carry this flag around on
      overwrites.
      
      Invariants:
      There may be multiple key for the same position in a given node (because
      of overwrites), but only one of them will be a live (non deleted) key,
      and only one key for a given position will have the needs_whiteout flag
      set.
      
      Additionally, we don't want to carry around whiteouts that need to be
      written in the main searchable part of a btree node - btree_iter_peek()
      will have to skip past them, and this can lead to an O(n^2) issues when
      doing sequential deletions (e.g. inode rm/truncate). So there's a
      separate region in the btree node buffer for unwritten whiteouts; these
      are merge sorted with the rest of the keys we're writing in the btree
      node write path.
      
      The unwritten whiteouts was a later optimization that bch2_sort_keys()
      didn't take into account; the unwritten whiteouts area means that we
      never have deleted keys with needs_whiteout set in the main searchable
      part of a btree node.
      
      That means we can simplify and optimize some sort paths, and eliminate
      an assertion that syzbot found:
      
      - Unless we're in the btree node write path, it's always ok to drop
        whiteouts when sorting
      - When sorting for a btree node write, we drop the whiteout if it's not
        from the unwritten whiteouts area, or if it's overwritten by a real
        key at the same position.
      
      This completely eliminates some tricky logic for propagating the
      needs_whiteout flag: syzbot was able to hit the assertion that checked
      that there shouldn't be more than one key at the same pos with
      needs_whiteout set, likely due to a combination of flipping on
      needs_whiteout on all written keys (they need whiteouts if overwritten),
      combined with not always dropping unneeded whiteouts, and the tricky
      logic in the sort path for preserving needs_whiteout that wasn't really
      needed.
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      5dfd3746
  4. 16 Apr, 2024 1 commit
  5. 14 Apr, 2024 2 commits
  6. 03 Apr, 2024 1 commit
  7. 02 Apr, 2024 1 commit
    • Kent Overstreet's avatar
      bcachefs: BCH_WATERMARK_interior_updates · e2a316b3
      Kent Overstreet authored
      This adds a new watermark, higher priority than BCH_WATERMARK_reclaim,
      for interior btree updates. We've seen a deadlock where journal replay
      triggers a ton of btree node merges, and these use up all available open
      buckets and then interior updates get stuck.
      
      One cause of this is that we're currently lacking btree node merging on
      write buffer btrees - that needs to be fixed as well.
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      e2a316b3
  8. 01 Apr, 2024 2 commits
    • Kent Overstreet's avatar
      bcachefs: Fix btree node keys accounting in topology repair path · 812a9297
      Kent Overstreet authored
      When dropping keys now outside a now because we're changing the node
      min/max, we need to redo the node's accounting as well.
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      812a9297
    • Kent Overstreet's avatar
      bcachefs: Improved topology repair checks · 79032b07
      Kent Overstreet authored
      Consolidate bch2_gc_check_topology() and btree_node_interior_verify(),
      and replace them with an improved version,
      bch2_btree_node_check_topology().
      
      This checks that children of an interior node correctly span the full
      range of the parent node with no overlaps.
      
      Also, ensure that topology repairs at runtime are always a fatal error;
      in particular, this adds a check in btree_iter_down() - if we don't find
      a key while walking down the btree that's indicative of a topology error
      and should be flagged as such, not a null ptr deref.
      
      Some checks in btree_update_interior.c remaining BUG_ONS(), because we
      already checked the node for topology errors when starting the update,
      and the assertions indicate that we _just_ corrupted the btree node -
      i.e. the problem can't be that existing on disk corruption, they
      indicate an actual algorithmic bug.
      
      In the future, we'll be annotating the fsck errors list with which
      recovery pass corrects them; the open coded "run explicit recovery pass
      or fatal error" in bch2_btree_node_check_topology() will in the future
      be done for every fsck_err() call.
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      79032b07
  9. 18 Mar, 2024 2 commits
  10. 14 Mar, 2024 1 commit
  11. 13 Mar, 2024 1 commit
  12. 10 Mar, 2024 1 commit
  13. 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
  14. 06 Jan, 2024 4 commits
  15. 01 Jan, 2024 5 commits
  16. 03 Dec, 2023 1 commit
  17. 24 Nov, 2023 1 commit
    • Kent Overstreet's avatar
      closures: CLOSURE_CALLBACK() to fix type punning · d4e3b928
      Kent Overstreet authored
      Control flow integrity is now checking that type signatures match on
      indirect function calls. That breaks closures, which embed a work_struct
      in a closure in such a way that a closure_fn may also be used as a
      workqueue fn by the underlying closure code.
      
      So we have to change closure fns to take a work_struct as their
      argument - but that results in a loss of clarity, as closure fns have
      different semantics from normal workqueue functions (they run owning a
      ref on the closure, which must be released with continue_at() or
      closure_return()).
      
      Thus, this patc introduces CLOSURE_CALLBACK() and closure_type() macros
      as suggested by Kees, to smooth things over a bit.
      Suggested-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Coly Li <colyli@suse.de>
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      d4e3b928
  18. 05 Nov, 2023 1 commit
  19. 02 Nov, 2023 2 commits
  20. 31 Oct, 2023 1 commit
  21. 22 Oct, 2023 2 commits