[GIT PULL] bcachefs changes for 6.17

[GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

Schedule notes for users:

I've been digging through the bug tracker and polling users to see what
bugs are still outstanding, and - it's not much.

So, the experimental label is coming off in 6.18. 

As always, if you do hit a bug, please report it.

-------------------------------

The following changes since commit c37495fe3531647db4ae5787a80699ae1438d7cf:

  bcachefs: Add missing snapshots_seen_add_inorder() (2025-07-24 22:56:37 -0400)

are available in the Git repository at:

  git://evilpiepirate.org/bcachefs.git tags/bcachefs-2025-07-28

for you to fetch changes up to c0d938c16b674bfe9e710579344653b703b92a49:

  bcachefs: Add missing error_throw to bch2_set_version_incompat() (2025-07-25 12:03:48 -0400)

----------------------------------------------------------------
bcachefs changes for 6.17-rc1

No noteworthy feature work: we're in hard freeze.

Lots of bugfixes. Assorted user visible changes and fixes:

- Fix a major performance bug when deleting many files: this was caused
  by the key cache caching keys that had been deleted, causing certain
  lookups in the inode triggers to scan excessively.

- The "io_read_nopromote" counter has been broken out into sub-counters;
  these can be seen with 'bcachefs fs top' on a recent bcachefs-tools.
  This helps when diagnosing why reads aren't coming from the cache.

- Congestion tracking is now a bit less aggressive (this controls when
  we decide to do a promote); this area still needs more work.

- Metadata writes are no longer throttled by writeback throttling

- Nocow writes can now be rebalanced (e.g. background_target,
  background_compression options)

- (Almost) all recovery passes now have progress indicators.

- Repair improvements: we'll now reconstruct missing inodes if we find
  contents for that inode (more than one or two keys), not just if the
  inodes btree was damaged: similarly for 'dirent to missing inode'.

- Btree node tracepoint improvements: they've been converted to more
  modern printbuf tracepoints, and include significantly more info.

- Fix in-memory accounting going out of sync with the accounting btree
  when doing accounting updates before going RW.

- BCH_MIN_NR_BUCKETS (minimum number of buckets per device) has been
  increased from 64 to 512. In the unlikely event that anyone anyone
  actually was using bcachefs on sub 128M filesystems and doesn't want
  to lose access (modern tools will format these small filesystems with
  a more appropriate bucket size), please file a report or contact me.

  (This was just a syzbot issue, so far as I know).

- CLASS()/guard() conversion: a great deal of code has been converted to
  the new __cleanup based resource handling, and away from 'goto err'
  cleanup.

----------------------------------------------------------------
Alan Huang (5):
      bcachefs: Don't memcpy more than needed
      bcachefs: Refactor trans->mem allocation
      bcachefs: Shut up clang warning
      bcachefs: Don't lock exec_update_lock
      bcachefs: Use user_backed_iter instead of iter_is_iovec

Anindya Sundar Gayen (1):
      bcachefs: remove extraneous ; after statements

George Hu (1):
      bcachefs: use union for bch_compression_opt to make encode & decode easier

Kent Overstreet (193):
      bcachefs: Fix UAF by journal write path
      bcachefs: async_objs: update iter pos after obj printed
      bcachefs: fsck: dir_loop, subvol_loop now autofix
      bcachefs: kill darray_u32_has()
      bcachefs: Reduce __bch2_btree_node_alloc() stack usage
      bcachefs: Allow CONFIG_UNICODE=m
      bcachefs: use scoped_guard() in fast_list.c
      bcachefs: DEFINE_CLASS()es for dev refcounts
      bcachefs: More errcode conversions
      bcachefs: add an unlikely() to trans_begin()
      bcachefs: Plumb trans_kmalloc ip to trans_log_msg
      bcachefs: Don't log error twice in allocator async repair
      bcachefs: bch2_trans_has_updates()
      bcachefs: Improve inode deletion
      bcachefs: Don't peek key cache unless we have a real key
      bcachefs: Evict/bypass key cache when deleting
      bcachefs: -o fix_errors may now be used without -o fsck
      bcachefs: Improved btree node tracepoints
      bcachefs: Finish error_throw tracepoints
      bcachefs: Improve inode_create behaviour on old filesystems
      bcachefs: Before removing dangling dirents, check for contents
      bcachefs: check_key_has_inode() reconstructs more aggressively
      bcachefs: bch_fs.devs_removed
      bcachefs: ptr_to_removed_device
      bcachefs: bch2_journal_entry_missing_range()
      bcachefs: Faster checking for missing journal entries
      bcachefs: Add missing bch2_log_msg_start()
      bcachefs: Print errcode when bch2_read_extent() sees error
      bcachefs: Fix error message in buffered read path
      bcachefs: Debug param for injecting btree node corruption on read
      bcachefs: device add now properly sets c->online_devs
      bcachefs: silence userspace build warning
      bcachefs: Update path flags cleanups
      bcachefs: add missing log message newline
      bcachefs: add missing includes
      bcachefs: silence userspace build warning
      bcachefs: trace_data_update_done_no_rw_devs
      bcachefs: use kvzalloc() for journal bios
      bcachefs: Improve nopromote visibility
      bcachefs: unsigned -> enum bch_trans_commit_flags
      bcachefs: __bch2_btree_node_alloc() now respects target
      bcachefs: bch2_btree_write_buffer_insert_checks()
      bcachefs: don't call get_update_rebalance_opts() on btree ptrs
      bcachefs: kill bch2_err_str() BUG_ON()
      bcachefs: bch2_read_bio_to_text(): tabstops
      bcachefs: kill __bch2_print_str()
      bcachefs: bch_log()
      bcachefs: c->loglevel
      bcachefs: Zero list_idx when deleting from async obj lists
      bcachefs: fix device add before fs started
      bcachefs: fast_list: warn if non-empty on exit
      bcachefs: bch2_journal_key_insert_take() accumulates accounting updates
      bcachefs: bch2_fs_initialize() now runs journal replay
      bcachefs: do_bch2_trans_commit_to_journal_replay handles accounting
      bcachefs: bch2_set_nr_journal_buckets_iter() always marks
      bcachefs: bch2_fs_initialize() initializes before going RW
      bcachefs: Improve bch2_read_bio_to_text()
      bcachefs: Fix replicas max options
      bcachefs: Better congestion visibilty in sysfs
      bcachefs: nopromote sub counters
      bcachefs: make congestion tracking less aggressive
      bcachefs: __bset_aux_tree_verify_ro()
      bcachefs: Add missing bch2_bkey_set_needs_rebalance to nocow write path
      bcachefs: delete useless null ptr check
      bcachefs: Also create snapshots with CAP_FOWNER
      bcachefs: Fix missing compat code in check_subvol()
      bcachefs: Fix UAF in check_dirent()
      bcachefs: Fix journal assertion
      bcachefs: Fix __bch2_fs_read_write() error path
      bcachefs: Give debugfs cached btree nodes better indentation
      bcachefs: Silence clang warning about enum types
      bcachefs: kill bkey_journal_seq()
      bcachefs: don't pass bch_ioctl_data by value
      bcachefs: better device too small error message
      bcachefs: check_i_sectors now prints paths
      bcachefs: simplify bch2_trans_do()
      bcachefs: DEFINE_GUARD(printbuf_atomic)
      bcachefs: convert super-io.c to CLASS/guards
      bcachefs: convert super.c to CLASS/guards
      bcachefs: convert acl.c to CLASS/guards
      bcachefs: convert xattr.c to CLASS/guards
      bcachefs: convert thread_with_file.c to CLASS/guards
      bcachefs: convert unit tests to CLASS/guards
      bcachefs: convert util.[ch] to CLASS/guards
      bcachefs: convert six.c to guards
      bcachefs: convert progress.c to guards
      bcachefs: convert enumerated_ref.c to guards
      bcachefs: convert opts.c to CLASS/guards
      bcachefs: convert sysfs.c to CLASS/guards
      bcachefs: convert buckets_waiting_for_journal.c to CLASS/guards
      bcachefs: convert quota.c to CLASS/guards
      bcachefs: convert sb-clean.c to CLASS/guards
      bcachefs: convert sb-downgrade.c to CLASS/guards
      bcachefs: convert sb-errors.c to CLASS/guards
      bcachefs: convert sb-members.c to CLASS/guards
      bcachefs: convert clock.c to CLASS/guards
      bcachefs: convert debug.c to CLASS/guards
      bcachefs: convert nocow_locking.c to CLASS/guards
      bcachefs: convert replicas.c to CLASS/guards
      bcachefs: convert bset.c to CLASS
      bcachefs: convert bkey.c to CLASS
      bcachefs: convert chardev.c to CLASS
      bcachefs: convert fs-ioctl.c to CLASS/guards
      bcachefs: convert disk_groups.c to guards
      bcachefs: convert checksum.c to CLASS/guards
      bcachefs: convert compress.c to guards
      bcachefs: convert rebalance.c to CLASS/guards
      bcachefs: convert migrate.c to CLASS/guards
      bcachefs: convert move.c to CLASS/guards
      bcachefs: convert movinggc.c to CLASS
      bcachefs: convert data_update.c to CLASS/guards
      bcachefs: convert reflink.c to CLASS/guards
      bcachefs: convert snapshot.c to CLASS/guards
      bcachefs: convert subvolume.c to CLASS/guards
      bcachefs: convert str_hash.c to CLASS
      bcachefs: convert recovery_passes.c to CLASS/guards
      bcachefs: convert recovery.c to CLASS/guards
      bcachefs: convert lru.c to CLASS
      bcachefs: convert extents.c to guards
      bcachefs: convert logged_ops.c to CLASS
      bcachefs: convert inode.c to CLASS
      bcachefs: convert dirent.c to CLASS
      bcachefs: convert namei.c to CLASS
      bcachefs: convert io_read.c to CLASS/guards
      bcachefs: convert io_write.c to CLASS/guards
      bcachefs: convert io_misc.c to CLASS/guards
      bcachefs: convert fsck.c to CLASS/guards
      bcachefs: convert disk_accounting.c to CLASS/guards
      bcachefs: convert buckets.c to CLASS/guards
      bcachefs: convert ec.c to CLASS/guards
      bcachefs: convert backpointers.c to CLASS/guards
      bcachefs: convert alloc_background.c to CLASS/guards
      bcachefs: convert alloc_foreground.c to CLASS/guards
      bcachefs: convert fs.c to CLASS/guards
      bcachefs: convert fs-io.c to CLASS/guards
      bcachefs: convert fs-io-pagecache.c to CLASS/guards
      bcachefs: convert fs-io-buffered.c to CLASS/guards
      bcachefs: convert fs-io-direct.c to CLASS/guards
      bcachefs: convert btree_node_scan.c to CLASS/guards
      bcachefs: convert journal.c to CLASS/guards
      bcachefs: convert journal_io.c to CLASS/guards
      bcachefs: convert journal_reclaim.c to CLASS/guards
      bcachefs: convert journal_seq_blacklist.c to CLASS/guards
      bcachefs: convert btree_cache.c to CLASS/guards
      bcachefs: convert btree_gc.c to CLASS/guards
      bcachefs: convert btree_write_buffer.c to CLASS/guards
      bcachefs: convert btree_update.c to CLASS/guards
      bcachefs: convert btree_update_interior.c to CLASS/guards
      bcachefs: convert btree_trans_commit.c to CLASS/guards
      bcachefs: convert btree_key_cache.c to CLASS/guards
      bcachefs: convert btree_io.c to CLASS/guards
      bcachefs: convert btree_iter.c to CLASS/guards
      bcachefs: convert btree_locking.c to CLASS/guards
      bcachefs: convert btree_journal_iter.c to CLASS/guards
      bcachefs: bch2_run_recovery_pass() now prints errors
      bcachefs: convert error.c to CLASS/guards
      bcachefs: Fix padding zeroout when creating casefolded dirents
      bcachefs: Don't call bch2_recovery_pass_want_ratelimit without sb_lock
      bcachefs: Tell wbt throttling not to throttle metadata writes
      bcachefs: Kill redundant write_super() when running recovery passes
      bcachefs: Add comment to journal_flush_done()
      bcachefs: Don't emit empty journal entry for accounting
      bcachefs: sysfs trigger_btree_write_buffer_flush
      closures: Improve warnings on bad put
      bcachefs: Fix unhandled key type in fiemap_fill_extent
      bcachefs: Ensure we don't return with closure on waitlist
      bcachefs: bch2_move_data() now walks btree nodes
      bcachefs: rereplicate flushes interior updates
      bcachefs: can_use_btree_node()
      bcachefs: Fix error handling in btree_iter_peek_slot
      bcachefs: fix assert in bch2_btree_path_traverse_cached()
      bcachefs: Fix allocate_dropping_locks() usage
      bcachefs: log devices we're scanning in btree node scan
      bcachefs: Fix refs to undefined fields in __bch2_alloc_v4_to_text()
      bcachefs: fix check_extent_overbig() call
      bcachefs: Convert topology repair errs to standard error codes
      bcachefs: Fix __bch2_alloc_to_v4 copy
      bcachefs: Flush btree_interior_update_work before freeing fs
      bcachefs: Only track read latency for congestion tracking
      bcachefs: Clean up btree_node_read_work() error handling
      bcachefs: Ensure pick_read_device() returns error for btree pointers
      bcachefs: btree_lost_data: mark a few more errors for silent fixing
      bcachefs: Don't allow mounting with crazy numbers of dirty journal entries
      bcachefs: Add pass_done to recovery_pass_status_to_text()
      bcachefs: Increase BCH_MIN_NR_NBUCKETS
      bcachefs: Hook up progress indicators for most recovery passes
      bcachefs: recovery_pass_will_run()
      bcachefs: journal_entry_btree_keys_to_text() is more careful
      bcachefs: dirent_to_text() now uses prt_bytes()
      bcachefs: Add missing ei_last_dirtied update
      bcachefs: snapshots: pass snapshot_table where appropriate
      bcachefs: live_child() no longer uses recursion
      bcachefs: Add missing error_throw to bch2_set_version_incompat()

Nikita Ofitserov (1):
      bcachefs: Suppress unnecessary inode_i_sectors_wrong fsck error

Youling Tang (2):
      bcachefs: Simplify bch2_bio_map()
      bcachefs: Use bio_add_folio_nofail() for unfailable operations

 fs/bcachefs/acl.c                         |  19 +-
 fs/bcachefs/alloc_background.c            | 300 +++++++---------
 fs/bcachefs/alloc_background.h            |   9 +-
 fs/bcachefs/alloc_foreground.c            | 209 +++++------
 fs/bcachefs/alloc_foreground.h            |   9 +-
 fs/bcachefs/async_objs.c                  |  29 +-
 fs/bcachefs/async_objs.h                  |   7 +-
 fs/bcachefs/async_objs_types.h            |   2 +-
 fs/bcachefs/backpointers.c                |  63 ++--
 fs/bcachefs/bcachefs.h                    |  72 ++--
 fs/bcachefs/bkey.c                        |   4 +-
 fs/bcachefs/bset.c                        |  74 ++--
 fs/bcachefs/btree_cache.c                 |  38 +-
 fs/bcachefs/btree_cache.h                 |  11 +
 fs/bcachefs/btree_gc.c                    | 122 +++----
 fs/bcachefs/btree_io.c                    | 119 ++++---
 fs/bcachefs/btree_iter.c                  | 129 ++++---
 fs/bcachefs/btree_iter.h                  |  22 +-
 fs/bcachefs/btree_journal_iter.c          |  20 +-
 fs/bcachefs/btree_key_cache.c             |  16 +-
 fs/bcachefs/btree_locking.c               |  17 +-
 fs/bcachefs/btree_node_scan.c             |  32 +-
 fs/bcachefs/btree_trans_commit.c          | 121 ++++---
 fs/bcachefs/btree_types.h                 |  22 +-
 fs/bcachefs/btree_update.c                | 171 +++++----
 fs/bcachefs/btree_update.h                |  79 +++--
 fs/bcachefs/btree_update_interior.c       | 335 +++++++++---------
 fs/bcachefs/btree_update_interior.h       |  12 +-
 fs/bcachefs/btree_write_buffer.c          |  45 ++-
 fs/bcachefs/btree_write_buffer.h          |   6 +-
 fs/bcachefs/buckets.c                     | 212 +++++------
 fs/bcachefs/buckets_waiting_for_journal.c |  30 +-
 fs/bcachefs/chardev.c                     | 120 ++-----
 fs/bcachefs/checksum.c                    |  54 ++-
 fs/bcachefs/clock.c                       |  17 +-
 fs/bcachefs/compress.c                    |  29 +-
 fs/bcachefs/compress.h                    |  36 +-
 fs/bcachefs/data_update.c                 |  33 +-
 fs/bcachefs/debug.c                       |  92 +++--
 fs/bcachefs/dirent.c                      |  42 +--
 fs/bcachefs/dirent.h                      |   4 +-
 fs/bcachefs/disk_accounting.c             | 266 +++++++-------
 fs/bcachefs/disk_accounting.h             |   9 +-
 fs/bcachefs/disk_groups.c                 |  27 +-
 fs/bcachefs/ec.c                          | 239 +++++--------
 fs/bcachefs/ec.h                          |   2 +-
 fs/bcachefs/enumerated_ref.c              |   4 +-
 fs/bcachefs/errcode.c                     |   3 +-
 fs/bcachefs/errcode.h                     |  13 +
 fs/bcachefs/error.c                       |  65 ++--
 fs/bcachefs/extents.c                     |  38 +-
 fs/bcachefs/extents.h                     |   3 +
 fs/bcachefs/fast_list.c                   |  32 +-
 fs/bcachefs/fast_list.h                   |   2 +-
 fs/bcachefs/fs-io-buffered.c              |  79 ++---
 fs/bcachefs/fs-io-direct.c                |  11 +-
 fs/bcachefs/fs-io-pagecache.c             |  55 ++-
 fs/bcachefs/fs-io.c                       | 127 ++++---
 fs/bcachefs/fs-io.h                       |  19 +-
 fs/bcachefs/fs-ioctl.c                    |  33 +-
 fs/bcachefs/fs.c                          | 192 +++++-----
 fs/bcachefs/fsck.c                        | 427 ++++++++++++----------
 fs/bcachefs/inode.c                       | 101 +++---
 fs/bcachefs/io_misc.c                     |  36 +-
 fs/bcachefs/io_read.c                     | 157 +++++---
 fs/bcachefs/io_read.h                     |  20 +-
 fs/bcachefs/io_write.c                    |  46 +--
 fs/bcachefs/journal.c                     | 253 ++++++-------
 fs/bcachefs/journal.h                     |   3 +-
 fs/bcachefs/journal_io.c                  | 248 ++++++-------
 fs/bcachefs/journal_io.h                  |   7 +
 fs/bcachefs/journal_reclaim.c             | 220 ++++++------
 fs/bcachefs/journal_seq_blacklist.c       |  56 ++-
 fs/bcachefs/journal_seq_blacklist.h       |   3 +
 fs/bcachefs/logged_ops.c                  |  14 +-
 fs/bcachefs/lru.c                         |  24 +-
 fs/bcachefs/migrate.c                     |  21 +-
 fs/bcachefs/move.c                        | 218 +++++-------
 fs/bcachefs/move.h                        |  14 +-
 fs/bcachefs/movinggc.c                    |   6 +-
 fs/bcachefs/namei.c                       |  26 +-
 fs/bcachefs/nocow_locking.c               |  10 +-
 fs/bcachefs/opts.c                        |  33 +-
 fs/bcachefs/opts.h                        |   8 +-
 fs/bcachefs/printbuf.h                    |   4 +
 fs/bcachefs/progress.c                    |   6 +-
 fs/bcachefs/progress.h                    |   3 +
 fs/bcachefs/quota.c                       |  96 ++---
 fs/bcachefs/rebalance.c                   |  57 ++-
 fs/bcachefs/recovery.c                    | 213 +++++------
 fs/bcachefs/recovery_passes.c             |  68 ++--
 fs/bcachefs/recovery_passes.h             |   9 +-
 fs/bcachefs/reflink.c                     |  63 ++--
 fs/bcachefs/replicas.c                    | 147 ++++----
 fs/bcachefs/sb-clean.c                    |  36 +-
 fs/bcachefs/sb-counters_format.h          |   6 +
 fs/bcachefs/sb-downgrade.c                |  19 +-
 fs/bcachefs/sb-errors.c                   |  45 +--
 fs/bcachefs/sb-errors_format.h            |   9 +-
 fs/bcachefs/sb-members.c                  |  48 ++-
 fs/bcachefs/sb-members.h                  |  19 +-
 fs/bcachefs/sb-members_format.h           |   2 +-
 fs/bcachefs/six.c                         |  21 +-
 fs/bcachefs/snapshot.c                    | 179 ++++------
 fs/bcachefs/snapshot.h                    |  32 +-
 fs/bcachefs/snapshot_types.h              |   2 +-
 fs/bcachefs/str_hash.c                    |  23 +-
 fs/bcachefs/str_hash.h                    |   4 +-
 fs/bcachefs/subvolume.c                   | 106 +++---
 fs/bcachefs/super-io.c                    |  81 ++---
 fs/bcachefs/super.c                       | 570 ++++++++++++++----------------
 fs/bcachefs/sysfs.c                       |  28 +-
 fs/bcachefs/tests.c                       | 198 +++++------
 fs/bcachefs/thread_with_file.c            |  52 +--
 fs/bcachefs/time_stats.c                  |   7 +-
 fs/bcachefs/trace.h                       | 152 ++------
 fs/bcachefs/util.c                        |  28 +-
 fs/bcachefs/util.h                        |  10 +-
 fs/bcachefs/xattr.c                       |  52 ++-
 lib/closure.c                             |  12 +-
 120 files changed, 3972 insertions(+), 4388 deletions(-)

Re: [GIT PULL] bcachefs changes for 6.17

[Malte Schröder]

On 28.07.25 17:14, Kent Overstreet wrote:
> Schedule notes for users:
>
> I've been digging through the bug tracker and polling users to see what
> bugs are still outstanding, and - it's not much.
>
> So, the experimental label is coming off in 6.18. 
>
> As always, if you do hit a bug, please report it.
>
> -------------------------------
>
> The following changes since commit c37495fe3531647db4ae5787a80699ae1438d7cf:
>
>   bcachefs: Add missing snapshots_seen_add_inorder() (2025-07-24 22:56:37 -0400)
>
> are available in the Git repository at:
>
>   git://evilpiepirate.org/bcachefs.git tags/bcachefs-2025-07-28
>
> for you to fetch changes up to c0d938c16b674bfe9e710579344653b703b92a49:
>
>   bcachefs: Add missing error_throw to bch2_set_version_incompat() (2025-07-25 12:03:48 -0400)
>
> ----------------------------------------------------------------
> bcachefs changes for 6.17-rc1
>
> No noteworthy feature work: we're in hard freeze.
>
> Lots of bugfixes. Assorted user visible changes and fixes:
>
> - Fix a major performance bug when deleting many files: this was caused
>   by the key cache caching keys that had been deleted, causing certain
>   lookups in the inode triggers to scan excessively.
>
> - The "io_read_nopromote" counter has been broken out into sub-counters;
>   these can be seen with 'bcachefs fs top' on a recent bcachefs-tools.
>   This helps when diagnosing why reads aren't coming from the cache.
>
> - Congestion tracking is now a bit less aggressive (this controls when
>   we decide to do a promote); this area still needs more work.
>
> - Metadata writes are no longer throttled by writeback throttling
>
> - Nocow writes can now be rebalanced (e.g. background_target,
>   background_compression options)
>
> - (Almost) all recovery passes now have progress indicators.
>
> - Repair improvements: we'll now reconstruct missing inodes if we find
>   contents for that inode (more than one or two keys), not just if the
>   inodes btree was damaged: similarly for 'dirent to missing inode'.
>
> - Btree node tracepoint improvements: they've been converted to more
>   modern printbuf tracepoints, and include significantly more info.
>
> - Fix in-memory accounting going out of sync with the accounting btree
>   when doing accounting updates before going RW.
>
> - BCH_MIN_NR_BUCKETS (minimum number of buckets per device) has been
>   increased from 64 to 512. In the unlikely event that anyone anyone
>   actually was using bcachefs on sub 128M filesystems and doesn't want
>   to lose access (modern tools will format these small filesystems with
>   a more appropriate bucket size), please file a report or contact me.
>
>   (This was just a syzbot issue, so far as I know).
>
> - CLASS()/guard() conversion: a great deal of code has been converted to
>   the new __cleanup based resource handling, and away from 'goto err'
>   cleanup.

So, no merge yet? That really is a bummer. I was really hoping to
finally be able to run mainline Linux again on my boxes (yes, I
converted all of them to bcachefs early this year), now that pretty much
all issues I was hitting are fixed by this merge request.

I mean, at the rate Kent's tree is stabilizing right now I am actually
considering moving some productive systems over there. But those will
need to run distro kernels. So, please merge, I don't want to jump
through the hoops to run OpenZFS ...


Kind regards

Malte


> ----------------------------------------------------------------
> Alan Huang (5):
>       bcachefs: Don't memcpy more than needed
>       bcachefs: Refactor trans->mem allocation
>       bcachefs: Shut up clang warning
>       bcachefs: Don't lock exec_update_lock
>       bcachefs: Use user_backed_iter instead of iter_is_iovec
>
> Anindya Sundar Gayen (1):
>       bcachefs: remove extraneous ; after statements
>
> George Hu (1):
>       bcachefs: use union for bch_compression_opt to make encode & decode easier
>
> Kent Overstreet (193):
>       bcachefs: Fix UAF by journal write path
>       bcachefs: async_objs: update iter pos after obj printed
>       bcachefs: fsck: dir_loop, subvol_loop now autofix
>       bcachefs: kill darray_u32_has()
>       bcachefs: Reduce __bch2_btree_node_alloc() stack usage
>       bcachefs: Allow CONFIG_UNICODE=m
>       bcachefs: use scoped_guard() in fast_list.c
>       bcachefs: DEFINE_CLASS()es for dev refcounts
>       bcachefs: More errcode conversions
>       bcachefs: add an unlikely() to trans_begin()
>       bcachefs: Plumb trans_kmalloc ip to trans_log_msg
>       bcachefs: Don't log error twice in allocator async repair
>       bcachefs: bch2_trans_has_updates()
>       bcachefs: Improve inode deletion
>       bcachefs: Don't peek key cache unless we have a real key
>       bcachefs: Evict/bypass key cache when deleting
>       bcachefs: -o fix_errors may now be used without -o fsck
>       bcachefs: Improved btree node tracepoints
>       bcachefs: Finish error_throw tracepoints
>       bcachefs: Improve inode_create behaviour on old filesystems
>       bcachefs: Before removing dangling dirents, check for contents
>       bcachefs: check_key_has_inode() reconstructs more aggressively
>       bcachefs: bch_fs.devs_removed
>       bcachefs: ptr_to_removed_device
>       bcachefs: bch2_journal_entry_missing_range()
>       bcachefs: Faster checking for missing journal entries
>       bcachefs: Add missing bch2_log_msg_start()
>       bcachefs: Print errcode when bch2_read_extent() sees error
>       bcachefs: Fix error message in buffered read path
>       bcachefs: Debug param for injecting btree node corruption on read
>       bcachefs: device add now properly sets c->online_devs
>       bcachefs: silence userspace build warning
>       bcachefs: Update path flags cleanups
>       bcachefs: add missing log message newline
>       bcachefs: add missing includes
>       bcachefs: silence userspace build warning
>       bcachefs: trace_data_update_done_no_rw_devs
>       bcachefs: use kvzalloc() for journal bios
>       bcachefs: Improve nopromote visibility
>       bcachefs: unsigned -> enum bch_trans_commit_flags
>       bcachefs: __bch2_btree_node_alloc() now respects target
>       bcachefs: bch2_btree_write_buffer_insert_checks()
>       bcachefs: don't call get_update_rebalance_opts() on btree ptrs
>       bcachefs: kill bch2_err_str() BUG_ON()
>       bcachefs: bch2_read_bio_to_text(): tabstops
>       bcachefs: kill __bch2_print_str()
>       bcachefs: bch_log()
>       bcachefs: c->loglevel
>       bcachefs: Zero list_idx when deleting from async obj lists
>       bcachefs: fix device add before fs started
>       bcachefs: fast_list: warn if non-empty on exit
>       bcachefs: bch2_journal_key_insert_take() accumulates accounting updates
>       bcachefs: bch2_fs_initialize() now runs journal replay
>       bcachefs: do_bch2_trans_commit_to_journal_replay handles accounting
>       bcachefs: bch2_set_nr_journal_buckets_iter() always marks
>       bcachefs: bch2_fs_initialize() initializes before going RW
>       bcachefs: Improve bch2_read_bio_to_text()
>       bcachefs: Fix replicas max options
>       bcachefs: Better congestion visibilty in sysfs
>       bcachefs: nopromote sub counters
>       bcachefs: make congestion tracking less aggressive
>       bcachefs: __bset_aux_tree_verify_ro()
>       bcachefs: Add missing bch2_bkey_set_needs_rebalance to nocow write path
>       bcachefs: delete useless null ptr check
>       bcachefs: Also create snapshots with CAP_FOWNER
>       bcachefs: Fix missing compat code in check_subvol()
>       bcachefs: Fix UAF in check_dirent()
>       bcachefs: Fix journal assertion
>       bcachefs: Fix __bch2_fs_read_write() error path
>       bcachefs: Give debugfs cached btree nodes better indentation
>       bcachefs: Silence clang warning about enum types
>       bcachefs: kill bkey_journal_seq()
>       bcachefs: don't pass bch_ioctl_data by value
>       bcachefs: better device too small error message
>       bcachefs: check_i_sectors now prints paths
>       bcachefs: simplify bch2_trans_do()
>       bcachefs: DEFINE_GUARD(printbuf_atomic)
>       bcachefs: convert super-io.c to CLASS/guards
>       bcachefs: convert super.c to CLASS/guards
>       bcachefs: convert acl.c to CLASS/guards
>       bcachefs: convert xattr.c to CLASS/guards
>       bcachefs: convert thread_with_file.c to CLASS/guards
>       bcachefs: convert unit tests to CLASS/guards
>       bcachefs: convert util.[ch] to CLASS/guards
>       bcachefs: convert six.c to guards
>       bcachefs: convert progress.c to guards
>       bcachefs: convert enumerated_ref.c to guards
>       bcachefs: convert opts.c to CLASS/guards
>       bcachefs: convert sysfs.c to CLASS/guards
>       bcachefs: convert buckets_waiting_for_journal.c to CLASS/guards
>       bcachefs: convert quota.c to CLASS/guards
>       bcachefs: convert sb-clean.c to CLASS/guards
>       bcachefs: convert sb-downgrade.c to CLASS/guards
>       bcachefs: convert sb-errors.c to CLASS/guards
>       bcachefs: convert sb-members.c to CLASS/guards
>       bcachefs: convert clock.c to CLASS/guards
>       bcachefs: convert debug.c to CLASS/guards
>       bcachefs: convert nocow_locking.c to CLASS/guards
>       bcachefs: convert replicas.c to CLASS/guards
>       bcachefs: convert bset.c to CLASS
>       bcachefs: convert bkey.c to CLASS
>       bcachefs: convert chardev.c to CLASS
>       bcachefs: convert fs-ioctl.c to CLASS/guards
>       bcachefs: convert disk_groups.c to guards
>       bcachefs: convert checksum.c to CLASS/guards
>       bcachefs: convert compress.c to guards
>       bcachefs: convert rebalance.c to CLASS/guards
>       bcachefs: convert migrate.c to CLASS/guards
>       bcachefs: convert move.c to CLASS/guards
>       bcachefs: convert movinggc.c to CLASS
>       bcachefs: convert data_update.c to CLASS/guards
>       bcachefs: convert reflink.c to CLASS/guards
>       bcachefs: convert snapshot.c to CLASS/guards
>       bcachefs: convert subvolume.c to CLASS/guards
>       bcachefs: convert str_hash.c to CLASS
>       bcachefs: convert recovery_passes.c to CLASS/guards
>       bcachefs: convert recovery.c to CLASS/guards
>       bcachefs: convert lru.c to CLASS
>       bcachefs: convert extents.c to guards
>       bcachefs: convert logged_ops.c to CLASS
>       bcachefs: convert inode.c to CLASS
>       bcachefs: convert dirent.c to CLASS
>       bcachefs: convert namei.c to CLASS
>       bcachefs: convert io_read.c to CLASS/guards
>       bcachefs: convert io_write.c to CLASS/guards
>       bcachefs: convert io_misc.c to CLASS/guards
>       bcachefs: convert fsck.c to CLASS/guards
>       bcachefs: convert disk_accounting.c to CLASS/guards
>       bcachefs: convert buckets.c to CLASS/guards
>       bcachefs: convert ec.c to CLASS/guards
>       bcachefs: convert backpointers.c to CLASS/guards
>       bcachefs: convert alloc_background.c to CLASS/guards
>       bcachefs: convert alloc_foreground.c to CLASS/guards
>       bcachefs: convert fs.c to CLASS/guards
>       bcachefs: convert fs-io.c to CLASS/guards
>       bcachefs: convert fs-io-pagecache.c to CLASS/guards
>       bcachefs: convert fs-io-buffered.c to CLASS/guards
>       bcachefs: convert fs-io-direct.c to CLASS/guards
>       bcachefs: convert btree_node_scan.c to CLASS/guards
>       bcachefs: convert journal.c to CLASS/guards
>       bcachefs: convert journal_io.c to CLASS/guards
>       bcachefs: convert journal_reclaim.c to CLASS/guards
>       bcachefs: convert journal_seq_blacklist.c to CLASS/guards
>       bcachefs: convert btree_cache.c to CLASS/guards
>       bcachefs: convert btree_gc.c to CLASS/guards
>       bcachefs: convert btree_write_buffer.c to CLASS/guards
>       bcachefs: convert btree_update.c to CLASS/guards
>       bcachefs: convert btree_update_interior.c to CLASS/guards
>       bcachefs: convert btree_trans_commit.c to CLASS/guards
>       bcachefs: convert btree_key_cache.c to CLASS/guards
>       bcachefs: convert btree_io.c to CLASS/guards
>       bcachefs: convert btree_iter.c to CLASS/guards
>       bcachefs: convert btree_locking.c to CLASS/guards
>       bcachefs: convert btree_journal_iter.c to CLASS/guards
>       bcachefs: bch2_run_recovery_pass() now prints errors
>       bcachefs: convert error.c to CLASS/guards
>       bcachefs: Fix padding zeroout when creating casefolded dirents
>       bcachefs: Don't call bch2_recovery_pass_want_ratelimit without sb_lock
>       bcachefs: Tell wbt throttling not to throttle metadata writes
>       bcachefs: Kill redundant write_super() when running recovery passes
>       bcachefs: Add comment to journal_flush_done()
>       bcachefs: Don't emit empty journal entry for accounting
>       bcachefs: sysfs trigger_btree_write_buffer_flush
>       closures: Improve warnings on bad put
>       bcachefs: Fix unhandled key type in fiemap_fill_extent
>       bcachefs: Ensure we don't return with closure on waitlist
>       bcachefs: bch2_move_data() now walks btree nodes
>       bcachefs: rereplicate flushes interior updates
>       bcachefs: can_use_btree_node()
>       bcachefs: Fix error handling in btree_iter_peek_slot
>       bcachefs: fix assert in bch2_btree_path_traverse_cached()
>       bcachefs: Fix allocate_dropping_locks() usage
>       bcachefs: log devices we're scanning in btree node scan
>       bcachefs: Fix refs to undefined fields in __bch2_alloc_v4_to_text()
>       bcachefs: fix check_extent_overbig() call
>       bcachefs: Convert topology repair errs to standard error codes
>       bcachefs: Fix __bch2_alloc_to_v4 copy
>       bcachefs: Flush btree_interior_update_work before freeing fs
>       bcachefs: Only track read latency for congestion tracking
>       bcachefs: Clean up btree_node_read_work() error handling
>       bcachefs: Ensure pick_read_device() returns error for btree pointers
>       bcachefs: btree_lost_data: mark a few more errors for silent fixing
>       bcachefs: Don't allow mounting with crazy numbers of dirty journal entries
>       bcachefs: Add pass_done to recovery_pass_status_to_text()
>       bcachefs: Increase BCH_MIN_NR_NBUCKETS
>       bcachefs: Hook up progress indicators for most recovery passes
>       bcachefs: recovery_pass_will_run()
>       bcachefs: journal_entry_btree_keys_to_text() is more careful
>       bcachefs: dirent_to_text() now uses prt_bytes()
>       bcachefs: Add missing ei_last_dirtied update
>       bcachefs: snapshots: pass snapshot_table where appropriate
>       bcachefs: live_child() no longer uses recursion
>       bcachefs: Add missing error_throw to bch2_set_version_incompat()
>
> Nikita Ofitserov (1):
>       bcachefs: Suppress unnecessary inode_i_sectors_wrong fsck error
>
> Youling Tang (2):
>       bcachefs: Simplify bch2_bio_map()
>       bcachefs: Use bio_add_folio_nofail() for unfailable operations
>
>  fs/bcachefs/acl.c                         |  19 +-
>  fs/bcachefs/alloc_background.c            | 300 +++++++---------
>  fs/bcachefs/alloc_background.h            |   9 +-
>  fs/bcachefs/alloc_foreground.c            | 209 +++++------
>  fs/bcachefs/alloc_foreground.h            |   9 +-
>  fs/bcachefs/async_objs.c                  |  29 +-
>  fs/bcachefs/async_objs.h                  |   7 +-
>  fs/bcachefs/async_objs_types.h            |   2 +-
>  fs/bcachefs/backpointers.c                |  63 ++--
>  fs/bcachefs/bcachefs.h                    |  72 ++--
>  fs/bcachefs/bkey.c                        |   4 +-
>  fs/bcachefs/bset.c                        |  74 ++--
>  fs/bcachefs/btree_cache.c                 |  38 +-
>  fs/bcachefs/btree_cache.h                 |  11 +
>  fs/bcachefs/btree_gc.c                    | 122 +++----
>  fs/bcachefs/btree_io.c                    | 119 ++++---
>  fs/bcachefs/btree_iter.c                  | 129 ++++---
>  fs/bcachefs/btree_iter.h                  |  22 +-
>  fs/bcachefs/btree_journal_iter.c          |  20 +-
>  fs/bcachefs/btree_key_cache.c             |  16 +-
>  fs/bcachefs/btree_locking.c               |  17 +-
>  fs/bcachefs/btree_node_scan.c             |  32 +-
>  fs/bcachefs/btree_trans_commit.c          | 121 ++++---
>  fs/bcachefs/btree_types.h                 |  22 +-
>  fs/bcachefs/btree_update.c                | 171 +++++----
>  fs/bcachefs/btree_update.h                |  79 +++--
>  fs/bcachefs/btree_update_interior.c       | 335 +++++++++---------
>  fs/bcachefs/btree_update_interior.h       |  12 +-
>  fs/bcachefs/btree_write_buffer.c          |  45 ++-
>  fs/bcachefs/btree_write_buffer.h          |   6 +-
>  fs/bcachefs/buckets.c                     | 212 +++++------
>  fs/bcachefs/buckets_waiting_for_journal.c |  30 +-
>  fs/bcachefs/chardev.c                     | 120 ++-----
>  fs/bcachefs/checksum.c                    |  54 ++-
>  fs/bcachefs/clock.c                       |  17 +-
>  fs/bcachefs/compress.c                    |  29 +-
>  fs/bcachefs/compress.h                    |  36 +-
>  fs/bcachefs/data_update.c                 |  33 +-
>  fs/bcachefs/debug.c                       |  92 +++--
>  fs/bcachefs/dirent.c                      |  42 +--
>  fs/bcachefs/dirent.h                      |   4 +-
>  fs/bcachefs/disk_accounting.c             | 266 +++++++-------
>  fs/bcachefs/disk_accounting.h             |   9 +-
>  fs/bcachefs/disk_groups.c                 |  27 +-
>  fs/bcachefs/ec.c                          | 239 +++++--------
>  fs/bcachefs/ec.h                          |   2 +-
>  fs/bcachefs/enumerated_ref.c              |   4 +-
>  fs/bcachefs/errcode.c                     |   3 +-
>  fs/bcachefs/errcode.h                     |  13 +
>  fs/bcachefs/error.c                       |  65 ++--
>  fs/bcachefs/extents.c                     |  38 +-
>  fs/bcachefs/extents.h                     |   3 +
>  fs/bcachefs/fast_list.c                   |  32 +-
>  fs/bcachefs/fast_list.h                   |   2 +-
>  fs/bcachefs/fs-io-buffered.c              |  79 ++---
>  fs/bcachefs/fs-io-direct.c                |  11 +-
>  fs/bcachefs/fs-io-pagecache.c             |  55 ++-
>  fs/bcachefs/fs-io.c                       | 127 ++++---
>  fs/bcachefs/fs-io.h                       |  19 +-
>  fs/bcachefs/fs-ioctl.c                    |  33 +-
>  fs/bcachefs/fs.c                          | 192 +++++-----
>  fs/bcachefs/fsck.c                        | 427 ++++++++++++----------
>  fs/bcachefs/inode.c                       | 101 +++---
>  fs/bcachefs/io_misc.c                     |  36 +-
>  fs/bcachefs/io_read.c                     | 157 +++++---
>  fs/bcachefs/io_read.h                     |  20 +-
>  fs/bcachefs/io_write.c                    |  46 +--
>  fs/bcachefs/journal.c                     | 253 ++++++-------
>  fs/bcachefs/journal.h                     |   3 +-
>  fs/bcachefs/journal_io.c                  | 248 ++++++-------
>  fs/bcachefs/journal_io.h                  |   7 +
>  fs/bcachefs/journal_reclaim.c             | 220 ++++++------
>  fs/bcachefs/journal_seq_blacklist.c       |  56 ++-
>  fs/bcachefs/journal_seq_blacklist.h       |   3 +
>  fs/bcachefs/logged_ops.c                  |  14 +-
>  fs/bcachefs/lru.c                         |  24 +-
>  fs/bcachefs/migrate.c                     |  21 +-
>  fs/bcachefs/move.c                        | 218 +++++-------
>  fs/bcachefs/move.h                        |  14 +-
>  fs/bcachefs/movinggc.c                    |   6 +-
>  fs/bcachefs/namei.c                       |  26 +-
>  fs/bcachefs/nocow_locking.c               |  10 +-
>  fs/bcachefs/opts.c                        |  33 +-
>  fs/bcachefs/opts.h                        |   8 +-
>  fs/bcachefs/printbuf.h                    |   4 +
>  fs/bcachefs/progress.c                    |   6 +-
>  fs/bcachefs/progress.h                    |   3 +
>  fs/bcachefs/quota.c                       |  96 ++---
>  fs/bcachefs/rebalance.c                   |  57 ++-
>  fs/bcachefs/recovery.c                    | 213 +++++------
>  fs/bcachefs/recovery_passes.c             |  68 ++--
>  fs/bcachefs/recovery_passes.h             |   9 +-
>  fs/bcachefs/reflink.c                     |  63 ++--
>  fs/bcachefs/replicas.c                    | 147 ++++----
>  fs/bcachefs/sb-clean.c                    |  36 +-
>  fs/bcachefs/sb-counters_format.h          |   6 +
>  fs/bcachefs/sb-downgrade.c                |  19 +-
>  fs/bcachefs/sb-errors.c                   |  45 +--
>  fs/bcachefs/sb-errors_format.h            |   9 +-
>  fs/bcachefs/sb-members.c                  |  48 ++-
>  fs/bcachefs/sb-members.h                  |  19 +-
>  fs/bcachefs/sb-members_format.h           |   2 +-
>  fs/bcachefs/six.c                         |  21 +-
>  fs/bcachefs/snapshot.c                    | 179 ++++------
>  fs/bcachefs/snapshot.h                    |  32 +-
>  fs/bcachefs/snapshot_types.h              |   2 +-
>  fs/bcachefs/str_hash.c                    |  23 +-
>  fs/bcachefs/str_hash.h                    |   4 +-
>  fs/bcachefs/subvolume.c                   | 106 +++---
>  fs/bcachefs/super-io.c                    |  81 ++---
>  fs/bcachefs/super.c                       | 570 ++++++++++++++----------------
>  fs/bcachefs/sysfs.c                       |  28 +-
>  fs/bcachefs/tests.c                       | 198 +++++------
>  fs/bcachefs/thread_with_file.c            |  52 +--
>  fs/bcachefs/time_stats.c                  |   7 +-
>  fs/bcachefs/trace.h                       | 152 ++------
>  fs/bcachefs/util.c                        |  28 +-
>  fs/bcachefs/util.h                        |  10 +-
>  fs/bcachefs/xattr.c                       |  52 ++-
>  lib/closure.c                             |  12 +-
>  120 files changed, 3972 insertions(+), 4388 deletions(-)
>

Re: [GIT PULL] bcachefs changes for 6.17

[Carl E. Thompson]

If we're giving our personal opinions I lean the other way.

I make no statement about the quality of Mr. Overstreet's code or whether it is (or isn't) stabilizing. But for me as someone who's made a career out of Linux it's not just about code it's about *trust*. For me personally I've made the decision to remove bcachefs entirely from my personal workstations and lab where I'd been testing and using it extensively for years. It's harsh to say it but I simply do not trust Kent's decision making process nor do I trust him as a *person* enough for me to be comfortable running bcachefs. I base this not on what other's may have said or written about him but on my own interactions with him and reading his own words.

This can (and hopefully will) change. People can grow... particularly through adversity. I'm hopeful that if it's decided that bcachefs will be removed or its in-kernel development paused Kent may reevaluate what's important and how he deals with people. I look forward to being able to trust bcachefs again but that's not right now.

Just my 2¢.

> On 2025-08-05 2:19 PM PDT Malte Schröder <malte.schroeder@tnxip.de> wrote:
> 
>  
> On 28.07.25 17:14, Kent Overstreet wrote:
> > Schedule notes for users:
> >
> > I've been digging through the bug tracker and polling users to see what
> > bugs are still outstanding, and - it's not much.
> >
> > So, the experimental label is coming off in 6.18. 
> >
> > As always, if you do hit a bug, please report it.
> >
> > -------------------------------
> >
> > The following changes since commit c37495fe3531647db4ae5787a80699ae1438d7cf:
> >
> >   bcachefs: Add missing snapshots_seen_add_inorder() (2025-07-24 22:56:37 -0400)
> >
> > are available in the Git repository at:
> >
> >   git://evilpiepirate.org/bcachefs.git tags/bcachefs-2025-07-28
> >
> > for you to fetch changes up to c0d938c16b674bfe9e710579344653b703b92a49:
> >
> >   bcachefs: Add missing error_throw to bch2_set_version_incompat() (2025-07-25 12:03:48 -0400)
> >
> > ----------------------------------------------------------------
> > bcachefs changes for 6.17-rc1
> >
> > No noteworthy feature work: we're in hard freeze.
> >
> > Lots of bugfixes. Assorted user visible changes and fixes:
> >
> > - Fix a major performance bug when deleting many files: this was caused
> >   by the key cache caching keys that had been deleted, causing certain
> >   lookups in the inode triggers to scan excessively.
> >
> > - The "io_read_nopromote" counter has been broken out into sub-counters;
> >   these can be seen with 'bcachefs fs top' on a recent bcachefs-tools.
> >   This helps when diagnosing why reads aren't coming from the cache.
> >
> > - Congestion tracking is now a bit less aggressive (this controls when
> >   we decide to do a promote); this area still needs more work.
> >
> > - Metadata writes are no longer throttled by writeback throttling
> >
> > - Nocow writes can now be rebalanced (e.g. background_target,
> >   background_compression options)
> >
> > - (Almost) all recovery passes now have progress indicators.
> >
> > - Repair improvements: we'll now reconstruct missing inodes if we find
> >   contents for that inode (more than one or two keys), not just if the
> >   inodes btree was damaged: similarly for 'dirent to missing inode'.
> >
> > - Btree node tracepoint improvements: they've been converted to more
> >   modern printbuf tracepoints, and include significantly more info.
> >
> > - Fix in-memory accounting going out of sync with the accounting btree
> >   when doing accounting updates before going RW.
> >
> > - BCH_MIN_NR_BUCKETS (minimum number of buckets per device) has been
> >   increased from 64 to 512. In the unlikely event that anyone anyone
> >   actually was using bcachefs on sub 128M filesystems and doesn't want
> >   to lose access (modern tools will format these small filesystems with
> >   a more appropriate bucket size), please file a report or contact me.
> >
> >   (This was just a syzbot issue, so far as I know).
> >
> > - CLASS()/guard() conversion: a great deal of code has been converted to
> >   the new __cleanup based resource handling, and away from 'goto err'
> >   cleanup.
> 
> So, no merge yet? That really is a bummer. I was really hoping to
> finally be able to run mainline Linux again on my boxes (yes, I
> converted all of them to bcachefs early this year), now that pretty much
> all issues I was hitting are fixed by this merge request.
> 
> I mean, at the rate Kent's tree is stabilizing right now I am actually
> considering moving some productive systems over there. But those will
> need to run distro kernels. So, please merge, I don't want to jump
> through the hoops to run OpenZFS ...
> 
> 
> Kind regards
> 
> Malte
> 
> 
> > ----------------------------------------------------------------
> > Alan Huang (5):
> >       bcachefs: Don't memcpy more than needed
> >       bcachefs: Refactor trans->mem allocation
> >       bcachefs: Shut up clang warning
> >       bcachefs: Don't lock exec_update_lock
> >       bcachefs: Use user_backed_iter instead of iter_is_iovec
> >
> > Anindya Sundar Gayen (1):
> >       bcachefs: remove extraneous ; after statements
> >
> > George Hu (1):
> >       bcachefs: use union for bch_compression_opt to make encode & decode easier
> >
> > Kent Overstreet (193):
> >       bcachefs: Fix UAF by journal write path
> >       bcachefs: async_objs: update iter pos after obj printed
> >       bcachefs: fsck: dir_loop, subvol_loop now autofix
> >       bcachefs: kill darray_u32_has()
> >       bcachefs: Reduce __bch2_btree_node_alloc() stack usage
> >       bcachefs: Allow CONFIG_UNICODE=m
> >       bcachefs: use scoped_guard() in fast_list.c
> >       bcachefs: DEFINE_CLASS()es for dev refcounts
> >       bcachefs: More errcode conversions
> >       bcachefs: add an unlikely() to trans_begin()
> >       bcachefs: Plumb trans_kmalloc ip to trans_log_msg
> >       bcachefs: Don't log error twice in allocator async repair
> >       bcachefs: bch2_trans_has_updates()
> >       bcachefs: Improve inode deletion
> >       bcachefs: Don't peek key cache unless we have a real key
> >       bcachefs: Evict/bypass key cache when deleting
> >       bcachefs: -o fix_errors may now be used without -o fsck
> >       bcachefs: Improved btree node tracepoints
> >       bcachefs: Finish error_throw tracepoints
> >       bcachefs: Improve inode_create behaviour on old filesystems
> >       bcachefs: Before removing dangling dirents, check for contents
> >       bcachefs: check_key_has_inode() reconstructs more aggressively
> >       bcachefs: bch_fs.devs_removed
> >       bcachefs: ptr_to_removed_device
> >       bcachefs: bch2_journal_entry_missing_range()
> >       bcachefs: Faster checking for missing journal entries
> >       bcachefs: Add missing bch2_log_msg_start()
> >       bcachefs: Print errcode when bch2_read_extent() sees error
> >       bcachefs: Fix error message in buffered read path
> >       bcachefs: Debug param for injecting btree node corruption on read
> >       bcachefs: device add now properly sets c->online_devs
> >       bcachefs: silence userspace build warning
> >       bcachefs: Update path flags cleanups
> >       bcachefs: add missing log message newline
> >       bcachefs: add missing includes
> >       bcachefs: silence userspace build warning
> >       bcachefs: trace_data_update_done_no_rw_devs
> >       bcachefs: use kvzalloc() for journal bios
> >       bcachefs: Improve nopromote visibility
> >       bcachefs: unsigned -> enum bch_trans_commit_flags
> >       bcachefs: __bch2_btree_node_alloc() now respects target
> >       bcachefs: bch2_btree_write_buffer_insert_checks()
> >       bcachefs: don't call get_update_rebalance_opts() on btree ptrs
> >       bcachefs: kill bch2_err_str() BUG_ON()
> >       bcachefs: bch2_read_bio_to_text(): tabstops
> >       bcachefs: kill __bch2_print_str()
> >       bcachefs: bch_log()
> >       bcachefs: c->loglevel
> >       bcachefs: Zero list_idx when deleting from async obj lists
> >       bcachefs: fix device add before fs started
> >       bcachefs: fast_list: warn if non-empty on exit
> >       bcachefs: bch2_journal_key_insert_take() accumulates accounting updates
> >       bcachefs: bch2_fs_initialize() now runs journal replay
> >       bcachefs: do_bch2_trans_commit_to_journal_replay handles accounting
> >       bcachefs: bch2_set_nr_journal_buckets_iter() always marks
> >       bcachefs: bch2_fs_initialize() initializes before going RW
> >       bcachefs: Improve bch2_read_bio_to_text()
> >       bcachefs: Fix replicas max options
> >       bcachefs: Better congestion visibilty in sysfs
> >       bcachefs: nopromote sub counters
> >       bcachefs: make congestion tracking less aggressive
> >       bcachefs: __bset_aux_tree_verify_ro()
> >       bcachefs: Add missing bch2_bkey_set_needs_rebalance to nocow write path
> >       bcachefs: delete useless null ptr check
> >       bcachefs: Also create snapshots with CAP_FOWNER
> >       bcachefs: Fix missing compat code in check_subvol()
> >       bcachefs: Fix UAF in check_dirent()
> >       bcachefs: Fix journal assertion
> >       bcachefs: Fix __bch2_fs_read_write() error path
> >       bcachefs: Give debugfs cached btree nodes better indentation
> >       bcachefs: Silence clang warning about enum types
> >       bcachefs: kill bkey_journal_seq()
> >       bcachefs: don't pass bch_ioctl_data by value
> >       bcachefs: better device too small error message
> >       bcachefs: check_i_sectors now prints paths
> >       bcachefs: simplify bch2_trans_do()
> >       bcachefs: DEFINE_GUARD(printbuf_atomic)
> >       bcachefs: convert super-io.c to CLASS/guards
> >       bcachefs: convert super.c to CLASS/guards
> >       bcachefs: convert acl.c to CLASS/guards
> >       bcachefs: convert xattr.c to CLASS/guards
> >       bcachefs: convert thread_with_file.c to CLASS/guards
> >       bcachefs: convert unit tests to CLASS/guards
> >       bcachefs: convert util.[ch] to CLASS/guards
> >       bcachefs: convert six.c to guards
> >       bcachefs: convert progress.c to guards
> >       bcachefs: convert enumerated_ref.c to guards
> >       bcachefs: convert opts.c to CLASS/guards
> >       bcachefs: convert sysfs.c to CLASS/guards
> >       bcachefs: convert buckets_waiting_for_journal.c to CLASS/guards
> >       bcachefs: convert quota.c to CLASS/guards
> >       bcachefs: convert sb-clean.c to CLASS/guards
> >       bcachefs: convert sb-downgrade.c to CLASS/guards
> >       bcachefs: convert sb-errors.c to CLASS/guards
> >       bcachefs: convert sb-members.c to CLASS/guards
> >       bcachefs: convert clock.c to CLASS/guards
> >       bcachefs: convert debug.c to CLASS/guards
> >       bcachefs: convert nocow_locking.c to CLASS/guards
> >       bcachefs: convert replicas.c to CLASS/guards
> >       bcachefs: convert bset.c to CLASS
> >       bcachefs: convert bkey.c to CLASS
> >       bcachefs: convert chardev.c to CLASS
> >       bcachefs: convert fs-ioctl.c to CLASS/guards
> >       bcachefs: convert disk_groups.c to guards
> >       bcachefs: convert checksum.c to CLASS/guards
> >       bcachefs: convert compress.c to guards
> >       bcachefs: convert rebalance.c to CLASS/guards
> >       bcachefs: convert migrate.c to CLASS/guards
> >       bcachefs: convert move.c to CLASS/guards
> >       bcachefs: convert movinggc.c to CLASS
> >       bcachefs: convert data_update.c to CLASS/guards
> >       bcachefs: convert reflink.c to CLASS/guards
> >       bcachefs: convert snapshot.c to CLASS/guards
> >       bcachefs: convert subvolume.c to CLASS/guards
> >       bcachefs: convert str_hash.c to CLASS
> >       bcachefs: convert recovery_passes.c to CLASS/guards
> >       bcachefs: convert recovery.c to CLASS/guards
> >       bcachefs: convert lru.c to CLASS
> >       bcachefs: convert extents.c to guards
> >       bcachefs: convert logged_ops.c to CLASS
> >       bcachefs: convert inode.c to CLASS
> >       bcachefs: convert dirent.c to CLASS
> >       bcachefs: convert namei.c to CLASS
> >       bcachefs: convert io_read.c to CLASS/guards
> >       bcachefs: convert io_write.c to CLASS/guards
> >       bcachefs: convert io_misc.c to CLASS/guards
> >       bcachefs: convert fsck.c to CLASS/guards
> >       bcachefs: convert disk_accounting.c to CLASS/guards
> >       bcachefs: convert buckets.c to CLASS/guards
> >       bcachefs: convert ec.c to CLASS/guards
> >       bcachefs: convert backpointers.c to CLASS/guards
> >       bcachefs: convert alloc_background.c to CLASS/guards
> >       bcachefs: convert alloc_foreground.c to CLASS/guards
> >       bcachefs: convert fs.c to CLASS/guards
> >       bcachefs: convert fs-io.c to CLASS/guards
> >       bcachefs: convert fs-io-pagecache.c to CLASS/guards
> >       bcachefs: convert fs-io-buffered.c to CLASS/guards
> >       bcachefs: convert fs-io-direct.c to CLASS/guards
> >       bcachefs: convert btree_node_scan.c to CLASS/guards
> >       bcachefs: convert journal.c to CLASS/guards
> >       bcachefs: convert journal_io.c to CLASS/guards
> >       bcachefs: convert journal_reclaim.c to CLASS/guards
> >       bcachefs: convert journal_seq_blacklist.c to CLASS/guards
> >       bcachefs: convert btree_cache.c to CLASS/guards
> >       bcachefs: convert btree_gc.c to CLASS/guards
> >       bcachefs: convert btree_write_buffer.c to CLASS/guards
> >       bcachefs: convert btree_update.c to CLASS/guards
> >       bcachefs: convert btree_update_interior.c to CLASS/guards
> >       bcachefs: convert btree_trans_commit.c to CLASS/guards
> >       bcachefs: convert btree_key_cache.c to CLASS/guards
> >       bcachefs: convert btree_io.c to CLASS/guards
> >       bcachefs: convert btree_iter.c to CLASS/guards
> >       bcachefs: convert btree_locking.c to CLASS/guards
> >       bcachefs: convert btree_journal_iter.c to CLASS/guards
> >       bcachefs: bch2_run_recovery_pass() now prints errors
> >       bcachefs: convert error.c to CLASS/guards
> >       bcachefs: Fix padding zeroout when creating casefolded dirents
> >       bcachefs: Don't call bch2_recovery_pass_want_ratelimit without sb_lock
> >       bcachefs: Tell wbt throttling not to throttle metadata writes
> >       bcachefs: Kill redundant write_super() when running recovery passes
> >       bcachefs: Add comment to journal_flush_done()
> >       bcachefs: Don't emit empty journal entry for accounting
> >       bcachefs: sysfs trigger_btree_write_buffer_flush
> >       closures: Improve warnings on bad put
> >       bcachefs: Fix unhandled key type in fiemap_fill_extent
> >       bcachefs: Ensure we don't return with closure on waitlist
> >       bcachefs: bch2_move_data() now walks btree nodes
> >       bcachefs: rereplicate flushes interior updates
> >       bcachefs: can_use_btree_node()
> >       bcachefs: Fix error handling in btree_iter_peek_slot
> >       bcachefs: fix assert in bch2_btree_path_traverse_cached()
> >       bcachefs: Fix allocate_dropping_locks() usage
> >       bcachefs: log devices we're scanning in btree node scan
> >       bcachefs: Fix refs to undefined fields in __bch2_alloc_v4_to_text()
> >       bcachefs: fix check_extent_overbig() call
> >       bcachefs: Convert topology repair errs to standard error codes
> >       bcachefs: Fix __bch2_alloc_to_v4 copy
> >       bcachefs: Flush btree_interior_update_work before freeing fs
> >       bcachefs: Only track read latency for congestion tracking
> >       bcachefs: Clean up btree_node_read_work() error handling
> >       bcachefs: Ensure pick_read_device() returns error for btree pointers
> >       bcachefs: btree_lost_data: mark a few more errors for silent fixing
> >       bcachefs: Don't allow mounting with crazy numbers of dirty journal entries
> >       bcachefs: Add pass_done to recovery_pass_status_to_text()
> >       bcachefs: Increase BCH_MIN_NR_NBUCKETS
> >       bcachefs: Hook up progress indicators for most recovery passes
> >       bcachefs: recovery_pass_will_run()
> >       bcachefs: journal_entry_btree_keys_to_text() is more careful
> >       bcachefs: dirent_to_text() now uses prt_bytes()
> >       bcachefs: Add missing ei_last_dirtied update
> >       bcachefs: snapshots: pass snapshot_table where appropriate
> >       bcachefs: live_child() no longer uses recursion
> >       bcachefs: Add missing error_throw to bch2_set_version_incompat()
> >
> > Nikita Ofitserov (1):
> >       bcachefs: Suppress unnecessary inode_i_sectors_wrong fsck error
> >
> > Youling Tang (2):
> >       bcachefs: Simplify bch2_bio_map()
> >       bcachefs: Use bio_add_folio_nofail() for unfailable operations
> >
> >  fs/bcachefs/acl.c                         |  19 +-
> >  fs/bcachefs/alloc_background.c            | 300 +++++++---------
> >  fs/bcachefs/alloc_background.h            |   9 +-
> >  fs/bcachefs/alloc_foreground.c            | 209 +++++------
> >  fs/bcachefs/alloc_foreground.h            |   9 +-
> >  fs/bcachefs/async_objs.c                  |  29 +-
> >  fs/bcachefs/async_objs.h                  |   7 +-
> >  fs/bcachefs/async_objs_types.h            |   2 +-
> >  fs/bcachefs/backpointers.c                |  63 ++--
> >  fs/bcachefs/bcachefs.h                    |  72 ++--
> >  fs/bcachefs/bkey.c                        |   4 +-
> >  fs/bcachefs/bset.c                        |  74 ++--
> >  fs/bcachefs/btree_cache.c                 |  38 +-
> >  fs/bcachefs/btree_cache.h                 |  11 +
> >  fs/bcachefs/btree_gc.c                    | 122 +++----
> >  fs/bcachefs/btree_io.c                    | 119 ++++---
> >  fs/bcachefs/btree_iter.c                  | 129 ++++---
> >  fs/bcachefs/btree_iter.h                  |  22 +-
> >  fs/bcachefs/btree_journal_iter.c          |  20 +-
> >  fs/bcachefs/btree_key_cache.c             |  16 +-
> >  fs/bcachefs/btree_locking.c               |  17 +-
> >  fs/bcachefs/btree_node_scan.c             |  32 +-
> >  fs/bcachefs/btree_trans_commit.c          | 121 ++++---
> >  fs/bcachefs/btree_types.h                 |  22 +-
> >  fs/bcachefs/btree_update.c                | 171 +++++----
> >  fs/bcachefs/btree_update.h                |  79 +++--
> >  fs/bcachefs/btree_update_interior.c       | 335 +++++++++---------
> >  fs/bcachefs/btree_update_interior.h       |  12 +-
> >  fs/bcachefs/btree_write_buffer.c          |  45 ++-
> >  fs/bcachefs/btree_write_buffer.h          |   6 +-
> >  fs/bcachefs/buckets.c                     | 212 +++++------
> >  fs/bcachefs/buckets_waiting_for_journal.c |  30 +-
> >  fs/bcachefs/chardev.c                     | 120 ++-----
> >  fs/bcachefs/checksum.c                    |  54 ++-
> >  fs/bcachefs/clock.c                       |  17 +-
> >  fs/bcachefs/compress.c                    |  29 +-
> >  fs/bcachefs/compress.h                    |  36 +-
> >  fs/bcachefs/data_update.c                 |  33 +-
> >  fs/bcachefs/debug.c                       |  92 +++--
> >  fs/bcachefs/dirent.c                      |  42 +--
> >  fs/bcachefs/dirent.h                      |   4 +-
> >  fs/bcachefs/disk_accounting.c             | 266 +++++++-------
> >  fs/bcachefs/disk_accounting.h             |   9 +-
> >  fs/bcachefs/disk_groups.c                 |  27 +-
> >  fs/bcachefs/ec.c                          | 239 +++++--------
> >  fs/bcachefs/ec.h                          |   2 +-
> >  fs/bcachefs/enumerated_ref.c              |   4 +-
> >  fs/bcachefs/errcode.c                     |   3 +-
> >  fs/bcachefs/errcode.h                     |  13 +
> >  fs/bcachefs/error.c                       |  65 ++--
> >  fs/bcachefs/extents.c                     |  38 +-
> >  fs/bcachefs/extents.h                     |   3 +
> >  fs/bcachefs/fast_list.c                   |  32 +-
> >  fs/bcachefs/fast_list.h                   |   2 +-
> >  fs/bcachefs/fs-io-buffered.c              |  79 ++---
> >  fs/bcachefs/fs-io-direct.c                |  11 +-
> >  fs/bcachefs/fs-io-pagecache.c             |  55 ++-
> >  fs/bcachefs/fs-io.c                       | 127 ++++---
> >  fs/bcachefs/fs-io.h                       |  19 +-
> >  fs/bcachefs/fs-ioctl.c                    |  33 +-
> >  fs/bcachefs/fs.c                          | 192 +++++-----
> >  fs/bcachefs/fsck.c                        | 427 ++++++++++++----------
> >  fs/bcachefs/inode.c                       | 101 +++---
> >  fs/bcachefs/io_misc.c                     |  36 +-
> >  fs/bcachefs/io_read.c                     | 157 +++++---
> >  fs/bcachefs/io_read.h                     |  20 +-
> >  fs/bcachefs/io_write.c                    |  46 +--
> >  fs/bcachefs/journal.c                     | 253 ++++++-------
> >  fs/bcachefs/journal.h                     |   3 +-
> >  fs/bcachefs/journal_io.c                  | 248 ++++++-------
> >  fs/bcachefs/journal_io.h                  |   7 +
> >  fs/bcachefs/journal_reclaim.c             | 220 ++++++------
> >  fs/bcachefs/journal_seq_blacklist.c       |  56 ++-
> >  fs/bcachefs/journal_seq_blacklist.h       |   3 +
> >  fs/bcachefs/logged_ops.c                  |  14 +-
> >  fs/bcachefs/lru.c                         |  24 +-
> >  fs/bcachefs/migrate.c                     |  21 +-
> >  fs/bcachefs/move.c                        | 218 +++++-------
> >  fs/bcachefs/move.h                        |  14 +-
> >  fs/bcachefs/movinggc.c                    |   6 +-
> >  fs/bcachefs/namei.c                       |  26 +-
> >  fs/bcachefs/nocow_locking.c               |  10 +-
> >  fs/bcachefs/opts.c                        |  33 +-
> >  fs/bcachefs/opts.h                        |   8 +-
> >  fs/bcachefs/printbuf.h                    |   4 +
> >  fs/bcachefs/progress.c                    |   6 +-
> >  fs/bcachefs/progress.h                    |   3 +
> >  fs/bcachefs/quota.c                       |  96 ++---
> >  fs/bcachefs/rebalance.c                   |  57 ++-
> >  fs/bcachefs/recovery.c                    | 213 +++++------
> >  fs/bcachefs/recovery_passes.c             |  68 ++--
> >  fs/bcachefs/recovery_passes.h             |   9 +-
> >  fs/bcachefs/reflink.c                     |  63 ++--
> >  fs/bcachefs/replicas.c                    | 147 ++++----
> >  fs/bcachefs/sb-clean.c                    |  36 +-
> >  fs/bcachefs/sb-counters_format.h          |   6 +
> >  fs/bcachefs/sb-downgrade.c                |  19 +-
> >  fs/bcachefs/sb-errors.c                   |  45 +--
> >  fs/bcachefs/sb-errors_format.h            |   9 +-
> >  fs/bcachefs/sb-members.c                  |  48 ++-
> >  fs/bcachefs/sb-members.h                  |  19 +-
> >  fs/bcachefs/sb-members_format.h           |   2 +-
> >  fs/bcachefs/six.c                         |  21 +-
> >  fs/bcachefs/snapshot.c                    | 179 ++++------
> >  fs/bcachefs/snapshot.h                    |  32 +-
> >  fs/bcachefs/snapshot_types.h              |   2 +-
> >  fs/bcachefs/str_hash.c                    |  23 +-
> >  fs/bcachefs/str_hash.h                    |   4 +-
> >  fs/bcachefs/subvolume.c                   | 106 +++---
> >  fs/bcachefs/super-io.c                    |  81 ++---
> >  fs/bcachefs/super.c                       | 570 ++++++++++++++----------------
> >  fs/bcachefs/sysfs.c                       |  28 +-
> >  fs/bcachefs/tests.c                       | 198 +++++------
> >  fs/bcachefs/thread_with_file.c            |  52 +--
> >  fs/bcachefs/time_stats.c                  |   7 +-
> >  fs/bcachefs/trace.h                       | 152 ++------
> >  fs/bcachefs/util.c                        |  28 +-
> >  fs/bcachefs/util.h                        |  10 +-
> >  fs/bcachefs/xattr.c                       |  52 ++-
> >  lib/closure.c                             |  12 +-
> >  120 files changed, 3972 insertions(+), 4388 deletions(-)
> >

Re: [GIT PULL] bcachefs changes for 6.17

[Aquinas Admin]

Generally, this drama is more like a kindergarten. I honestly don't understand 
why there's such a reaction. It's a management issue, solely a management 
issue. The fact is that there are plenty of administrative possibilities to 
resolve this situation.

Assign a specific person to handle issues with Kent, if Linus is unable to do 
so.
Simply freeze the patch acceptance for a certain period, explaining the 
situation, and ignoring it if the problem is really there. Then resume work. 
This has already been done and it was reasonable.
Explain to the person who is wrong in the discussion, draw conclusions, and 
possibly make some exceptions or changes in the process.
The main task of management is to work with engineers, who are often not 
politically correct or have their own view of the world. If you throw out a 
successful development that has proven its viability into the cold, I have 
questions about your actions. Anyway, I have plenty of questions about the 
Linux Foundation in general. The point is that many remember how the project 
was born and how it developed.

So, tell me, you release a product. You have a well-organized development 
cycle. You find a problem that prevents your product from being used as 
advertised. You already have an RC. The only way to fix the problem is to add 
new functionality to one of the product's subsystems. Will you release a 
product with known issues and later issue an errata, or will you make the 
necessary changes, provided no one is standing behind you with an axe 
threatening to cut your head off for a delay in the release? What's so terrible 
about that?

What's so terrible about fixing a bug in a subsystem marked as experimental, 
which some of your customers use? Especially since it will only affect those 
customers who use this subsystem, as others won't include it in their build 
processes.

This "We don't start adding new features just because you found other bugs" 
sounds absurd. So, if we find bugs, they can't be fixed if we need to extend the 
functionality before the release? Excuse me, what? I clearly understand the 
absurdity of this requirement. Because it effectively means that if we notice 
that ext4 is corrupting data only in RC simply because some code was forgotten 
to be added to a subsystem during the release window, we can't accept the fix 
because it requires adding new functionality and we will release the version 
with the problem. I clearly understand that this is not the exact situation, 
but it was done as a solution to an existing user's problem. Moreover, the 
amount of changes is not that significant. Especially since it's not really a 
fix but a workaround, a useful one that can actually help some real users in 
certain situations.

new USB serial driver device ids 6.12-rc7 is this new functionality or not?
ALSA: hda/realtek: Support mute LED on HP Laptop 14-dq2xxx 6.11-rc7 - new 
functionality?
ALSA: hda/realtek: Enable Mute Led for HP Victus 15-fb1xxx - 6.11-rc7
Octeontx2-pf: ethtool: support multi advertise mode - 6.15-rc5
drm/i915/flipq: Implement Wa_18034343758
drm/i915/display: Add drm_panic support
Is this different? Or are the rules somehow not for everyone?

But no, instead, this is what happened.

Yes, the file system is marked as experimental. However, everyone knows that 
there are users who use this file system in a production environment. It's just 
how it has historically been. Usually, it's SOHO, but that doesn't change 
much. Everyone knows that the file system has a very interesting design and 
some features that make it the most optimal solution. At least now, it is 
already successfully used as a replacement for LVM-Cache, DM-Cache, Bcachefs, 
etc. No existing file system today offers this functionality. Btrfs does not 
offer this functionality on various types of devices. Let's not consider ZFS, 
since it's an Out-Of-Tree project and has a number of problems and 
limitations, and even though such functionality could be implemented, it's not 
SOHO.

Therefore, instead of development, we are getting nonsense in the form of 
freezing the project or, worse, throwing the codebase away entirely. Why? 
Maybe we should switch from development to degradation?

As for the "trust issue," we've seen many examples of malicious code being 
included in the kernel. That's also a trust issue, isn't it? From this 
perspective, you can't use Linux at all. There's no way. You know, You can't 
have it both ways. Either that or nothing at all. Why these half-measures?

I somehow feel that we should start with management, not throwing the project 
into the cold.
> If we're giving our personal opinions I lean the other way.
> 
> I make no statement about the quality of Mr. Overstreet's code or whether it
> is (or isn't) stabilizing. But for me as someone who's made a career out of
> Linux it's not just about code it's about *trust*. For me personally I've
> made the decision to remove bcachefs entirely from my personal workstations
> and lab where I'd been testing and using it extensively for years. It's
> harsh to say it but I simply do not trust Kent's decision making process
> nor do I trust him as a *person* enough for me to be comfortable running
> bcachefs. I base this not on what other's may have said or written about
> him but on my own interactions with him and reading his own words.
> 
> This can (and hopefully will) change. People can grow... particularly
> through adversity. I'm hopeful that if it's decided that bcachefs will be
> removed or its in-kernel development paused Kent may reevaluate what's
> important and how he deals with people. I look forward to being able to
> trust bcachefs again but that's not right now.
> 
> Just my 2¢.
> 
> > On 2025-08-05 2:19 PM PDT Malte Schröder <malte.schroeder@tnxip.de> wrote:
> > 
> > On 28.07.25 17:14, Kent Overstreet wrote:
>> <Overquoting deleted>.

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Thu, Aug 07, 2025 at 07:42:38PM +0700, Aquinas Admin wrote:
> Generally, this drama is more like a kindergarten. I honestly don't understand 
> why there's such a reaction. It's a management issue, solely a management 
> issue. The fact is that there are plenty of administrative possibilities to 
> resolve this situation.

Yes, this is accurate. I've been getting entirely too many emails from
Linus about how pissed off everyone is, completely absent of details -
or anything engineering related, for that matter. Lots of "you need to
work with us better" - i.e. bend to demands - without being willing to
put forth an argument that stands to scrutiny.

This isn't high school, and it's not a popularity contest. This is
engineering, and it's about engineering standards.

Those engineering standards have been notably lacking in the Linux
filesystem world.

When brtfs shipped, it did so with clear design issues that have never
been adequately resolved. These were brought up on the list in the very
early days of btrfs, when it was still experimental, with detailed
analysis - that was ignored.

The issues in btrfs are the stuff of legend; I've been to conferences
(past LSFs) where after dinner the stories kept coming out from people
who had worked on it - for easily an _hour_ - and had people falling out
of their chairs.

As a result, to this day, people don't trust it, and for good reason.
Multidevice data corruptions, unfixed bugs with no real information,
people who have tried to help out and fund getting this stuff fixed only
to be turned away. This stuff is still going on:
https://news.ycombinator.com/item?id=44508601

This is what you'd expect to happen when you rush to have all the
features, skip the design, and don't build a community that's focused on
working with users.

Let's compare what's going on in bcachefs:

Bug tracker:
https://github.com/koverstreet/bcachefs/issues?q=is%3Aissue%20state%3Aopen%20-label%3Aenhancement%20-label%3A%22waiting%20confirmation%20fixed%22

Syzbot, and the other major filesystems for comparison:
https://syzkaller.appspot.com/upstream/s/bcachefs
https://syzkaller.appspot.com/upstream/s/ext4
https://syzkaller.appspot.com/upstream/s/xfs
https://syzkaller.appspot.com/upstream/s/btrfs

(Does btrfs even have a central bug tracker?)

An important note, with bcachefs most of the activity doesn't happen on
the bug tracker, it's on IRC (and the IRC channel is by far the most
active out of all the major filesystems). The bug tracker is for making
sure bugs don't get lost if they can't get fixed right away - most bugs
never make it there. So the bug tracker is a good measure of outstanding
bugs, but not fixed bugs or gauging usage.

How did we get here, what are we doing differently - and where are we
now?

The recipe has been: patient, methodical engineering, with a focus on
the users and building the user community, and working closely with the
people who are using, testing and QAing.

Get the design right, keep the codebase reasonably clean and well
organized so that we can work efficiently; _heavy_ focus on assertions,
automated testing (i.e. basic modern engineering best practices),
introspection and debug tooling.

Get enough feature work done to validate the design, and then - fix
every last bug, and work with users to make sure that bugs are fixed and
it's working well; work with people who are doing every kind of torture
testing imaginable.

A refrain I've been hearing has been about "working with the community",
but to the kernel community, I need to hammer the point home that the
community is not just us; it's all the people running our code, too.

We have to actively work with those people if we want our code to
actually work reliably in the real world, and this is something that's
been frighteningly absent elsewhere, in filesystem development these
days.

30 years ago, Linux took over by being a real community effort.

But now, most of the development is very corporate, and getting
corporate developers to actually engage with the community and do
anything that smells of unpaid support is worse than pulling teeth - it
just doesn't happen.

Now bcachefs is the community based up and comer...

But it's not really "up and coming" anymore.

6.16 is "unofficially unexperimental" - it's solid.

It's attracting real interest and feedback from the ZFS community, and
that hasn't happened before; those are the people who care about
reliability and good engineering above all else.

All the hard engineering problems are solved, stabilizing is basically
done. We've got petabyte scalability, the majority of online fsck in
place, all the multi device stuff rock solid (a major area where brtfs
falls over); the error handling, logging and debugging tools are top
notch. Repair is comprehensive and robust, with real defense in depth,
and an extensive suite of tools for analyzing issues and making sure we
can debug anything that may occur in the wild.

The kernel community is being caught with their pants down here.

The desicionmaking process has, at every step in the way, been "things
couldn't possibly be that insane" - and yet, I am continually proven
wrong.

Post btrfs, I seriously expected there to be real design review for any
future filesystems, and a retrospective on development process.

Needless to say, that did not happen - it seems we're still in the
"trust me bro, I got this" stage in the development of an engineering
culture.

But a cowboy culture only takes you so far, at some point you really do
need actual engineer standards; you need to be able to explain your
designs, your methods, your processes and decisionmaking.

I've talked at length in the past about the need for a tight feedback
loop on getting bugs out to users if we want to be able to work with
those users (and to be honest, that should not even have been a
discussion; I've been going over RC pull requests and there's been
nothing remotely unusual about what I've been sending - except for
volume, which is exactly what you want and expect for a filesystem
that's been rapidly stabilizing).

But "shipping bugfixes" has been called "whining" - that's the mentality
we're dealing with here.

I have to hammer on this one: there are certain bedrock principles of
systems engineering we all know.  "Make sure things work and stay
working" is one of them. The rest of the kernel knows this as "do not
break userspace", but in filesystem land that same underlying principle
is written as "we do not lose user data".

Our job is to ship things that work, and make sure they work.

I also talk a lot about the need for automated testing; and that's
another area where the kernel is woefully behind - and it's been one of
the sources of conflict. I've asked people in other subsystems to please
make sure they tests when regressions have hit bcachefs; it's good for
everyone, not just bcachefs. But this has been cited (!) as one of the
causes of conflict that's been pissing Linus off.

Engineering principles. Basic stuff, here.

And regarding manegement processes: Linus has been saying repeatedly
(and loudly, and in public) that it's his decision whether or not to
remove bcachefs from the kernel - but the criteria and decisionmaking
process have been notably absent.

It is not for me to say whether or not the kernel should still be a
personal project, with decisions made in this way. And at the end of the
day, we're all human beings, I'm not going to argue against the human
factor, or against considering the people behind these projects.

But the uncertainty this has caused has created massive problems for
building a sustainable developer community around this thing, it should
be noted.

For my part, I just want to reassure people that I'm not going anywhere;
bcachefs will continue to be developed and supported, in or out of the
kernel.

Cheers,
Kent

Re: [GIT PULL] bcachefs changes for 6.17

[Josef Bacik]

On Sat, Aug 09, 2025 at 01:36:39PM -0400, Kent Overstreet wrote:
> On Thu, Aug 07, 2025 at 07:42:38PM +0700, Aquinas Admin wrote:
> > Generally, this drama is more like a kindergarten. I honestly don't understand 
> > why there's such a reaction. It's a management issue, solely a management 
> > issue. The fact is that there are plenty of administrative possibilities to 
> > resolve this situation.
> 
> Yes, this is accurate. I've been getting entirely too many emails from
> Linus about how pissed off everyone is, completely absent of details -
> or anything engineering related, for that matter. Lots of "you need to
> work with us better" - i.e. bend to demands - without being willing to
> put forth an argument that stands to scrutiny.
> 
> This isn't high school, and it's not a popularity contest. This is
> engineering, and it's about engineering standards.
> 

Exactly. Which is why the Meta infrastructure is built completely on btrfs and
its features. We have saved billions of dollars in infrastructure costs with the
features and robustness of btrfs.

Btrfs doesn't need me or anybody else wandering around screaming about how
everybody else sucks to gain users. The proof is in the pudding. If you read
anything that I've wrote in my commentary about other file systems you will find
nothing but praise and respect, because this is hard and we all make our
tradeoffs.

That courtesy has been extended to you in the past, and still extends to your
file system. Because I don't need to tear you down or your work down to make
myself feel good. And because I truly beleive you've done some great things with
bcachefs, things I wish we had had the foresight to do with btrfs.

I'm yet again having to respond to this silly childishness because people on the
outside do not have the context or historical knowledge to understand that they
should ignore every word that comes out of your mouth. If there are articles
written about these claims I want to make sure that they are not unchallenged
and thus viewed as if they are true or valid.

Emails like this are why nobody wants to work with you. Emails like this are why
I've been on literally dozens of email threads, side conversations, chat
threads, and in person discussions about what to do when we have exceedingly
toxic developers in our community.

Emails like this are exactly why we have to have a code of conduct.

Emails like this are why a majority of the community filters your emails to
/dev/null.

You alone with your toxic behavior have wasted a fair amount of mine and other
peoples time trying to figure out how do we exist in our place of work with
somebody who is bent on tearing down the community and the people who work in
it.

I have defended you in the past, I was hoping that the support, guidance, and
grace you've been afforded by so many people in this community would have
resulted in your behavior changing. I'm very sorry I was wrong, and I'm very
sorry if my support in anyway enabled the decision to merge your filesystem.

Because your behavior is unacceptable. This email is unacceptable. Everything
about your presence in this community has been a disruption and has ended up
with all of our jobs being harder.

You are not some paraih. You are not some victim. You are not some misunderstood
genius. Your behavior makes this community a worse place to work in. If you are
removed from this community it will soley be because you lack the ability to
learn and to grow as a person and take responsibility for your behavior.

If you are allowed to continue to be in this community that will be a travesty.

Thanks,

Josef

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Sat, Aug 09, 2025 at 03:21:56PM -0400, Josef Bacik wrote:
> On Sat, Aug 09, 2025 at 01:36:39PM -0400, Kent Overstreet wrote:
> > On Thu, Aug 07, 2025 at 07:42:38PM +0700, Aquinas Admin wrote:
> > > Generally, this drama is more like a kindergarten. I honestly don't understand 
> > > why there's such a reaction. It's a management issue, solely a management 
> > > issue. The fact is that there are plenty of administrative possibilities to 
> > > resolve this situation.
> > 
> > Yes, this is accurate. I've been getting entirely too many emails from
> > Linus about how pissed off everyone is, completely absent of details -
> > or anything engineering related, for that matter. Lots of "you need to
> > work with us better" - i.e. bend to demands - without being willing to
> > put forth an argument that stands to scrutiny.
> > 
> > This isn't high school, and it's not a popularity contest. This is
> > engineering, and it's about engineering standards.
> > 
> 
> Exactly. Which is why the Meta infrastructure is built completely on btrfs and
> its features. We have saved billions of dollars in infrastructure costs with the
> features and robustness of btrfs.

That's great for Facebook, but you're doing everyone else a disservice.

The big cloud providers don't require as much reliability from
individual nodes. I've provided data in the form of bug reports and
actual user reports, you've provided no data on reliability within
Facebook, nor which featureset is being used (it's the multi device
stuff that's been absolutely notorious; Synology famously still uses md
raid to avoid that, write hole and all).

This is real, Josef. I've seen time and again how corporate development
works; I've been at Google, I've worked with Redhat enough to see their
model, and within the filesystem world engineering standards have not
been what they should be, and the wider community (i.e. the rest of the
world, not just the tech giants) is not being served.

COW filesystems were supposed to bring improved reliability over
conventional filesystems - it's been known for decades that "update in
place" is a massive problem if we want real advances in reliability. ZFS
showed that it was possible, but the common consensus in the user
community, among people with the data (i.e. quite a few of the distros)
is that btrfs dropped the ball, and regressed on reliability from
ext4/xfs.

That's common knowledge.

At this point in the development and deployment in bcachefs I can say,
with confidence, that bcachefs is changing that, and that in time we
will deliver _better_ reliability than ext4/xfs.

That's why my work has been funded, that's what people want, and that's
why I'm talking about it.

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Sat, Aug 09, 2025 at 04:37:56PM -0400, Kent Overstreet wrote:
> At this point in the development and deployment in bcachefs I can say,
> with confidence, that bcachefs is changing that, and that in time we
> will deliver _better_ reliability than ext4/xfs.

I should add, based on the data I'm seeing - this isn't far off, but due
to the sheer amount of deployment and usage ext4/xfs have had it'll be
awhile (perhaps a year) before we have the data to make hard claims.

The data from users versus btrfs is much clearer, we're already
delivering much better reliability in terms of "will my data be safe" -
there are numerous failure modes that simply don't exist in bcachefs.
And where we've had significant bugs (I count ~2 that have made it all
the way to a mainline .0 release), good debugging tools and a clean
design have meant that we've been able to resolve them by about the
third report, and in every case with significant hardening done after
the fact and real support for affected users.

IOW: your data is safe on bcachefs, and that's priority #1 for a
filesystem.

Re: [GIT PULL] bcachefs changes for 6.17

[Theodore Ts'o]

On Sat, Aug 09, 2025 at 04:37:51PM -0400, Kent Overstreet wrote:
> showed that it was possible, but the common consensus in the user
> community, among people with the data (i.e. quite a few of the distros)
> is that btrfs dropped the ball, and regressed on reliability from
> ext4/xfs.

Kent, you eeem to have ignored the primary point of Josef's message,
and instead, prceeded to prove *exactly* what he was pointing out.
Let me quote the most relevant parts of his e-mail, in case you missed
it:

> Btrfs doesn't need me or anybody else wandering around screaming
> about how everybody else sucks to gain users. The proof is in the
> pudding. If you read anything that I've wrote in my commentary about
> other file systems you will find nothing but praise and respect,
> because this is hard and we all make our tradeoffs.
>
> That courtesy has been extended to you in the past, and still
> extends to your file system. Because I don't need to tear you down
> or your work down to make myself feel good. And because I truly
> beleive you've done some great things with bcachefs, things I wish
> we had had the foresight to do with btrfs.
>
> I'm yet again having to respond to this silly childishness because
> people on the outside do not have the context or historical
> knowledge to understand that they should ignore every word that
> comes out of your mouth. If there are articles written about these
> claims I want to make sure that they are not unchallenged and thus
> viewed as if they are true or valid.
> 
> ...
> Emails like this are why nobody wants to work with you. Emails like
> this are why I've been on literally dozens of email threads, side
> conversations, chat threads, and in person discussions about what to
> do when we have exceedingly toxic developers in our community.
> 
> Emails like this are why a majority of the community filters your emails to
> /dev/null.
> 
> You alone with your toxic behavior have wasted a fair amount of mine
> and other peoples time trying to figure out how do we exist in our
> place of work with somebody who is bent on tearing down the
> community and the people who work in it.

And how did you respond?  By criticizing another file system, and
talking about how wonderful you believe bcachefs to be, all of which
is beside the point.  In fact, you once again demonstrated exactly why
a very large number of kernel deevlopers have decided you are
extremely toxic, and have been clamoring that your code be ejected
from the kernel.  Not because of the code, but because your behavior.

In general, file system developers have been the ones that have been
arguing that you should be shone more grace, because we respect the
work that you have done.  However, don't mistake respect for your code
with respect for your behavior.  There are *many* developers in
adjcaent subsystems (for example, block and mm) who have lost all
patience with you.  This is not just one or two people; so please
don't blame this on the people who have been trying to reach out and
help you see what you have been doing.  Quite frankly, it is
astonishing to me how *many* people who have been arguing for "git rm
-r fs/bcachefs" as soon as the merge window opened and effectively
asking why Linus has been extending as much grace as he has up until
now.

Programming is a team sport, and you have pissed off a very large
number of people on the team.  It doesn't matter how talented a
particular indiviual might be; if they can't work with the other
people on the team; if they are toxic to the community, it doesn't
matter whether or not they might be technically correct on a
particular point or not.

Many decades ago, when I was working group chair for ipsec, there was
a particular individual who was super-smart; and who was often
technically on point..  Unfortunately, he had the habit of appending
phrases such as, "as any idiot could see" at to the end of what might
otherwise be a very insightful comment.  It didn't matter that the
point that he raised was one that was (a) correct, and (b) missed by
other people in the working group.  The way that he phrased it meant
that no one wanted to listen to what he had to say.  Because I wanted
the ipsec standardization to succeed, I acted as that person's
intermediary, rephrasing his arguments and technical points in a way
that was easier to understand, and more importantly, stripping out all
of the adhominem asides.  It took a huge amount of work, and psychic
toil, and it isn't something I would ask someone else to do.

All of this being said, unless you can find someone willing to be your
intermediary, and hopefully your coach in how to better work with
other people, I fear that the only thing we can do is to find the most
graceful way for you to leave the community.  And fortunately, I'm
very glad that at the end of the day, it's not up to me.

						- Ted

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Sat, Aug 09, 2025 at 10:24:36PM -0400, Theodore Ts'o wrote:
> On Sat, Aug 09, 2025 at 04:37:51PM -0400, Kent Overstreet wrote:
> > showed that it was possible, but the common consensus in the user
> > community, among people with the data (i.e. quite a few of the distros)
> > is that btrfs dropped the ball, and regressed on reliability from
> > ext4/xfs.
> 
> Kent, you eeem to have ignored the primary point of Josef's message,
> and instead, prceeded to prove *exactly* what he was pointing out.
> Let me quote the most relevant parts of his e-mail, in case you missed
> it:
> 
> > Btrfs doesn't need me or anybody else wandering around screaming
> > about how everybody else sucks to gain users. The proof is in the
> > pudding. If you read anything that I've wrote in my commentary about
> > other file systems you will find nothing but praise and respect,
> > because this is hard and we all make our tradeoffs.
> >
> > That courtesy has been extended to you in the past, and still
> > extends to your file system. Because I don't need to tear you down
> > or your work down to make myself feel good. And because I truly
> > beleive you've done some great things with bcachefs, things I wish
> > we had had the foresight to do with btrfs.
> >
> > I'm yet again having to respond to this silly childishness because
> > people on the outside do not have the context or historical
> > knowledge to understand that they should ignore every word that
> > comes out of your mouth. If there are articles written about these
> > claims I want to make sure that they are not unchallenged and thus
> > viewed as if they are true or valid.
> > 
> > ...
> > Emails like this are why nobody wants to work with you. Emails like
> > this are why I've been on literally dozens of email threads, side
> > conversations, chat threads, and in person discussions about what to
> > do when we have exceedingly toxic developers in our community.
> > 
> > Emails like this are why a majority of the community filters your emails to
> > /dev/null.
> > 
> > You alone with your toxic behavior have wasted a fair amount of mine
> > and other peoples time trying to figure out how do we exist in our
> > place of work with somebody who is bent on tearing down the
> > community and the people who work in it.
> 
> And how did you respond?  By criticizing another file system, and
> talking about how wonderful you believe bcachefs to be, all of which
> is beside the point.  In fact, you once again demonstrated exactly why
> a very large number of kernel deevlopers have decided you are
> extremely toxic, and have been clamoring that your code be ejected
> from the kernel.  Not because of the code, but because your behavior.

I would dearly love to have not opened that up, but "let's now delete
bcachefs from the kernel" opened up that discussion, because our first
priority has to be doing right by users - and a decision like that
should absolutely be discussed publicly, well in advance, with all
technical arguments put forth.

Or was that going to happen without giving users advance notice?
Without a discussion of why we need a filesystem that's prioritizing
basic reliability and robustness?

Moreover -

"Work as service to others" is something I think worth thinking about.
We're not supposed to be in this for ourselves; I don't write code to
stroke my own ego, I do it to be useful.

I honestly can't even remember the last time I wrote code purely for
enjoyment, or worked on a project because it was what I wanted to work
on. My life consists of writing code base on what's needed; to fix a
bug, to incorporate a good idea someone else had, to smooth something
over to make someone else's life easier down the line. Very rarely does
it come from my own vision.

My feelings are entirely secondary to the work I do.

And yet again, in this thread, we keep hearing about how pissed off
people are, and how that's supposed to be our primary concern. I'm
afraid I can't agree.

And if someone's going to start outright swearing over technical
criticism, that's a flagrant CoC violation - and just beyond
unprofessional. That is one of the interactions you guys are apparently
basing this one, and that wasn't me.

And I have to point out, this has been escalated, over and over and
over, over a patch that was purely internal to fs/bcachefs.

I think you guys have been taking this a bit too far.

Re: [GIT PULL] bcachefs changes for 6.17

[Sasha Levin]

On Sat, Aug 09, 2025 at 11:17:44PM -0400, Kent Overstreet wrote:
>On Sat, Aug 09, 2025 at 10:24:36PM -0400, Theodore Ts'o wrote:
>> And how did you respond?  By criticizing another file system, and
>> talking about how wonderful you believe bcachefs to be, all of which
>> is beside the point.  In fact, you once again demonstrated exactly why
>> a very large number of kernel deevlopers have decided you are
>> extremely toxic, and have been clamoring that your code be ejected
>> from the kernel.  Not because of the code, but because your behavior.
>
>I would dearly love to have not opened that up, but "let's now delete
>bcachefs from the kernel" opened up that discussion, because our first
>priority has to be doing right by users - and a decision like that
>should absolutely be discussed publicly, well in advance, with all
>technical arguments put forth.

Kent,

You say our first priority has to be doing right by users, and I agree -
but doing right by users means maintaining a healthy, functioning
development community. A toxic community that drives away contributors
fails its users far more severely than the absence of any single
filesystem ever could.

Look at this thread again. Really look at it. Neither Ted nor Josef
raised a single technical argument against bcachefs. They didn't
criticize your code, your design decisions, or your engineering. Josef
explicitly praised your technical work. Ted has repeatedly shown respect
for your code.  The discussions about potentially dropping bcachefs
aren't happening because it's technically inferior to ext4, xfs, or
btrfs. They're happening because your personal interactions are
undermining the health of the community that maintains all of these
filesystems.

>"Work as service to others" is something I think worth thinking about.
>We're not supposed to be in this for ourselves; I don't write code to
>stroke my own ego, I do it to be useful.

Service to others includes maintaining professional relationships with
your colleagues. It includes building rather than tearing down. It
includes recognizing that a healthy community serves users better in the
long run than any individual contribution, no matter how technically
excellent.

The kernel has thrived for over 30 years not just because of technical
excellence, but because it has (mostly) maintained a collaborative
environment where developers can work together despite disagreements.
That collaborative environment IS doing right by users.

No filesystem is worth destroying that.

-- 
Thanks,
Sasha

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Sun, Aug 10, 2025 at 12:05:28AM -0400, Sasha Levin wrote:
> On Sat, Aug 09, 2025 at 11:17:44PM -0400, Kent Overstreet wrote:
> > On Sat, Aug 09, 2025 at 10:24:36PM -0400, Theodore Ts'o wrote:
> > > And how did you respond?  By criticizing another file system, and
> > > talking about how wonderful you believe bcachefs to be, all of which
> > > is beside the point.  In fact, you once again demonstrated exactly why
> > > a very large number of kernel deevlopers have decided you are
> > > extremely toxic, and have been clamoring that your code be ejected
> > > from the kernel.  Not because of the code, but because your behavior.
> > 
> > I would dearly love to have not opened that up, but "let's now delete
> > bcachefs from the kernel" opened up that discussion, because our first
> > priority has to be doing right by users - and a decision like that
> > should absolutely be discussed publicly, well in advance, with all
> > technical arguments put forth.
> 
> Kent,
> 
> You say our first priority has to be doing right by users, and I agree -
> but doing right by users means maintaining a healthy, functioning
> development community. A toxic community that drives away contributors
> fails its users far more severely than the absence of any single
> filesystem ever could.
> 
> Look at this thread again. Really look at it. Neither Ted nor Josef
> raised a single technical argument against bcachefs. They didn't
> criticize your code, your design decisions, or your engineering. Josef
> explicitly praised your technical work. Ted has repeatedly shown respect
> for your code.  The discussions about potentially dropping bcachefs
> aren't happening because it's technically inferior to ext4, xfs, or
> btrfs. They're happening because your personal interactions are
> undermining the health of the community that maintains all of these
> filesystems.
> 
> > "Work as service to others" is something I think worth thinking about.
> > We're not supposed to be in this for ourselves; I don't write code to
> > stroke my own ego, I do it to be useful.
> 
> Service to others includes maintaining professional relationships with
> your colleagues. It includes building rather than tearing down. It
> includes recognizing that a healthy community serves users better in the
> long run than any individual contribution, no matter how technically
> excellent.
> 
> The kernel has thrived for over 30 years not just because of technical
> excellence, but because it has (mostly) maintained a collaborative
> environment where developers can work together despite disagreements.
> That collaborative environment IS doing right by users.
> 
> No filesystem is worth destroying that.

Then can we please drop all this madness?

I do hereby solomnly swear that I will refrain from critizing btrfs ever
again, or any other code anywhere in the kernel (if that is the wish) -
as long as Linus stops trying to dictate on patches internal to
fs/bcachefs/.

If it affects the rest of the kernel, that's fair game; I just want to
be able to get work done.

Re: [GIT PULL] bcachefs changes for 6.17

[Gerald B. Cox]

Please excuse, sending this again because I forgot to put in plain text mode.

Been watching this thread unfold. There are valid concerns, sure—but
I’d caution folks against mistaking frustration for hostility.

Kent’s been carrying a heavy load with bcachefs, and it shows. Solo
stewardship at this scale isn’t just technical—it’s psychological.
When someone’s under pressure and feels attacked, responses get sharp.
That’s not ideal, but it’s not malicious either.

If we’re serious about maintaining a healthy kernel community, we need
to be better at recognizing when someone’s burning out—and not make it
worse. The CoC isn’t just there to call out bad behavior; it’s
supposed to guide us toward empathy and restraint.

Kent, if you’re reading this: it’s clear you’re reacting to what feels
like a pile-on. That’s understandable. But at this point, stepping
back might serve you better than continuing to reply. Let the code
speak. Let others weigh in. You’ve done the hard part—now give it
room.

And really, this whole thread feels beneath what the kernel community
should be. If there’s a serious question about bcachefs’s future, it
ought to be a quiet, direct conversation between Kent and Linus—not a
public spectacle. We’ve seen how these things go, and it rarely ends
well unless someone redirects the tone.

On Sat, Aug 9, 2025 at 9:13 PM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Sun, Aug 10, 2025 at 12:05:28AM -0400, Sasha Levin wrote:
> > On Sat, Aug 09, 2025 at 11:17:44PM -0400, Kent Overstreet wrote:
> > > On Sat, Aug 09, 2025 at 10:24:36PM -0400, Theodore Ts'o wrote:
> > > > And how did you respond?  By criticizing another file system, and
> > > > talking about how wonderful you believe bcachefs to be, all of which
> > > > is beside the point.  In fact, you once again demonstrated exactly why
> > > > a very large number of kernel deevlopers have decided you are
> > > > extremely toxic, and have been clamoring that your code be ejected
> > > > from the kernel.  Not because of the code, but because your behavior.
> > >
> > > I would dearly love to have not opened that up, but "let's now delete
> > > bcachefs from the kernel" opened up that discussion, because our first
> > > priority has to be doing right by users - and a decision like that
> > > should absolutely be discussed publicly, well in advance, with all
> > > technical arguments put forth.
> >
> > Kent,
> >
> > You say our first priority has to be doing right by users, and I agree -
> > but doing right by users means maintaining a healthy, functioning
> > development community. A toxic community that drives away contributors
> > fails its users far more severely than the absence of any single
> > filesystem ever could.
> >
> > Look at this thread again. Really look at it. Neither Ted nor Josef
> > raised a single technical argument against bcachefs. They didn't
> > criticize your code, your design decisions, or your engineering. Josef
> > explicitly praised your technical work. Ted has repeatedly shown respect
> > for your code.  The discussions about potentially dropping bcachefs
> > aren't happening because it's technically inferior to ext4, xfs, or
> > btrfs. They're happening because your personal interactions are
> > undermining the health of the community that maintains all of these
> > filesystems.
> >
> > > "Work as service to others" is something I think worth thinking about.
> > > We're not supposed to be in this for ourselves; I don't write code to
> > > stroke my own ego, I do it to be useful.
> >
> > Service to others includes maintaining professional relationships with
> > your colleagues. It includes building rather than tearing down. It
> > includes recognizing that a healthy community serves users better in the
> > long run than any individual contribution, no matter how technically
> > excellent.
> >
> > The kernel has thrived for over 30 years not just because of technical
> > excellence, but because it has (mostly) maintained a collaborative
> > environment where developers can work together despite disagreements.
> > That collaborative environment IS doing right by users.
> >
> > No filesystem is worth destroying that.
>
> Then can we please drop all this madness?
>
> I do hereby solomnly swear that I will refrain from critizing btrfs ever
> again, or any other code anywhere in the kernel (if that is the wish) -
> as long as Linus stops trying to dictate on patches internal to
> fs/bcachefs/.
>
> If it affects the rest of the kernel, that's fair game; I just want to
> be able to get work done.
>

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Sat, Aug 09, 2025 at 09:26:16PM -0700, Gerald B. Cox wrote:
> Please excuse, sending this again because I forgot to put in plain text mode.
> 
> Been watching this thread unfold. There are valid concerns, sure—but
> I’d caution folks against mistaking frustration for hostility.
> 
> Kent’s been carrying a heavy load with bcachefs, and it shows. Solo
> stewardship at this scale isn’t just technical—it’s psychological.
> When someone’s under pressure and feels attacked, responses get sharp.
> That’s not ideal, but it’s not malicious either.
> 
> If we’re serious about maintaining a healthy kernel community, we need
> to be better at recognizing when someone’s burning out—and not make it
> worse. The CoC isn’t just there to call out bad behavior; it’s
> supposed to guide us toward empathy and restraint.
> 
> Kent, if you’re reading this: it’s clear you’re reacting to what feels
> like a pile-on. That’s understandable. But at this point, stepping
> back might serve you better than continuing to reply. Let the code
> speak. Let others weigh in. You’ve done the hard part—now give it
> room.

Thanks; I really appreciate this response.

The thing is, the burnout isn't coming from bcachefs. It has been an
absolutely monumental effort - but looking back and where we're at now,
I can't describe how lucky I and the bcachefs community have been at how
smoothly it's gone. I've been doing storage for a long time, and I know
what can happen when things go badly; when I look at the bug tracker now
I count my lucky stars.

And the bcachefs community has been amazing, I have a ton of people I
work with on a daily basis, and people see and appreciate the work I do;
when people show up with bugs to report - people are often shocked at
how quickly we're able to get it sorted, it's almost always downright
pleasant experiences where we all get to learn something and someone new
joins the community. I'm honestly proud of the community I've built and
proud of the people I work with.

We've got more engineers coming in and getting up to speed on the code
(THANK YOU ALAN for all the work you've done on the syzbot bugs!);
funding is now stable (Thank you, Valve! They do a ton of amazing stuff
for Linux).

But dealing with upstream has left me at my wit's end, and well past
that. I'm not going to describe the effects it's caused... I'll just
leave off there.

Re: [GIT PULL] bcachefs changes for 6.17

[Theodore Ts'o]

On Sat, Aug 09, 2025 at 09:26:16PM -0700, Gerald B. Cox wrote:
> And really, this whole thread feels beneath what the kernel community
> should be. If there’s a serious question about bcachefs’s future, it
> ought to be a quiet, direct conversation between Kent and Linus—not a
> public spectacle.

There has been private conversations with Kent.  I will note that it
was *Kent* who started this most recent round of e-mails[1].  In his
e-mail, He slammed the Linux Kernel's "engineering standards", and
btrfs in particular.  I won't quote any of it here, because it really
is quite toxic, but please note that it was Kent who started the
discussion about btrfs.  This kind of attack is Just Not Helpful, and
this kind of behavior is, unfortunately, quite common coming from
Kent.

[1] https://lore.kernel.org/all/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72qk5izizw@k6vxp22uwnwa/

And no, I don't agree that Kent's behavior is due to him being
"piled-on".  His behaviour has been going on for months, if not a year
or more.  Some of us have tried pointing this out to Kent before,
privately, but about a month ago, I gave up out of frustration.
Getting him to understand is clearly beyond my abilities.

If Kent hadn't spoken up, I would have remained quiet and waited for
Linus to do what he was going to do --- but no, he decided to take
this public, and started slamming Linux's engineering standards.  I
will point out that a good engineer has to have good people skills[2].
In fact, there are many who have claimed that engineers' soft skills
are just as important, if not more important than their technical
abilities.

[2] https://www.ijee.ie/articles/Vol13-5/ijee996.pdf

Kent has been claiming the role of victim, but [1] is a really good
example of how this is not the case.  Similar e-mails over the past
year questioning other developers' professionalism, engineering
competence, etc. is why there hasn't been any Linux developers
speaking up trying to defend Kent on various private e-mail threads in
the past month.

Kent, it's not about promising to not criticize btrfs.  It's
about assuming good faith, and other maintainers' technical
competence, and listening to their concerns, and genunely believing
that perhaps their concerns are as important as yours.  If you really
believe that we are all clowns, and that Linux's engineering standards
are cr*p, I cordially invite you to create your own OS which upholds
your high technical standards.  Maybe you will be happier, and maybe
you *will* create something which is better for all of your users.

Cheers,

					- Ted

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Sun, Aug 10, 2025 at 01:59:55AM -0400, Theodore Ts'o wrote:
> If Kent hadn't spoken up, I would have remained quiet and waited for
> Linus to do what he was going to do --- but no, he decided to take
> this public, and started slamming Linux's engineering standards.  I
> will point out that a good engineer has to have good people skills[2].
> In fact, there are many who have claimed that engineers' soft skills
> are just as important, if not more important than their technical
> abilities.

If I had simply remained quiet until it happened, I think the entire
bcachefs userbase, and my funders, would have been absolutely furious
with me.

And yes, the kernel engineering processes and standards that got us to
the point are absolutely relevant to the discussion.

Re: [GIT PULL] bcachefs changes for 6.17

[Martin Steigerwald]

Hi Theodore, hi,

Theodore Ts'o - 10.08.25, 07:59:55 CEST:
> On Sat, Aug 09, 2025 at 09:26:16PM -0700, Gerald B. Cox wrote:
> > And really, this whole thread feels beneath what the kernel community
> > should be. If there’s a serious question about bcachefs’s future, it
> > ought to be a quiet, direct conversation between Kent and Linus—not a
> > public spectacle.
> 
> There has been private conversations with Kent.  I will note that it
> was *Kent* who started this most recent round of e-mails[1].  In his
> e-mail, He slammed the Linux Kernel's "engineering standards", and
> btrfs in particular.  I won't quote any of it here, because it really
> is quite toxic, but please note that it was Kent who started the
> discussion about btrfs.  This kind of attack is Just Not Helpful, and
> this kind of behavior is, unfortunately, quite common coming from
> Kent.
> 
> [1]
> https://lore.kernel.org/all/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72q
> k5izizw@k6vxp22uwnwa/

I kind of agree that this thread would have gone better without this mail 
from Kent.

Best,
-- 
Martin

Peanut gallery 2c

[James Lawrence]

I've been a user of bcachefs for over 2 years now and I must say in that time watching the drama
play out in the lkml most of it isn't coming from kent. Interestingly like ext4 its one of the few filesystems
I have *not* had to think about while providing far more functionality all while marked as experimental.

What I've found most interesting in watching it play out is that the criticisms of kent are rarely on the technical issues.
its mostly 'how dare he point out the issues in other file systems', 'how dare he point out issues with the kernel's engineering processes'
as if that is somehow unthinkable. Are we not allowed to critize poorly performing systems and processes?

Isn't that *precisely* what engineering is all about *improving* poorly performing systems? Have we all forgotten this? How about instead of
complaining that kent is critiquing your processes, fix them. address the actual critiques. its pretty hard to critique something that has been resolved no?

linus if you dont like the timing of kent's pull requests just ignore it until the next cycle, no one is forcing you and kent certainly can't.
It'll be inconvenient for those of us downstream who absolutely adore the fast pace of the fixes kent has provided when we run into problems, but we'll survive we went in knowing
we'd run into issues and if they're serious we'll work around the delays caused by upstream in our own way.

If maintainers have actual technical issues with bcachefs, then they can bring those up with some ideas for solutions. they can bring hard evidence to the table and
not 'someone said something about code i work on, that i took offense to and then did nothing to address, as a reason for their code existing'.

I would very much like to see bcachefs remain because its been a breeze to setup, use, and maintain. Backups are a breeze, I can safely mess with my entire
system with a single command to produce a snapshot prior to starting that is basically instant. Something that previously required an entire esoteric distribution ecosystem dedicated to immutability to accomplish.

And since other FS maintainers are not stepping up to the plate and improving or implementing new filesystems to address their own featureset and branding short comings,
I'm not terribly interested in what they have tso say on the matter. And neither should you linus, let them be upset that *experimental* *opt in* systems can
(and should) operate under different development processes. I certainly give my engineers/researchers a ton of leeway long as their work is opt in.

And when kent is ready to take off the experimental label, then rake bcachefs over the coals as much as you want to make sure its actually ready.

Until then maybe consider not making your own life harder by trying to gate keep the development process for an actively developing entirely opt in/experimental system?

Apologies for bothering everyone with my 2c,
James Lawrence
Principal Engineer

Re: Peanut gallery 2c

[Kent Overstreet]

On Mon, Aug 11, 2025 at 11:48:26AM -0400, James Lawrence wrote:
> And since other FS maintainers are not stepping up to the plate and
> improving or implementing new filesystems to address their own
> featureset and branding short comings, I'm not terribly interested in
> what they have tso say on the matter. And neither should you linus,
> let them be upset that *experimental* *opt in* systems can
> (and should) operate under different development processes. I
> certainly give my engineers/researchers a ton of leeway long as their
> work is opt in.

That one is unfair: btrfs has improved greatly, by most reports (but I
also still see reports of e.g. multi device issues). 

I think bcachefs has been a bit of a kick in the pants for them, they've
taken some stuff directly from bcachefs - e.g. I believe they took the
basic design of raid5 v2, the stripes tree, directly from bcachefs. A
btrfs engineer asked me and I explained the design at a conference some
years back, and I've seen other solutions show up in btrfs that look
cribbed from btrfs. Similarly, the basic user interface of subvolumes
and snapshots in bcachefs is lifted directly from btrfs - it looked
sane, so I stole it.

That's where we're at our best, spurring each other on in friendly
competition, stealing each other's good ideas...

Peanut gallery 2c

[James Lawrence]

fair enough, I was less explicit about which are which. btrfs has mostly a branding issue at this stage, which is fairly rough to dig out of.

You would know better than I would since you're directly in the weeds. I only have prior experiences and old cases to go off, of most of which are out dated at this point, and im primarily interested in raid 5/6 usecases.

Which is why I've mostly stayed out of the lkml drama until now. But removal doesnt resolve the problems with the linux filesystem ecosystem
and it'd be a disservice to everyone to lose convienent access to the work you've done.

crossing my fingers your work will remain,
James Lawrence
Principal Engineer

Re: Peanut gallery 2c

[Kent Overstreet]

On Tue, Aug 12, 2025 at 11:24:18AM +0200, Johannes Thumshirn wrote:
> On Mon, Aug 11, 2025 at 12:08:12PM -0400, Kent Overstreet wrote:
> > I think bcachefs has been a bit of a kick in the pants for them, they've
> > taken some stuff directly from bcachefs - e.g. I believe they took the
> > basic design of raid5 v2, the stripes tree, directly from bcachefs. A
> > btrfs engineer asked me and I explained the design at a conference some
> > years back [...]
> 
> Just one single mail and I will not reply to any follow ups on this. But I
> feel the need to clarify things as people have approached me. Yes Kent and I
> have talked about RAID. This has been at LSFMM 2024 in Salt Lake City. 
> 
> I can't remember if we talked about stripe trees, I only remember us talking
> about erasure coding, which Kent has done for bcachefs and I was planning to
> do for btrfs as well.
> 
> But the 1st presentations I did on the idea of the stripe tree have been Lund
> Linux Conference and Plumbers in 2022 [1]. This is easy to look up. In the
> beginning the RAID stripe tree didn't have anything to do with RAID5 and the
> write hole at all (this is just a nice side effect) but with doing RAID on
> zoned block devices and ZONE APPEND writing.
> 
> [1] https://lpc.events/event/16/contributions/1235/attachments/1111/2132/BTRFS%20RAID-DP.pdf

Thanks for the correction :)

Re: [GIT PULL] bcachefs changes for 6.17

[Aquinas Admin]

> 
> The kernel has thrived for over 30 years not just because of technical
> excellence, but because it has (mostly) maintained a collaborative
> environment where developers can work together despite disagreements.
> That collaborative environment IS doing right by users.
> 
Come on? It's been around for 30 years because it's financially beneficial for 
some players. Should we forget about the letters and insults that flew around 
before 2018? The Code of Conduct wasn't introduced just like that. Well, 
that's just a small remark, in general. The fact is, there are no objections 
to the technical quality of Bcachefs. The objections are exclusively about 
Kent's personality and how he conducts his affairs. Maybe someone experienced 
in resolving such issues and handling personnel conflicts could suggest a 
solution? Analyze the situation and offer methods for resolution? Especially 
since the problem is far from being solely about Kent. I suggest that instead 
of threats, hasty conclusions, and quick decisions, we turn to professionals 
with the right expertise, who are surely present in the Linux Foundation. It 
will take time, but it will help everyone become better. I hope everyone 
understands that the right solution shouldn't be dictated by someone's 
feelings or grudges—regardless of who's involved.

Re: [GIT PULL] bcachefs changes for 6.17

[Martin Steigerwald]

Hi Kent, hi,

Kent Overstreet - 10.08.25, 05:17:44 CEST:
> I think you guys have been taking this a bit too far.

I am not sure who is right here. Or right to what extend.

And maybe that is not even the question.

But Kent, if your priority is the users of BCacheFS, look at the result:

The current result is a disservice to users.

Maybe even a huge one.

And likely a disservice to developers as well.

Is this result really what you like to achieve?

Cause if not, I can assure you that by doing the same thing over and over 
and over again you will yield exactly the same result over and over and 
over again. Just look at the past: This has been going in *predictable* 
cycles.

If you go on to do the same thing over and over again that drives off 
people, then that is exactly the result you will be receiving.

So if you do not adapt your behavior and do something *different* next 
time… *whether you like it or not* (!) you need to wait until someone else 
does. And that "until" may never happen. You can only influence what you 
do. So do you like to continue to give the power to change something in 
here to someone else by blaming everyone but you? That would be a lot of 
wasted energy.

You are not going to change the dynamics of power within the kernel 
development community by what you have been doing all the time.

Of course this goes the other way around as well: As long as people try to 
change each other in here, this is not going anywhere. The only change you 
can affect is a change within yourself.

So maybe take a while off mail, breathe deeply and meditate or do whatever 
helps you to see what within you contributes to the result we see here. I 
will do the same.

All in all again I point out: This cannot by solved by writing mails. You 
need to *speak* to each other.

Enough already.

Best,
-- 
Martin

Re: [GIT PULL] bcachefs changes for 6.17

[Carl E. Thompson]

> On 2025-08-09 7:24 PM PDT Theodore Ts'o <tytso@mit.edu> wrote:

> ... unless you can find someone willing to be your intermediary, and
> hopefully your coach in how to better work with other people ...

Going that route would just prolong Kent's attack on all of you (and the kernel) and make the damage worse. It's not a matter of getting him to understand; He's *always* understood what is needed from him but he does not believe in it and will not do it. Even though he is now (once again) promising to behave he won't. You all know that. Giving him yet another chance right now won't undo the damage that's already been done to Linux and will only allow him to inflict more.

Kent has already said many times, including in this thread, that he can and will continue to work on bcachefs even if it's removed from the kernel. Let him.

This is not the time to try to fix him. This is the time to protect the thing you've spent so much of your collective lives building.

Re: [GIT PULL] bcachefs changes for 6.17

[Aquinas Admin]

> Exactly. Which is why the Meta infrastructure is built completely on btrfs
> and its features. We have saved billions of dollars in infrastructure costs
> with the features and robustness of btrfs.
> 
> Btrfs doesn't need me or anybody else wandering around screaming about how
> everybody else sucks to gain users. The proof is in the pudding. If you read
> anything that I've wrote in my commentary about other file systems you will
> find nothing but praise and respect, because this is hard and we all make
> our tradeoffs.
> 
Sure, of course. The problem is that Meta doesn't need a general-purpose file 
system. And yes, and in general, Meta is not the kind of company that makes 
technically sound decisions. Tell me, does Meta still store user passwords in 
plain text? At least in March 2019, Meta was fined for that. Should we mention 
that the btrfs used at Meta differs from the btrfs in the kernel? Has "btrfs 
check" stopped completely destroying the file system? Has the problem with 
RAID5/6 (write hole) been solved in more than 20 years of development? Btrfs 
is not the file system that users want to see as a general-purpose file system. 
It works, of course, in certain scenarios. But if you run out of space, you 
even can't delete a file from it. That's the design—bravo! I'm surprised that a 
technically knowledgeable person would use "god-level" arguments. What file 
system have they saved money on compared to? How does a specific use case align 
with general-purpose scenarios? Why did you switch to discussing personal 
attacks in response to technical criticism?
> 
> Thanks,
> 
> Josef

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Mon, Aug 11, 2025 at 11:02:24PM +0700, Aquinas Admin wrote:
> > Exactly. Which is why the Meta infrastructure is built completely on btrfs
> > and its features. We have saved billions of dollars in infrastructure costs
> > with the features and robustness of btrfs.
> > 
> > Btrfs doesn't need me or anybody else wandering around screaming about how
> > everybody else sucks to gain users. The proof is in the pudding. If you read
> > anything that I've wrote in my commentary about other file systems you will
> > find nothing but praise and respect, because this is hard and we all make
> > our tradeoffs.
> > 
> Sure, of course. The problem is that Meta doesn't need a general-purpose file 
> system. And yes, and in general, Meta is not the kind of company that makes 
> technically sound decisions.

This is entirely unnecessary.

> Has the problem with RAID5/6 (write hole) been solved in more than 20
> years of development?

My understanding is that RAID5/6 v2, with the stripes tree, is intended
to fix this (the same as how it works in bcachefs).

Re: [GIT PULL] bcachefs changes for 6.17

[Matthew Wilcox]

On Sat, Aug 09, 2025 at 01:36:39PM -0400, Kent Overstreet wrote:
> Yes, this is accurate. I've been getting entirely too many emails from
> Linus about how pissed off everyone is, completely absent of details -
> or anything engineering related, for that matter. Lots of "you need to
> work with us better" - i.e. bend to demands - without being willing to
> put forth an argument that stands to scrutiny.

Kent, if you genuinely don't understand by now what it is that you do
that pisses people off, find someone you trust and get them to explain it
to you.  I've tried.  Other people have tried.  You react by dismissing
and insulting us, then pretending months later that you've done nothing
wrong.  Now you've pissed off Linus and he has ultimate power to decide to
accept your pull requests or not ... and he's decided not to.  You had
a lot of chances to fix your behaviour before it got to this point.
It's sad that you chose not to take any of them.

Can you really not see the difference between, eg Palmer's response here:
https://lore.kernel.org/lkml/mhng-655602B8-F102-4B0F-AF4A-4AB94A9F231F@Palmers-Mini.rwc.dabbelt.com/

and your response whenever Linus dares to critique even the smallest
parts of your pull requests?

[pointless attempt to divert the conversation to engineering snipped]

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Sun, Aug 10, 2025 at 12:01:18AM +0100, Matthew Wilcox wrote:
> On Sat, Aug 09, 2025 at 01:36:39PM -0400, Kent Overstreet wrote:
> > Yes, this is accurate. I've been getting entirely too many emails from
> > Linus about how pissed off everyone is, completely absent of details -
> > or anything engineering related, for that matter. Lots of "you need to
> > work with us better" - i.e. bend to demands - without being willing to
> > put forth an argument that stands to scrutiny.
> 
> Kent, if you genuinely don't understand by now what it is that you do
> that pisses people off, find someone you trust and get them to explain it
> to you.  I've tried.  Other people have tried.  You react by dismissing
> and insulting us, then pretending months later that you've done nothing
> wrong.  Now you've pissed off Linus and he has ultimate power to decide to
> accept your pull requests or not ... and he's decided not to.  You had
> a lot of chances to fix your behaviour before it got to this point.
> It's sad that you chose not to take any of them.
> 
> Can you really not see the difference between, eg Palmer's response here:
> https://lore.kernel.org/lkml/mhng-655602B8-F102-4B0F-AF4A-4AB94A9F231F@Palmers-Mini.rwc.dabbelt.com/
> 
> and your response whenever Linus dares to critique even the smallest
> parts of your pull requests?
> 
> [pointless attempt to divert the conversation to engineering snipped]

There's been pull requests where I've quietly dropped patches and
respun. I've never argued with Linus when it comes to other subsystems,
and there are things I've absolutely changed and addressed about the
bcachefs pull requests (e.g. switching to sending them on Thursdays;
which, unfortunately, took a three day shouting match before it came out
that that was the issue).

But when it comes to getting bugfixes out that users are waiting on; too
many of the pull requests have come over that, and "feedback" on those
has never come in the form of "do we need this? Can we dial things
back?" - too often it's been "oh hell no!"; and when I've got users I'm
supporting that's just not going to go well. Nor is it how things
generally work for other subsystems; Linus at one point gave me examples
of his other pull request feedback, while saying "this is totally
normal" - and my immediate response was, if I'd been getting that kind
of calm reasonable feedback, we'd have been in a very different place.

And you recently took to outright swearing at me on IRC, while I've been
staring at mm bugs and going "ok, the CONFIG_VM_DEBUG approach isn't
working".

And now, I just got an email from Linus saying "we're now talking about
git rm -rf in 6.18", after previously saying we just needed a
go-between.

So if that's the plan, I need to be arguing forcefully here, because a
lot is on the line for a lot of people.

I've heard from so many people saying things along the lines of "when
will it be ready, I _need_ something more reliable because I've been bit
too many times", and up until a month ago I've been telling people
"check back, we're nearly there, but check back soon".

Now, I finally clear out the bug tracker, and the bug reports and
feedback start pointing to "yes, we're pretty much there", and I have
this to face.

Oi vey.

Re: [GIT PULL] bcachefs changes for 6.17

[Jani Partanen]

On 10/08/2025 2.13, Kent Overstreet wrote:
> And now, I just got an email from Linus saying "we're now talking about
> git rm -rf in 6.18", after previously saying we just needed a
> go-between.
>
> So if that's the plan, I need to be arguing forcefully here, because a
> lot is on the line for a lot of people.


No that is not what you need to do. Arguing is the guarantee way that rm 
-rf will happen.

You need to *SHUT* *THE* *FUCK* *UP* *RIGHT* *NOW!* That is what you 
need to do and find very very fast some spokesman/woman/person who deal 
all the communication.

As I already said like month or 2 back, you are unable to do code and 
communication. You do one well (what I understand from comments, I am 
not a coder myself) and you suck on the other.


It does not help:

- that you are trashing constantly other filesystems.

- that you are bragging that you are here to challenge Linus.

  -that you cannot see your own faults.

- that you are playing the victim when shit hits the fan.


You and I have much same. I am also asshole who will argue for the sake 
of argument. So even when I know that I am wrong, I still keep going and 
that is behavior what I am not proud and I start to be too old that I 
can be fixed. After all, I am always right.

Linus is that kind of person who would really feed my hunger to argue. 
Seems like he works for you also.


Minor stuff I want to point out is that you do fearmongering by telling 
how other filesystems constantly break up and world really need bcachefs 
to save the world. This is quite pointless and stupid marketing. I have 
been running btrfs, ext4 and xfs years, sorry decades in multiple 
systems and I cannot even recall when I had last  time any issues with 
them what wasn't user error or hardware error. I am running even btrfs 
raid-5 on system what is not behind UPS and power outtakes is a thing here.


// Jani

Re: [GIT PULL] bcachefs changes for 6.17

[Martin Steigerwald]

Hi Jani, hi.

Jani Partanen - 12.08.25, 09:49:03 CEST:
> On 10/08/2025 2.13, Kent Overstreet wrote:
> > And now, I just got an email from Linus saying "we're now talking
> > about
> > git rm -rf in 6.18", after previously saying we just needed a
> > go-between.
> > 
> > So if that's the plan, I need to be arguing forcefully here, because a
> > lot is on the line for a lot of people.
> 
> No that is not what you need to do. Arguing is the guarantee way that rm
> -rf will happen.
> 
> You need to *SHUT* *THE* *FUCK* *UP* *RIGHT* *NOW!* That is what you
> need to do and find very very fast some spokesman/woman/person who deal
> all the communication.

I might have worded this differently, but in essence I agree.

The likely hood of BCacheFS pull requests being accepted again would have 
been far better without that initial comment and subsequent comments from 
you, Kent, (and some others) on this thread. Actually I felt that the 
thread was even going in a quite good direction, before your first comment 
to it. Some users spoke in favor of accepting the pull request. And I feel 
after your comment that momentum was completely destroyed. As I read your 
first comment, Kent, I thought: Oh no, now this is going to go downhill 
just like the other threads about the topic. And unfortunately that 
happened. It was predictable. Completely predictable.

And avoidable.

See, Kent, you argued all the time. Look at the results.

Again: Look at your behavior and look at the results. Really do it. Take 
time to do it.

It is not even about to what extent your arguments have been accurate or 
not. But more about the *way* you argued.

If you continue to do the same thing all over again, you will receive the 
same result. (Unless someone in charge changes their behavior in a 
significant way, but do you really like to make BCacheFS acceptance in 
kernel community dependent on that? You may wait a very long time then.)

See, it is not about right or wrong, but it is about where the lever to 
change the outcome actually is. And that lever is not in asking others to 
change. And it is also not within insisting that you are right, even in 
case you are right at least to some extent.

It may very well be that others overreacted. But it is outside of your 
power to change that. Especially not by blaming or asking them to change. 
Blaming is a certain way to give away power over what you experience to 
someone else.

Step back. Take some time to contemplate about what happened. Actually 
that is a good approach for everyone involved, I think.

Seek another approach to communicate *differently* from what you have 
already been doing all the time. Then you *might* achieve a different 
result.

Doing the same thing over and over again and expecting a different result 
is insane.

Best,
-- 
Martin

Re: [GIT PULL] bcachefs changes for 6.17

[Konstantin Shelekhin]

> Yes, this is accurate. I've been getting entirely too many emails from Linus about
> how pissed off everyone is, completely absent of details - or anything engineering
> related, for that matter.

That's because this is not an engineering problem, it's a communication problem. You just piss
people off for no good reason. Then people get tired of dealing with you and now we're here,
with Linus thinking about `git rm -rf fs/bcachesfs`. Will your users be happy? Probably not.
Will your sponsors be happy? Probably not either. Then why are you keep doing this?

If you really want to change the way things work go see a therapist. A competent enough doctor
probably can fix all that in a couple of months.

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Mon, Aug 11, 2025 at 12:51:11PM +0300, Konstantin Shelekhin wrote:
> >  Yes, this is accurate. I've been getting entirely too many emails from Linus about
> > how pissed off everyone is, completely absent of details - or anything engineering
> > related, for that matter.
> 
> That's because this is not an engineering problem, it's a communication problem. You just piss
> people off for no good reason. Then people get tired of dealing with you and now we're here,
> with Linus thinking about `git rm -rf fs/bcachesfs`. Will your users be happy? Probably not.
> Will your sponsors be happy? Probably not either. Then why are you keep doing this?
> 
> If you really want to change the way things work go see a therapist. A competent enough doctor
> probably can fix all that in a couple of months.

Konstantin, please tell me what you're basing this on.

The claims I've been hearing have simply lacked any kind of specifics;
if there's people I'd pissed off for no reason, I would've been happy to
apologize, but I'm not aware of the incidences you're claiming - not
within a year or more; I have made real efforts to tone things down.

On the other hand, for the only incidences I can remotely refer to in
the past year and a half, there has been:

- the mm developer who started outright swearing at me on IRC in a
  discussion about assertions
- the block layer developer who went on a four email rant where he,
  charitably, misread the spec or the patchset or both; all this over a
  patch to simply bring a warning in line with the actual NVME and SCSI
  specs.
- and reference to an incident at LSF, but the only noteworthy event
  that I can recall at the last LSF (a year and a half ago) was where a
  filesystem developer chased a Rust developer out of the community.

So: what am I supposed to make of all this?

To an outsider, I don't think any of this looks like a reasonable or
measured response, or professional behaviour. The problems with toxic
behaviour have been around long before I was prominent, and they're
still in evidence.

It is not reasonable or professional to jump from professional criticism
of code and work to personal attacks: it is our job to be critical of
our own and each other's code, and while that may bring up strong
feelings when we feel our work is attacked, that does not mean that it
is appropriate to lash out.

We have to separate the professional criticism from the personal.

It's also not reasonable or professional to always escelate tensions,
always look for the upper hand, and never de-escalate.

As a reminder, this all stems from a single patch, purely internal to
fs/bcachefs/, that was a critical, data integrity hotfix.

There has been a real pattern of hyper reactive, dramatic responses to
bugfixes in the bcachefs pull requests, all the way up to full blown
repeated threats of removing it from the kernel, and it's been toxic.

And it's happening again, complete with full blown rants right off the
bat in the private maintainer thread about not trusting my work (and I
have provided data and comparisons with btrfs specifically to rebut
that), all the way to "everyone hates you and you need therapy". That is
not reasonable or constructive.

This specific thread was in response to Linus saying that bcachefs was
imminently going to be git rm -rf'd, "or else", again with zero details
on that or else or anything that would make it actionable.

Look, I'm always happy to sit down, have a beer, talk things out, and
listen.

If there's people I have legitimately pissed off (and I do not include
anyone who starts swearing at me in a technical discussion) - let me
know, I'll listen. I'm not unapproachable, I'm not going to bite your
head off.

I've mended fences with people in the past; there were people I thought
I'd be odds with forever, but all it really takes is just talking. Say
what it is that you feel has affected, be willing to listen and turn,
and it gets better.

Re: [GIT PULL] bcachefs changes for 6.17

[Carl E. Thompson]

I seriously hope none of the kernel developers are foolish enough to be fooled (yet again) by this I'm-a-reasonable-guy-we-can-talk-this-out act. You've been there and done that.

Kent's perplexing behavior almost makes me want to put on a tinfoil hat. Is it simply mental illness or is it something more? Is he being egged on by backers who *want* to destabilize the leadership of Linux for whatever reason? It's hard to see how any individual could be this far out there without help.

And I'll point out what's obvious to people who have followed this closely but may not be to people who read an occasional email thread like this one: A very large portion of what Kent says including in this email is just factually wrong. Either he is an unashamed and extremely prolific liar or he is very sick.

Carl

> On 2025-08-11 7:26 AM PDT Kent Overstreet <kent.overstreet@linux.dev> wrote:
> 
>  
> On Mon, Aug 11, 2025 at 12:51:11PM +0300, Konstantin Shelekhin wrote:
> > >  Yes, this is accurate. I've been getting entirely too many emails from Linus about
> > > how pissed off everyone is, completely absent of details - or anything engineering
> > > related, for that matter.
> > 
> > That's because this is not an engineering problem, it's a communication problem. You just piss
> > people off for no good reason. Then people get tired of dealing with you and now we're here,
> > with Linus thinking about `git rm -rf fs/bcachesfs`. Will your users be happy? Probably not.
> > Will your sponsors be happy? Probably not either. Then why are you keep doing this?
> > 
> > If you really want to change the way things work go see a therapist. A competent enough doctor
> > probably can fix all that in a couple of months.
> 
> Konstantin, please tell me what you're basing this on.
> 
> The claims I've been hearing have simply lacked any kind of specifics;
> if there's people I'd pissed off for no reason, I would've been happy to
> apologize, but I'm not aware of the incidences you're claiming - not
> within a year or more; I have made real efforts to tone things down.
> 
> On the other hand, for the only incidences I can remotely refer to in
> the past year and a half, there has been:
> 
> - the mm developer who started outright swearing at me on IRC in a
>   discussion about assertions
> - the block layer developer who went on a four email rant where he,
>   charitably, misread the spec or the patchset or both; all this over a
>   patch to simply bring a warning in line with the actual NVME and SCSI
>   specs.
> - and reference to an incident at LSF, but the only noteworthy event
>   that I can recall at the last LSF (a year and a half ago) was where a
>   filesystem developer chased a Rust developer out of the community.
> 
> So: what am I supposed to make of all this?
> 
> To an outsider, I don't think any of this looks like a reasonable or
> measured response, or professional behaviour. The problems with toxic
> behaviour have been around long before I was prominent, and they're
> still in evidence.
> 
> It is not reasonable or professional to jump from professional criticism
> of code and work to personal attacks: it is our job to be critical of
> our own and each other's code, and while that may bring up strong
> feelings when we feel our work is attacked, that does not mean that it
> is appropriate to lash out.
> 
> We have to separate the professional criticism from the personal.
> 
> It's also not reasonable or professional to always escelate tensions,
> always look for the upper hand, and never de-escalate.
> 
> As a reminder, this all stems from a single patch, purely internal to
> fs/bcachefs/, that was a critical, data integrity hotfix.
> 
> There has been a real pattern of hyper reactive, dramatic responses to
> bugfixes in the bcachefs pull requests, all the way up to full blown
> repeated threats of removing it from the kernel, and it's been toxic.
> 
> And it's happening again, complete with full blown rants right off the
> bat in the private maintainer thread about not trusting my work (and I
> have provided data and comparisons with btrfs specifically to rebut
> that), all the way to "everyone hates you and you need therapy". That is
> not reasonable or constructive.
> 
> This specific thread was in response to Linus saying that bcachefs was
> imminently going to be git rm -rf'd, "or else", again with zero details
> on that or else or anything that would make it actionable.
> 
> Look, I'm always happy to sit down, have a beer, talk things out, and
> listen.
> 
> If there's people I have legitimately pissed off (and I do not include
> anyone who starts swearing at me in a technical discussion) - let me
> know, I'll listen. I'm not unapproachable, I'm not going to bite your
> head off.
> 
> I've mended fences with people in the past; there were people I thought
> I'd be odds with forever, but all it really takes is just talking. Say
> what it is that you feel has affected, be willing to listen and turn,
> and it gets better.

Re: [GIT PULL] bcachefs changes for 6.17

[Malte Schröder]

On 11.08.25 20:13, Carl E. Thompson wrote:
> I seriously hope none of the kernel developers are foolish enough to be fooled (yet again) by this I'm-a-reasonable-guy-we-can-talk-this-out act. You've been there and done that.
>
> Kent's perplexing behavior almost makes me want to put on a tinfoil hat. Is it simply mental illness or is it something more? Is he being egged on by backers who *want* to destabilize the leadership of Linux for whatever reason? It's hard to see how any individual could be this far out there without help.
>
> And I'll point out what's obvious to people who have followed this closely but may not be to people who read an occasional email thread like this one: A very large portion of what Kent says including in this email is just factually wrong. Either he is an unashamed and extremely prolific liar or he is very sick.
>
> Carl

Frankly for me as a user who does probably not know the hole picture you
seem to just be spewing paranoid hate into these threads which I do not
quite understand. Yes, Kent can be off-putting, but really, that is
something I often observe from other people as well, the tone on LKML
tends to be pretty harsh.

My involvement in bcachefs is that of an early adopter and hence, a
tester. I find working with him productive. I give him bug reports,
observations and data and he fixes those. If I did something stupid, he
will point that out, and very directly so.

So what you call a "I'm-a-reasonable-guy-we-can-talk-this-out act" is
actually how he can and does behave, at least when interacting on IRC
with his users, testers and co-developers.

So maybe if we can dial the personal attacks down a few notches
(including against btrfs, though I have my reasons why I jumped from
it to bcachefs like two years ago) and have a calm discussion it might
be possible to build new bridges?


/Malte

>
>> On 2025-08-11 7:26 AM PDT Kent Overstreet <kent.overstreet@linux.dev> wrote:
>>
>>  
>> On Mon, Aug 11, 2025 at 12:51:11PM +0300, Konstantin Shelekhin wrote:
>>>>  Yes, this is accurate. I've been getting entirely too many emails from Linus about
>>>> how pissed off everyone is, completely absent of details - or anything engineering
>>>> related, for that matter.
>>> That's because this is not an engineering problem, it's a communication problem. You just piss
>>> people off for no good reason. Then people get tired of dealing with you and now we're here,
>>> with Linus thinking about `git rm -rf fs/bcachesfs`. Will your users be happy? Probably not.
>>> Will your sponsors be happy? Probably not either. Then why are you keep doing this?
>>>
>>> If you really want to change the way things work go see a therapist. A competent enough doctor
>>> probably can fix all that in a couple of months.
>> Konstantin, please tell me what you're basing this on.
>>
>> The claims I've been hearing have simply lacked any kind of specifics;
>> if there's people I'd pissed off for no reason, I would've been happy to
>> apologize, but I'm not aware of the incidences you're claiming - not
>> within a year or more; I have made real efforts to tone things down.
>>
>> On the other hand, for the only incidences I can remotely refer to in
>> the past year and a half, there has been:
>>
>> - the mm developer who started outright swearing at me on IRC in a
>>   discussion about assertions
>> - the block layer developer who went on a four email rant where he,
>>   charitably, misread the spec or the patchset or both; all this over a
>>   patch to simply bring a warning in line with the actual NVME and SCSI
>>   specs.
>> - and reference to an incident at LSF, but the only noteworthy event
>>   that I can recall at the last LSF (a year and a half ago) was where a
>>   filesystem developer chased a Rust developer out of the community.
>>
>> So: what am I supposed to make of all this?
>>
>> To an outsider, I don't think any of this looks like a reasonable or
>> measured response, or professional behaviour. The problems with toxic
>> behaviour have been around long before I was prominent, and they're
>> still in evidence.
>>
>> It is not reasonable or professional to jump from professional criticism
>> of code and work to personal attacks: it is our job to be critical of
>> our own and each other's code, and while that may bring up strong
>> feelings when we feel our work is attacked, that does not mean that it
>> is appropriate to lash out.
>>
>> We have to separate the professional criticism from the personal.
>>
>> It's also not reasonable or professional to always escelate tensions,
>> always look for the upper hand, and never de-escalate.
>>
>> As a reminder, this all stems from a single patch, purely internal to
>> fs/bcachefs/, that was a critical, data integrity hotfix.
>>
>> There has been a real pattern of hyper reactive, dramatic responses to
>> bugfixes in the bcachefs pull requests, all the way up to full blown
>> repeated threats of removing it from the kernel, and it's been toxic.
>>
>> And it's happening again, complete with full blown rants right off the
>> bat in the private maintainer thread about not trusting my work (and I
>> have provided data and comparisons with btrfs specifically to rebut
>> that), all the way to "everyone hates you and you need therapy". That is
>> not reasonable or constructive.
>>
>> This specific thread was in response to Linus saying that bcachefs was
>> imminently going to be git rm -rf'd, "or else", again with zero details
>> on that or else or anything that would make it actionable.
>>
>> Look, I'm always happy to sit down, have a beer, talk things out, and
>> listen.
>>
>> If there's people I have legitimately pissed off (and I do not include
>> anyone who starts swearing at me in a technical discussion) - let me
>> know, I'll listen. I'm not unapproachable, I'm not going to bite your
>> head off.
>>
>> I've mended fences with people in the past; there were people I thought
>> I'd be odds with forever, but all it really takes is just talking. Say
>> what it is that you feel has affected, be willing to listen and turn,
>> and it gets better.

Re: [GIT PULL] bcachefs changes for 6.17

[Carl E. Thompson]

> On 2025-08-11 11:40 AM PDT Malte Schröder <malte.schroeder@tnxip.de> wrote:
> ...

> Frankly for me as a user who does probably not know the hole picture you
> seem to just be spewing paranoid hate into these threads which I do not
> quite understand.

I apologize for coming across that way. I guess I'm just very frustrated at this whole situation and the fact that it appears from my perspective to be damaging the reputation and credibility of Linux which is something I care about very deeply.

And I'm angry. I'm angry because of the damage to Linux and because Kent appears to be misrepresenting events in a way that make others whom I respect look bad. For example, here in this thread a key point Kent is claiming is that no one has ever told him specifically anything that he's done wrong and essentially that other kernel developers are attacking him for no good reason. That's simply not true. Linus has explained his mistakes to Kent on multiple occasions. Other kernel developers have tried to help him see what he's doing wrong. Random users (including I) have tried to help him interact better with others. It is simply not true that no one has told him what he's done wrong.

There are many other things about Kent's recounting of events and things he has said in this thread that also seem to be objectively not true. If anyone thinks it would be useful I can itemize those things I've noticed.

I'm also angry because I'm a long-time bcachefs supporter. I started using bcachefs years ago long before it was in the kernel. I've put a lot of my own work into running it, testing it and submitting bug reports. Up until a few months ago I had about 20 bcachefs filesystems of varying sizes spread across my personal workstations, servers and lab. I even integrated bcachefs as a core part of a relatively large (by my standards) project I'm hoping to release some time before the end of the year. There were some warning signs along the way but I ignored them because I really, really wanted bcachefs. 

But eventually I had to ask myself... If Kent repeatedly brings conflict and discord to a group that needs to work closely and trust each other, and if Kent repeatedly makes the same interpersonal mistakes and doesn't learn from them, and if Kent seemingly regularly misrepresents things... Can I really trust him or his code? My personal answer to that is "no." So I've migrated everything I have from bcachefs and I'm angry about wasting all the time and effort I put into it.

Finally I'm angry because so many people appear to be thinking only of themselves. They appear to think: *I* really want to use bcachefs and it would be much more convenient for *me* if it were in the kernel therefore it should be in the kernel and the other kernel developers should let Kent do whatever he wants no matter how it makes them feel about their work environment.

My opinion is that's a really great recipe for making Linux worse: Suck the joy out of the other kernel developers' jobs by forcing them to work with someone who seemingly doesn't respect anyone but himself simply because *we* (the users) really want bcachefs. Go that route and valuable contributors will mentally check out or worse leave altogether. It will spread like cancer (and probably already is). It's an absolute fact that people who are unhappy in the workplace do worse work. Let's keep the kernel developers happy.

Again, I apologize for being overly harsh.

Carl

PS: I do hope that Kent can work things out and figure out how to contribute in a way that's useful for others and makes him happy. But we sometimes have to weigh giving someone like Kent another chance against the harm keeping him around does to other people we care about.

Re: [GIT PULL] bcachefs changes for 6.17

[Aquinas Admin]

> Either he is an unashamed and extremely prolific liar or
> he is very sick.

Accusations need to be supported by facts. You don't have any. And you are 
currently harassing the developer, which is completely unjustified. I think 
those Kent was talking about can certainly provide arguments if they want to. 
But this behavior is extremely offensive, at the very least.

Re: [GIT PULL] bcachefs changes for 6.17

[Martin Steigerwald]

Hi.

Carl E. Thompson - 11.08.25, 20:13:58 CEST:
> Kent's perplexing behavior [… ad hominen attack …]

Please, stop those ad hominem attacks.

Everyone.

It is not doing any good.


How about starting from a place of assuming good intentions instead? And 
then try to understand where everyone is coming from? That would be much 
more in line with a good code of conduct.

Best,
-- 
Martin

Re: [GIT PULL] bcachefs changes for 6.17

[Konstantin Shelekhin]

On 11/08/2025 17:26, Kent Overstreet wrote:

> Konstantin, please tell me what you're basing this on.

This, for example: - 
https://lore.kernel.org/all/9db17620-4b93-4c01-b7f8-ecab83b12d0f@kernel.dk/ 
- 
https://lore.kernel.org/all/20250308155011.1742461-1-kent.overstreet@linux.dev/ 
I've just lurked around lore for a couple of minutes.

> The claims I've been hearing have simply lacked any kind of specifics;
if there's people I'd pissed off for no reason, I would've been happy to
apologize, but I'm not aware of the incidences you're claiming - not
within a year or more; I have made real efforts to tone things down.

Both links are four months old.

> On the other hand, for the only incidences I can remotely refer to in
the past year and a half, there has been:
>
> - the mm developer who started outright swearing at me on IRC in a
> discussion about assertions

That is very unfortunate.

> - the block layer developer who went on a four email rant where he,
> charitably, misread the spec or the patchset or both; all this over a
> patch to simply bring a warning in line with the actual NVME and SCSI
> specs.

My team has contributed to NVMe and SCSI subsystems, so I have some
experience working with Jens, Martin and Christoph. Nobody on my team
had this level of drama, even when we were in disagreement about specs
or intended behavior.

> - and reference to an incident at LSF, but the only noteworthy event
>  that I can recall at the last LSF (a year and a half ago) was where a
>  filesystem developer chased a Rust developer out of the community.
>
> So: what am I supposed to make of all this?

That you're trying to excuse your communication issues with other people's
communication issues?

> To an outsider, I don't think any of this looks like a reasonable or
> measured response, or professional behaviour. The problems with toxic
> behaviour have been around long before I was prominent, and they're
> still in evidence.

Again, "Timmy also did that" is not a very good excuse for a grown up adult.

> It is not reasonable or professional to jump from professional criticism
> of code and work to personal attacks: it is our job to be critical of
> our own and each other's code, and while that may bring up strong
> feelings when we feel our work is attacked, that does not mean that it
> is appropriate to lash out.

This is _NOT_ about the code. That's the essence of your struggles. Forget
about the code, the code is not the issue here. Communication is.

> As a reminder, this all stems from a single patch, purely internal to
> fs/bcachefs/, that was a critical, data integrity hotfix.

But this does not matter. No matter how important your fix is.

> There has been a real pattern of hyper reactive, dramatic responses to
> bugfixes in the bcachefs pull requests, all the way up to full blown
> repeated threats of removing it from the kernel, and it's been toxic.

Play stupid games, win stupid prizes. Piss off a maintainer long enough,
he will refuse to work with you. Who would've thought, eh?

> And it's happening again, complete with full blown rants right off the
> bat in the private maintainer thread about not trusting my work (and I
> have provided data and comparisons with btrfs specifically to rebut
> that), all the way to "everyone hates you and you need therapy". That is
> not reasonable or constructive.

You seem to ignore what people keep telling you: _COMMUNICATION_ is the
problem, not the _CODE_. So arguments about how btrfs performs compared
to bcachefs do not matter.

Your result is not the issue, the journey with you is.

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Tue, Aug 12, 2025 at 12:04:53AM +0300, Konstantin Shelekhin wrote:
> On 11/08/2025 17:26, Kent Overstreet wrote:
> 
> > Konstantin, please tell me what you're basing this on.
> 
> This, for example: -
> https://lore.kernel.org/all/9db17620-4b93-4c01-b7f8-ecab83b12d0f@kernel.dk/
> - https://lore.kernel.org/all/20250308155011.1742461-1-kent.overstreet@linux.dev/
> I've just lurked around lore for a couple of minutes.

So for the dm-faulty one - md-flakey was removed without anyone ever
testing the equivalent functionality in the replacement - it was pretty
disruptive.

I'll fill you in on the other one off list, the tensions behind that
flare up go back years, and I don't think anyone wants that stuff
dredged up yet again on the list - Christoph and I in particular have
been quite frosty to each other at times, but we've always respected
each other and lately I think we've both made signs that we're actually
trying to work better together.

> > - and reference to an incident at LSF, but the only noteworthy event
> >  that I can recall at the last LSF (a year and a half ago) was where a
> >  filesystem developer chased a Rust developer out of the community.
> > 
> > So: what am I supposed to make of all this?
> 
> That you're trying to excuse your communication issues with other people's
> communication issues?

No, definitely not.

I don't think endlessly rehashing old stuff really solves anything. When
tensions are high, I try to narrow the focus and just focus on the work
at hand.

But the only thing I've found that really solves things in the long run
is just - talking. Talking when there isn't work hanging over our heads
that needs to be focused on, talking and listening without making
demands and trying to actually understand each other's points of view.

Re: [GIT PULL] bcachefs changes for 6.17

[asdx]

On 8/11/25 11:26 AM, Kent Overstreet wrote:
> On Mon, Aug 11, 2025 at 12:51:11PM +0300, Konstantin Shelekhin wrote:
>>>   Yes, this is accurate. I've been getting entirely too many emails from Linus about
>>> how pissed off everyone is, completely absent of details - or anything engineering
>>> related, for that matter.
>> That's because this is not an engineering problem, it's a communication problem. You just piss
>> people off for no good reason. Then people get tired of dealing with you and now we're here,
>> with Linus thinking about `git rm -rf fs/bcachesfs`. Will your users be happy? Probably not.
>> Will your sponsors be happy? Probably not either. Then why are you keep doing this?
>>
>> If you really want to change the way things work go see a therapist. A competent enough doctor
>> probably can fix all that in a couple of months.
> Konstantin, please tell me what you're basing this on.
>
> The claims I've been hearing have simply lacked any kind of specifics;
> if there's people I'd pissed off for no reason, I would've been happy to
> apologize, but I'm not aware of the incidences you're claiming - not
> within a year or more; I have made real efforts to tone things down.
>
You keep lying. How can you be so cynical? Just two days ago you were
complaining on #bcache about how much control Linus has over Linux and there
was a lot of talk about getting him removed from Linux via CoC action.

All you do is act in bad faith and when you get called out for your nonsense,
you resort to playing the victim.

You are not fooling anyone anymore.

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Tue, Aug 12, 2025 at 03:52:39AM -0300, asdx wrote:
> 
> On 8/11/25 11:26 AM, Kent Overstreet wrote:
> > On Mon, Aug 11, 2025 at 12:51:11PM +0300, Konstantin Shelekhin wrote:
> > > >   Yes, this is accurate. I've been getting entirely too many emails from Linus about
> > > > how pissed off everyone is, completely absent of details - or anything engineering
> > > > related, for that matter.
> > > That's because this is not an engineering problem, it's a communication problem. You just piss
> > > people off for no good reason. Then people get tired of dealing with you and now we're here,
> > > with Linus thinking about `git rm -rf fs/bcachesfs`. Will your users be happy? Probably not.
> > > Will your sponsors be happy? Probably not either. Then why are you keep doing this?
> > > 
> > > If you really want to change the way things work go see a therapist. A competent enough doctor
> > > probably can fix all that in a couple of months.
> > Konstantin, please tell me what you're basing this on.
> > 
> > The claims I've been hearing have simply lacked any kind of specifics;
> > if there's people I'd pissed off for no reason, I would've been happy to
> > apologize, but I'm not aware of the incidences you're claiming - not
> > within a year or more; I have made real efforts to tone things down.
> > 
> You keep lying. How can you be so cynical? Just two days ago you were
> complaining on #bcache about how much control Linus has over Linux and there
> was a lot of talk about getting him removed from Linux via CoC action.

Are you the same guy who was just posting this on Phoronix? Either
you're trolling, or you misread something.

For the record, I'm one of the more anti CoC people out there - I agree
with the spirit of their goals, not so much the approach. I would never
invoke them on anyone; I prefer to talk things out (and I don't mind
getting flamed, so long as it doesn't get in the way of the work).

Re: [GIT PULL] bcachefs changes for 6.17

[asdx]

On 8/12/25 4:04 AM, Kent Overstreet wrote:
> On Tue, Aug 12, 2025 at 03:52:39AM -0300, asdx wrote:
>> On 8/11/25 11:26 AM, Kent Overstreet wrote:
>>> On Mon, Aug 11, 2025 at 12:51:11PM +0300, Konstantin Shelekhin wrote:
>>>>>    Yes, this is accurate. I've been getting entirely too many emails from Linus about
>>>>> how pissed off everyone is, completely absent of details - or anything engineering
>>>>> related, for that matter.
>>>> That's because this is not an engineering problem, it's a communication problem. You just piss
>>>> people off for no good reason. Then people get tired of dealing with you and now we're here,
>>>> with Linus thinking about `git rm -rf fs/bcachesfs`. Will your users be happy? Probably not.
>>>> Will your sponsors be happy? Probably not either. Then why are you keep doing this?
>>>>
>>>> If you really want to change the way things work go see a therapist. A competent enough doctor
>>>> probably can fix all that in a couple of months.
>>> Konstantin, please tell me what you're basing this on.
>>>
>>> The claims I've been hearing have simply lacked any kind of specifics;
>>> if there's people I'd pissed off for no reason, I would've been happy to
>>> apologize, but I'm not aware of the incidences you're claiming - not
>>> within a year or more; I have made real efforts to tone things down.
>>>
>> You keep lying. How can you be so cynical? Just two days ago you were
>> complaining on #bcache about how much control Linus has over Linux and there
>> was a lot of talk about getting him removed from Linux via CoC action.
> Are you the same guy who was just posting this on Phoronix? Either
> you're trolling, or you misread something.
>
> For the record, I'm one of the more anti CoC people out there - I agree
> with the spirit of their goals, not so much the approach. I would never
> invoke them on anyone; I prefer to talk things out (and I don't mind
> getting flamed, so long as it doesn't get in the way of the work).

I read your messages well.

Linus Torvalds is way more valuable than bcachefs. Please back off.

Re: [GIT PULL] bcachefs changes for 6.17

[Keith Busch]

On Mon, Aug 11, 2025 at 10:26:03AM -0400, Kent Overstreet wrote:
> On the other hand, for the only incidences I can remotely refer to in
> the past year and a half, there has been:
...

> - the block layer developer who went on a four email rant where he,
>   charitably, misread the spec or the patchset or both; all this over a
>   patch to simply bring a warning in line with the actual NVME and SCSI
>   specs.

Are you talking about this thread?

  https://lore.kernel.org/linux-block/20250311201518.3573009-14-kent.overstreet@linux.dev/

I try to closely follow those lists, and that's the only thread I recall
that even slightly rings a bell from your description, however it's not
an accurate description (you were the one who misread the specs there; I
tried to help bridge the gap). I recall the interaction was pretty tame
though, so maybe you're talking about something else. Perhaps a link for
context if I got it wrong?

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Tue, Aug 12, 2025 at 01:35:56PM -0600, Keith Busch wrote:
> On Mon, Aug 11, 2025 at 10:26:03AM -0400, Kent Overstreet wrote:
> > On the other hand, for the only incidences I can remotely refer to in
> > the past year and a half, there has been:
> ...
> 
> > - the block layer developer who went on a four email rant where he,
> >   charitably, misread the spec or the patchset or both; all this over a
> >   patch to simply bring a warning in line with the actual NVME and SCSI
> >   specs.
> 
> Are you talking about this thread?
> 
>   https://lore.kernel.org/linux-block/20250311201518.3573009-14-kent.overstreet@linux.dev/
> 
> I try to closely follow those lists, and that's the only thread I recall
> that even slightly rings a bell from your description, however it's not
> an accurate description (you were the one who misread the specs there; I
> tried to help bridge the gap). I recall the interaction was pretty tame
> though, so maybe you're talking about something else. Perhaps a link for
> context if I got it wrong?

I've since seen a lot of actual test data from SCSI hard drives - fua
reads are definitely not cached, without exception across manufacturers.

On NVME the situation is much murkier.

Re: [GIT PULL] bcachefs changes for 6.17

[Keith Busch]

On Tue, Aug 12, 2025 at 04:03:17PM -0400, Kent Overstreet wrote:
> On Tue, Aug 12, 2025 at 01:35:56PM -0600, Keith Busch wrote:
> > On Mon, Aug 11, 2025 at 10:26:03AM -0400, Kent Overstreet wrote:
> > > On the other hand, for the only incidences I can remotely refer to in
> > > the past year and a half, there has been:
> > ...
> > 
> > > - the block layer developer who went on a four email rant where he,
> > >   charitably, misread the spec or the patchset or both; all this over a
> > >   patch to simply bring a warning in line with the actual NVME and SCSI
> > >   specs.
> > 
> > Are you talking about this thread?
> > 
> >   https://lore.kernel.org/linux-block/20250311201518.3573009-14-kent.overstreet@linux.dev/
> > 
> > I try to closely follow those lists, and that's the only thread I recall
> > that even slightly rings a bell from your description, however it's not
> > an accurate description (you were the one who misread the specs there; I
> > tried to help bridge the gap). I recall the interaction was pretty tame
> > though, so maybe you're talking about something else. Perhaps a link for
> > context if I got it wrong?
> 
> I've since seen a lot of actual test data from SCSI hard drives - fua
> reads are definitely not cached, without exception across manufacturers.
> 
> On NVME the situation is much murkier.

Okay, I take it I got the right thread then. I just wanted to get the
context. For the record, all the specs align with what read fua does
(anyone interested can visit the linked thread, I don't want to hijack
this one for it).

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Tue, Aug 12, 2025 at 02:30:44PM -0600, Keith Busch wrote:
> On Tue, Aug 12, 2025 at 04:03:17PM -0400, Kent Overstreet wrote:
> > On Tue, Aug 12, 2025 at 01:35:56PM -0600, Keith Busch wrote:
> > > On Mon, Aug 11, 2025 at 10:26:03AM -0400, Kent Overstreet wrote:
> > > > On the other hand, for the only incidences I can remotely refer to in
> > > > the past year and a half, there has been:
> > > ...
> > > 
> > > > - the block layer developer who went on a four email rant where he,
> > > >   charitably, misread the spec or the patchset or both; all this over a
> > > >   patch to simply bring a warning in line with the actual NVME and SCSI
> > > >   specs.
> > > 
> > > Are you talking about this thread?
> > > 
> > >   https://lore.kernel.org/linux-block/20250311201518.3573009-14-kent.overstreet@linux.dev/
> > > 
> > > I try to closely follow those lists, and that's the only thread I recall
> > > that even slightly rings a bell from your description, however it's not
> > > an accurate description (you were the one who misread the specs there; I
> > > tried to help bridge the gap). I recall the interaction was pretty tame
> > > though, so maybe you're talking about something else. Perhaps a link for
> > > context if I got it wrong?
> > 
> > I've since seen a lot of actual test data from SCSI hard drives - fua
> > reads are definitely not cached, without exception across manufacturers.
> > 
> > On NVME the situation is much murkier.
> 
> Okay, I take it I got the right thread then. I just wanted to get the
> context. For the record, all the specs align with what read fua does
> (anyone interested can visit the linked thread, I don't want to hijack
> this one for it).

If you're interested, is it time to do some spec quoting and language
lawyering?

Re: [GIT PULL] bcachefs changes for 6.17

[Keith Busch]

On Tue, Aug 12, 2025 at 04:31:53PM -0400, Kent Overstreet wrote:
> If you're interested, is it time to do some spec quoting and language
> lawyering?

If you want to start or restart a thread on the block list specificaly
for that topic, then sure, happy to spec talk with you. But I don't want
to chat on this one. I just wanted to know what you were talking about
because the description seemed underhanded.

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Tue, Aug 12, 2025 at 02:38:26PM -0600, Keith Busch wrote:
> On Tue, Aug 12, 2025 at 04:31:53PM -0400, Kent Overstreet wrote:
> > If you're interested, is it time to do some spec quoting and language
> > lawyering?
> 
> If you want to start or restart a thread on the block list specificaly
> for that topic, then sure, happy to spec talk with you. But I don't want
> to chat on this one. I just wanted to know what you were talking about
> because the description seemed underhanded.

Not underhanded, just straightforward - I've seen the test data, and the
spec seemed pretty clear to me...

Re: [GIT PULL] bcachefs changes for 6.17

[Keith Busch]

On Tue, Aug 12, 2025 at 04:45:48PM -0400, Kent Overstreet wrote:
> On Tue, Aug 12, 2025 at 02:38:26PM -0600, Keith Busch wrote:
> > On Tue, Aug 12, 2025 at 04:31:53PM -0400, Kent Overstreet wrote:
> > > If you're interested, is it time to do some spec quoting and language
> > > lawyering?
> > 
> > If you want to start or restart a thread on the block list specificaly
> > for that topic, then sure, happy to spec talk with you. But I don't want
> > to chat on this one. I just wanted to know what you were talking about
> > because the description seemed underhanded.
> 
> Not underhanded, just straightforward - I've seen the test data, and the
> spec seemed pretty clear to me...

  "the block layer developer who went on a four email rant where he,
   charitably, misread the spec or the patchset or both"

Please revisit the thread and let me know me if you still stand by that
description. I've no idea if you're talking about me or one of the other
block developers on it, but I frankly don't see anything resembling what
you're describing.

Re: [GIT PULL] bcachefs changes for 6.17

[Kent Overstreet]

On Tue, Aug 12, 2025 at 02:54:21PM -0600, Keith Busch wrote:
> On Tue, Aug 12, 2025 at 04:45:48PM -0400, Kent Overstreet wrote:
> > On Tue, Aug 12, 2025 at 02:38:26PM -0600, Keith Busch wrote:
> > > On Tue, Aug 12, 2025 at 04:31:53PM -0400, Kent Overstreet wrote:
> > > > If you're interested, is it time to do some spec quoting and language
> > > > lawyering?
> > > 
> > > If you want to start or restart a thread on the block list specificaly
> > > for that topic, then sure, happy to spec talk with you. But I don't want
> > > to chat on this one. I just wanted to know what you were talking about
> > > because the description seemed underhanded.
> > 
> > Not underhanded, just straightforward - I've seen the test data, and the
> > spec seemed pretty clear to me...
> 
>   "the block layer developer who went on a four email rant where he,
>    charitably, misread the spec or the patchset or both"
> 
> Please revisit the thread and let me know me if you still stand by that
> description. I've no idea if you're talking about me or one of the other
> block developers on it, but I frankly don't see anything resembling what
> you're describing.

Well, since you asked, Christoph...

I want to say - no hard feelings, things being frosty between us goes
way back, and we've recently made efforts to work better together. But
that was pretty hard to respond to.

Re: [GIT PULL] bcachefs changes for 6.17

[Aquinas Admin]

В письме от понедельник, 11 августа 2025 г. 16:51:11 Красноярск, стандартное 
время пользователь Konstantin Shelekhin написал:
> > Yes, this is accurate. I've been getting entirely too many emails from
> >Linus about>
> > how pissed off everyone is, completely absent of details - or anything
> > engineering related, for that matter.
> 
> That's because this is not an engineering problem, it's a communication
> problem. You just piss people off for no good reason. Then people get tired
> of dealing with you and now we're here, with Linus thinking about `git rm
> -rf fs/bcachesfs`. Will your users be happy? Probably not. Will your
> sponsors be happy? Probably not either. Then why are you keep doing this?
> 
> If you really want to change the way things work go see a therapist. A
> competent enough doctor probably can fix all that in a couple of months.

Come on? It's been around for 30 years because it's financially beneficial for 
some players. Should we forget about the letters and insults that flew around 
before 2018? The Code of Conduct wasn't introduced just like that. Well, 
that's just a small remark, in general. The fact is, there are no objections 
to the technical quality of Bcachefs. The objections are exclusively about 
Kent's personality and how he conducts his affairs. Maybe someone experienced 
in resolving such issues and handling personnel conflicts could suggest a 
solution? Analyze the situation and offer methods for resolution? Especially 
since the problem is far from being solely about Kent. I suggest that instead 
of threats, hasty conclusions, and quick decisions, we turn to professionals 
with the right expertise, who are surely present in the Linux Foundation. It 
will take time, but it will help everyone become better. I hope everyone 
understands that the right solution shouldn't be dictated by someone's 
feelings or grudges—regardless of who's involved.

Re: [GIT PULL] bcachefs changes for 6.17

[Gerhard Wiesinger]

On 07.08.2025 14:42, Aquinas Admin wrote:
> This "We don't start adding new features just because you found other bugs"
> sounds absurd. So, if we find bugs, they can't be fixed if we need to extend the
> functionality before the release? Excuse me, what? I clearly understand the
> absurdity of this requirement. Because it effectively means that if we notice
> that ext4 is corrupting data only in RC simply because some code was forgotten
> to be added to a subsystem during the release window, we can't accept the fix
> because it requires adding new functionality and we will release the version
> with the problem. I clearly understand that this is not the exact situation,
> but it was done as a solution to an existing user's problem. Moreover, the
> amount of changes is not that significant. Especially since it's not really a
> fix but a workaround, a useful one that can actually help some real users in
> certain situations.
>
> new USB serial driver device ids 6.12-rc7 is this new functionality or not?
> ALSA: hda/realtek: Support mute LED on HP Laptop 14-dq2xxx 6.11-rc7 - new
> functionality?
> ALSA: hda/realtek: Enable Mute Led for HP Victus 15-fb1xxx - 6.11-rc7
> Octeontx2-pf: ethtool: support multi advertise mode - 6.15-rc5
> drm/i915/flipq: Implement Wa_18034343758
> drm/i915/display: Add drm_panic support
> Is this different? Or are the rules somehow not for everyone?
>
> But no, instead, this is what happened.

That mentioned code parts are AFAIK NOT experimental and therefore 
stable. But still include feature request in RC7 phase. Will that be 
removed, too?

I think we should sort out 3 topics:

1. Technical topics

2. Working together from an organizational/process perspective

3. Working together from a personal perspective

my 2 cents.

Ciao,

Gerhard

Re: [GIT PULL] bcachefs changes for 6.17

[Martin Steigerwald]

Hi.

Malte Schröder - 05.08.25, 23:19:21 CEST:
> So, no merge yet? That really is a bummer. I was really hoping to
> finally be able to run mainline Linux again on my boxes (yes, I
> converted all of them to bcachefs early this year), now that pretty much
> all issues I was hitting are fixed by this merge request.

Thanks, that is great to know.

> I mean, at the rate Kent's tree is stabilizing right now I am actually
> considering moving some productive systems over there. But those will
> need to run distro kernels. So, please merge, I don't want to jump
> through the hoops to run OpenZFS ...

I did not agree to some of your behavior before, Kent. But actually at 
least from your description I had the feeling this pull request is about 
stabilizing BCacheFS in order to remove the experimental tag. The pull 
request looked quite reasonable to me.

And frankly I am using BCacheFS in production meanwhile, even with 
encryption: On a 4 TB XS-2000 external SSD and I am quite sure I am not 
willing to copy over all that data to a different filesystem again. And on 
a scratch filesystem on my laptop, but that one is easily replaceable.

Sure I can switch to a different kernel source tree, having compiled 
BCacheFS tools myself as well. And I am fine to do so.

But on the other hand, Linus, on a past rc1 pull request that does not 
only contain bug fixes, there is still the option to simply not pull it. 
After the discussion that has been had, even not pulling it without 
explaining it sounds absolutely fair enough to me. It is not that someone 
could force you to accept a pull request as far as I understand.

Well, maybe that is the strategy here: Just pull this at the last day of 
the 2-week window to make sure everything else after that can only contain 
bug fixes anymore. :)

So my two cents… I'd appreciate BCacheFS to stay in kernel. I bet the 
churn to remove it and later again reintroduce it would be actually more 
work than to simply ignore a pull request every now and then.

And I think I may not be the only BCacheFS user who prefers to use 
mainline kernels.

Maybe at one conference you could come together in a room and sort this 
all out face to face. But until then maybe the approach I outlined above 
can be an option?

Best,
-- 
Martin

Re: [GIT PULL] bcachefs changes for 6.17

[Peter Schneider]

Am 05.08.2025 um 23:19 schrieb Malte Schröder:

> So, no merge yet? That really is a bummer. I was really hoping to
> finally be able to run mainline Linux again on my boxes (yes, I
> converted all of them to bcachefs early this year), now that pretty much
> all issues I was hitting are fixed by this merge request.
> 
> I mean, at the rate Kent's tree is stabilizing right now I am actually
> considering moving some productive systems over there. But those will
> need to run distro kernels. So, please merge, I don't want to jump
> through the hoops to run OpenZFS ...


I'm just a user, but please allow me to chime in with my 2 cts:

Linux is much better and more useful to more users WITH bcachefs included than it would be 
without it. Throwing it out or even only freezing it would hurt Linux users, only to 
please Linus' ego for a short amount of time. I don't think that's a good trade-off, and 
that certainly (IMHO) would be a very bad decision. Also, it would be a big violation of 
the promise to not break userspace. How could you possibly break userspace more than by 
needlessly throwing out a much needed filesystem that is in active use?

Of course, Kent has, to some extent, not quite adhered to the letter of the process, but 
as I see it, he did so only to show responsibility towards his users, and this is a good 
thing. We should wish for all developers and maintainers to have this much sense of 
responsibility. We need people who care, and not just bureaucratically follow a strict 
process that in this case was not designed to handle the criticality of the situation for 
the affected users.

Linus, long time ago, in a Google talk about (then new) SCM tool git, you said that a 
distributed workflow is all about respecting other people's decisions, even if sometimes 
you don't fully agree with them. Kent's pull request in the last cycle which is the source 
of this quarrel is one you could and should, in hindsight, have respected as Kent's 
responsible decision!


So Linus, may I humbly ask you to please merge!


Beste Grüße,
Peter Schneider

-- 
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you.                    -- David McCullough Jr.

OpenPGP:  0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244
Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@googlemail.com
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@gmail.com

Re: [GIT PULL] bcachefs changes for 6.17

[Gerhard Wiesinger]

On 28.07.2025 17:14, Kent Overstreet wrote:
> Schedule notes for users:
>
> I've been digging through the bug tracker and polling users to see what
> bugs are still outstanding, and - it's not much.
>
> So, the experimental label is coming off in 6.18.
>
> As always, if you do hit a bug, please report it.
>
I can now confirm that bcachefs is getting stable and the test cases 
with intentionally data corruption (simulation of a real world case I 
had) gets bcachefs back to a consistent state (after 2 runs of: bcachefs 
fsck -f -y ${DEV}). That's a base requirement for a stable filesystem. 
Version of bcachefs-tools is git 
530e8ade4e6af7d152f4f79bf9f2b9dec6441f2b and kernel is 
6.16.0-200.fc42.x86_64.

See for details, I made data corruption even worser with running the 
destroy script 5x:

https://lore.kernel.org/linux-bcachefs/aa613c37-153c-43e4-b68e-9d50744be7de@wiesinger.com/

Great work Kent and the other contributors.

Unfortunately btrfs can't be repaired to a consistent state with the 
same testcase. I'd like to be that testcase fixed also for BTRFS as a 
stable filesystem (versions: 6.16.0-200.fc42.x86_64, btrfs-progs v6.15, 
-EXPERIMENTAL -INJECT -STATIC +LZO +ZSTD +UDEV +FSVERITY +ZONED 
CRYPTO=libgcrypt).

(I reported that already far in the past on the mailing list, see here: 
https://lore.kernel.org/linux-btrfs/63f8866f-ceda-4228-b595-e37b016e7b1f@wiesinger.com/).

Thnx.

Ciao,

Gerhard

Re: [GIT PULL] bcachefs changes for 6.17

[Martin Steigerwald]

Hi Gerhard, hi.

Gerhard Wiesinger - 10.08.25, 08:20:43 CEST:
> On 28.07.2025 17:14, Kent Overstreet wrote:
> > Schedule notes for users:
> > 
> > I've been digging through the bug tracker and polling users to see
> > what bugs are still outstanding, and - it's not much.
> > 
> > So, the experimental label is coming off in 6.18.
> > 
> > As always, if you do hit a bug, please report it.
> 
> I can now confirm that bcachefs is getting stable and the test cases
> with intentionally data corruption (simulation of a real world case I
> had) gets bcachefs back to a consistent state (after 2 runs of: bcachefs
> fsck -f -y ${DEV}). That's a base requirement for a stable filesystem.
> Version of bcachefs-tools is git
> 530e8ade4e6af7d152f4f79bf9f2b9dec6441f2b and kernel is
> 6.16.0-200.fc42.x86_64.
> 
> See for details, I made data corruption even worser with running the
> destroy script 5x:
> 
> https://lore.kernel.org/linux-bcachefs/aa613c37-153c-43e4-b68e-9d50744be
> 7de@wiesinger.com/
> 
> Great work Kent and the other contributors.
> 
> Unfortunately btrfs can't be repaired to a consistent state with the
> same testcase. I'd like to be that testcase fixed also for BTRFS as a
> stable filesystem (versions: 6.16.0-200.fc42.x86_64, btrfs-progs v6.15,
> -EXPERIMENTAL -INJECT -STATIC +LZO +ZSTD +UDEV +FSVERITY +ZONED
> CRYPTO=libgcrypt).
> 
> (I reported that already far in the past on the mailing list, see here:
> https://lore.kernel.org/linux-btrfs/63f8866f-ceda-4228-b595-e37b016e7b1f
> @wiesinger.com/).

Thanks for this great find and these test results.

On a technical perspective I still think the Linux kernel is a better 
kernel with BCacheFS included.

And write this without having had any issues – except for bad performance 
especially on hard disks, but partly also on flash – with BTRFS. And I use 
it on a couple laptops, some virtual machines and a lot of external disks. 
But not on a multi device setup. I had a BTRFS RAID 1 for a long time. 
This also has been stable since kernel 4.6 up to the time I still used it.

So I did not really have much of a need to fsck BTRFS.

Best,
-- 
Martin