Bcachefs to be removed from mainline Linux kernel

* [GIT PULL] bcachefs changes for 6.17 @ 2025-07-28 15:14 Kent Overstreet 2025-08-05 21:19 ` Malte Schröder 2025-08-10 6:20 ` Gerhard Wiesinger 0 siblings, 2 replies; 39+ messages in thread From: Kent Overstreet @ 2025-07-28 15:14 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-bcachefs, linux-fsdevel, linux-kernel 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(-) ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-07-28 15:14 [GIT PULL] bcachefs changes for 6.17 Kent Overstreet @ 2025-08-05 21:19 ` Malte Schröder 2025-08-05 22:41 ` Carl E. Thompson ` (2 more replies) 2025-08-10 6:20 ` Gerhard Wiesinger 1 sibling, 3 replies; 39+ messages in thread From: Malte Schröder @ 2025-08-05 21:19 UTC (permalink / raw) To: Kent Overstreet, Linus Torvalds Cc: linux-bcachefs, linux-fsdevel, linux-kernel 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(-) > ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-08-05 21:19 ` Malte Schröder @ 2025-08-05 22:41 ` Carl E. Thompson 2025-08-07 12:42 ` Aquinas Admin 2025-08-07 14:27 ` Martin Steigerwald 2025-08-07 17:29 ` Peter Schneider 2 siblings, 1 reply; 39+ messages in thread From: Carl E. Thompson @ 2025-08-05 22:41 UTC (permalink / raw) To: Malte Schröder, Kent Overstreet, Linus Torvalds Cc: linux-bcachefs, linux-fsdevel, linux-kernel 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 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(-) > > ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-08-05 22:41 ` Carl E. Thompson @ 2025-08-07 12:42 ` Aquinas Admin 2025-08-09 17:36 ` Kent Overstreet 2025-08-10 4:29 ` Gerhard Wiesinger 0 siblings, 2 replies; 39+ messages in thread From: Aquinas Admin @ 2025-08-07 12:42 UTC (permalink / raw) To: Malte Schröder, Kent Overstreet, Linus Torvalds, Carl E. Thompson Cc: linux-bcachefs, linux-fsdevel, linux-kernel 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 wrote: > > > > On 28.07.25 17:14, Kent Overstreet wrote: >> . ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-08-05 21:19 ` Malte Schröder 2025-08-05 22:41 ` Carl E. Thompson @ 2025-08-07 14:27 ` Martin Steigerwald 2025-08-07 17:29 ` Peter Schneider 2 siblings, 0 replies; 39+ messages in thread From: Martin Steigerwald @ 2025-08-07 14:27 UTC (permalink / raw) To: Kent Overstreet, Linus Torvalds, Malte Schröder Cc: linux-bcachefs, linux-fsdevel, linux-kernel 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 ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-08-05 21:19 ` Malte Schröder 2025-08-05 22:41 ` Carl E. Thompson 2025-08-07 14:27 ` Martin Steigerwald @ 2025-08-07 17:29 ` Peter Schneider 2 siblings, 0 replies; 39+ messages in thread From: Peter Schneider @ 2025-08-07 17:29 UTC (permalink / raw) To: Malte Schröder, Kent Overstreet, Linus Torvalds Cc: linux-bcachefs, linux-fsdevel, linux-kernel 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/[email protected] https://keys.mailvelope.com/pks/[email protected] ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-08-07 12:42 ` Aquinas Admin @ 2025-08-09 17:36 ` Kent Overstreet 2025-08-09 19:21 ` Josef Bacik ` (2 more replies) 2025-08-10 4:29 ` Gerhard Wiesinger 1 sibling, 3 replies; 39+ messages in thread From: Kent Overstreet @ 2025-08-09 17:36 UTC (permalink / raw) To: Aquinas Admin Cc: Malte Schröder, Linus Torvalds, Carl E. Thompson, linux-bcachefs, linux-fsdevel, linux-kernel 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 ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-08-09 17:36 ` Kent Overstreet @ 2025-08-09 19:21 ` Josef Bacik 2025-08-09 20:37 ` Kent Overstreet 2025-08-11 16:02 ` Aquinas Admin 2025-08-09 23:01 ` Matthew Wilcox 2025-08-11 9:51 ` Konstantin Shelekhin 2 siblings, 2 replies; 39+ messages in thread From: Josef Bacik @ 2025-08-09 19:21 UTC (permalink / raw) To: Kent Overstreet Cc: Aquinas Admin, Malte Schröder, Linus Torvalds, Carl E. Thompson, linux-bcachefs, linux-fsdevel, linux-kernel 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 ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-08-09 19:21 ` Josef Bacik @ 2025-08-09 20:37 ` Kent Overstreet 2025-08-09 21:34 ` Kent Overstreet 2025-08-10 2:24 ` Theodore Ts'o 2025-08-11 16:02 ` Aquinas Admin 1 sibling, 2 replies; 39+ messages in thread From: Kent Overstreet @ 2025-08-09 20:37 UTC (permalink / raw) To: Josef Bacik Cc: Aquinas Admin, Malte Schröder, Linus Torvalds, Carl E. Thompson, linux-bcachefs, linux-fsdevel, linux-kernel 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. ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-08-09 23:01 ` Matthew Wilcox @ 2025-08-09 23:13 ` Kent Overstreet 0 siblings, 0 replies; 39+ messages in thread From: Kent Overstreet @ 2025-08-09 23:13 UTC (permalink / raw) To: Matthew Wilcox Cc: Aquinas Admin, Malte Schröder, Linus Torvalds, Carl E. Thompson, linux-bcachefs, linux-fsdevel, linux-kernel 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] ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-08-09 20:37 ` Kent Overstreet 2025-08-09 21:34 ` Kent Overstreet @ 2025-08-10 2:24 ` Theodore Ts'o 2025-08-10 3:17 ` Kent Overstreet 2025-08-10 6:05 ` Carl E. Thompson 1 sibling, 2 replies; 39+ messages in thread From: Theodore Ts'o @ 2025-08-10 2:24 UTC (permalink / raw) To: Kent Overstreet Cc: Josef Bacik, Aquinas Admin, Malte Schröder, Linus Torvalds, Carl E. Thompson, linux-bcachefs, linux-fsdevel, linux-kernel 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 ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-08-10 2:24 ` Theodore Ts'o @ 2025-08-10 3:17 ` Kent Overstreet 2025-08-10 4:05 ` Sasha Levin 2025-08-10 8:02 ` Martin Steigerwald 2025-08-10 6:05 ` Carl E. Thompson 1 sibling, 2 replies; 39+ messages in thread From: Kent Overstreet @ 2025-08-10 3:17 UTC (permalink / raw) To: Theodore Ts'o Cc: Josef Bacik, Aquinas Admin, Malte Schröder, Linus Torvalds, Carl E. Thompson, linux-bcachefs, linux-fsdevel, linux-kernel 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. ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-08-10 3:17 ` Kent Overstreet @ 2025-08-10 4:05 ` Sasha Levin 2025-08-10 4:13 ` Kent Overstreet 2025-08-11 16:48 ` [GIT PULL] bcachefs changes for 6.17 Aquinas Admin 2025-08-10 8:02 ` Martin Steigerwald 1 sibling, 2 replies; 39+ messages in thread From: Sasha Levin @ 2025-08-10 4:05 UTC (permalink / raw) To: Kent Overstreet Cc: Theodore Ts'o, Josef Bacik, Aquinas Admin, Malte Schröder, Linus Torvalds, Carl E. Thompson, linux-bcachefs, linux-fsdevel, linux-kernel 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 ^ permalink raw reply [flat|nested] 39+ messages in thread * Re: [GIT PULL] bcachefs changes for 6.17 2025-08-10 4:05 ` Sasha Levin @ 2025-08-10 4:13 ` Kent Overstreet 2025-08-10 4:26 ` Gerald B. Cox 2025-08-11 16:48 ` [GIT PULL] bcachefs changes for 6.17 Aquinas Admin 1 sibling, 1 reply; 39+ messages in thread From: Kent Overstreet @ 2025-08-10 4:13 UTC (permalink / raw) To: Sasha Levin Cc: Theodore Ts'o, Josef Bacik, Aquinas Admin, Malte Schröder, Linus Torvalds, Carl E. Thompson, linux-bcachefs, linux-fsdevel, linux-kernel 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 wonderfu