* [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
* 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
* 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
... continue reading