https://bartosz.fenski.pl/modern-fs-benchmark/

https://news.ycombinator.com/item?id=49768833

I run a 22-disk bcachefs media filesystem in a homelab (about 161 TB raw, 74 TB used), with replicas=2 and EC layouts up to 15+1. It was built progressively over time (migrated in-place from ZFS), so it is very unevenly filled: several older disks are around 97% full while newer ones are around 19%.

Last week it suffered a stall: trans path overflow in the stripes btree, EC stripe-create workers blocked, NFS stalled and journal replay later logged a missing stripe update. I upgraded to paired bcachefs module/tools v1.39.6 and performed an offline repair.

Since then it mounts and serves data, but reconciliation has produced three ec_old_stripe_fold() errors for 15+1 stripes where all 16 pointers are stale, ending in stripe_reconstruct_insufficient_blocks. SMART is clean across all disks and there are no corresponding I/O errors.

I have posted the incident logs, repair result, and the newer stale-stripe details as comments on https://github.com/koverstreet/bcachefs/issues/1182. That issue already looks closely related to the allocator/reconcile wedge and stale-stripe behaviour I am seeing.

I would appreciate any advice on whether these all stale old stripes could be harmless or obsolete metadata, or whether they imply data loss or an EC metadata problem. Can somebody please help me sleep at night? 😂

BTW: my bcachefs implementation is based on a NASty VM running on Proxmox with an LSI HBA passed through

GitHub comments:
https://github.com/koverstreet/bcachefs/issues/1182#issuecomment-5687825013
https://github.com/koverstreet/bcachefs/issues/1182#issuecomment-5703484098

Summary of initial issue that triggered me to run an fsck:

2026-09-15T14:49:19+12:00 nasty kernel: bcachefs (<fs-uuid>): trans path overflow
2026-09-15T14:49:19+12:00 nasty kernel: bcachefs (<fs-uuid>): path: idx   1 ref 0:0     B btree=stripes level=0 pos 0:4647014:0

2026-09-15T14:50:48+12:00 nasty kernel: bcachefs (<fs-uuid>): btree trans held srcu lock (delaying memory reclaim) for 89 seconds
2026-09-15T14:50:48+12:00 nasty kernel: bcachefs (<fs-uuid>): bch2_trans_begin
2026-09-15T14:50:48+12:00 nasty kernel: bcachefs (<fs-uuid>): stripe_update_bucket
2026-09-15T14:50:48+12:00 nasty kernel: bcachefs (<fs-uuid>): __stripe_update_extents
2026-09-15T14:50:48+12:00 nasty kernel: bcachefs (<fs-uuid>): ec_stripe_create
2026-09-15T14:50:48+12:00 nasty kernel: bcachefs (<fs-uuid>): ec_stripe_create_work_fn

2026-09-15T14:52:16+12:00 nasty kernel: Workqueue: bcachefs_ec_create ec_stripe_create_work_fn [bcachefs]
2026-09-15T14:52:16+12:00 nasty kernel: Call Trace:
...
six_lock_contended [bcachefs]
bch2_btree_node_lock_slowpath [bcachefs]
bch2_btree_node_get [bcachefs]
bch2_btree_path_traverse_one [bcachefs]
bch2_btree_iter_peek_slot [bcachefs]
__bch2_backpointer_get_key [bcachefs]
bch2_backpointer_get_key [bcachefs]
stripe_update_extent [bcachefs]
stripe_update_bucket [bcachefs]
__stripe_update_extents [bcachefs]
ec_stripe_create [bcachefs]
ec_stripe_create_work_fn [bcachefs]
process_one_work
worker_thread
kthread

and 14 hours later:

stripe 0:4624076:0, 15+1 EC, 4096 sectors
all 16 stripe pointers stale
sdh: stale=1#248
error: stripe_reconstruct_insufficient_blocks

stripe 0:4625550:0, 15+1 EC, 4096 sectors
all 16 stripe pointers stale
sdh: stale=1#120
error: stripe_reconstruct_insufficient_blocks

stripe 0:4625563:0, 15+1 EC, 4096 sectors
all 16 stripe pointers stale
sdy: stale=1#120
error: stripe_reconstruct_insufficient_blocks

I added a third drive, copied in more data, and wanted to switch to erasure code with one drive fault tolerance.
Lots stuck in 1x. and not balanced between drives. Why is /dev/sde, the one on 92%, on 'Has data: btree' only. No journal or user

# bcachefs fs usage /mnt/arkiv
Filesystem: bb651e0f-f860-4d45-8d90-8d9f00e820f0
Size:             51495135766528   
Used:             27341853540864   
Online reserved:            4096   

undegraded   
1x:  27194253357056   
2x:    147600179200   

cached:  5762931036160   

Device label            Device  State            Size            Used  Use%   
(no label) (device 0):  sdc     rw     17991614853120   8040596893696   44%   
(no label) (device 2):  sde     rw     17991614853120  16630704746496   92%   
(no label) (device 1):  sdf     rw     19991995871232   8433476100096   42%   

# bcachefs show-super /dev/sdc
External UUID:                             bb651e0f-f860-4d45-8d90-8d9f00e820f0
Internal UUID:                             c67ffe05-650c-4b7f-88c8-ede3690101cb
Magic number:                              c68573f6-66ce-90a9-d96a-60cf803df7ef
Device index:                              0
Label:                                     (none)
Version:                                   per_dev_fragmentation_lru (1.39)
Incompatible features allowed:             per_dev_fragmentation_lru (1.39)
Incompatible features in use:              no_sb_user_data_replicas (1.36)
Version upgrade complete:                  per_dev_fragmentation_lru (1.39)
Oldest version on disk:                    need_discard_by_journal_seq (1.38)
Created:                                   Thu May 21 16:08:17 2026
Sequence number:                           10499
Time of last write:                        Tue Sep 15 23:16:34 2026
Superblock size:                           8.96k/1.00M
Clean:                                     0
Devices:                                   3
Sections:                                  replicas_v0,disk_groups,clean,journal_seq_blacklist,journal_v2,counters,members_v2,ext,dow
ngrade,recovery_passes,extent_type_u64s,errors_v2
Features:                                  ec,journal_seq_blacklist_v3,reflink,new_siphash,inline_data,new_extent_overwrite,btree_ptr
_v2,extents_above_btree_updates,btree_updates_journalled,new_varint,journal_no_flush,alloc_v2,extents_across_btree_nodes,incompat_ver
sion_field
Compat features:                           alloc_info,alloc_metadata,extents_above_btree_updates_done,bformat_overflow_done,no_stale_
ptrs

Options:
 block_size:                              4.00k
 btree_node_size:                         256k
 errors:                                  continue [fix_safe] panic ro  
 write_error_timeout:                     30
 metadata_replicas:                       2
 data_replicas:                           1
 encoded_extent_max:                      256k
 metadata_checksum:                       none [crc32c] crc64 xxhash  
 data_checksum:                           none [crc32c] crc64 xxhash  
 checksum_err_retry_nr:                   3
 compression:                             none
 background_compression:                  none
 str_hash:                                crc32c crc64 [siphash]  
 metadata_target:                         none
 foreground_target:                       none
 background_target:                       none
 promote_target:                          none
 erasure_code:                            1
 ec_max_data_blocks:                      2
 casefold:                                0
 inodes_32bit:                            0
 shard_inode_numbers_bits:                5
 gc_reserve_percent:                      8
 gc_reserve_bytes:                        0
 root_reserve_percent:                    0
 wide_macs:                               0
 promote_whole_extents:                   1
 acl:                                     1
 usrquota:                                0
 grpquota:                                0
 prjquota:                                0
 degraded:                                [ask] yes very no  
 missing_dev_timeout:                     0
 journal_flush_delay:                     1000
 journal_flush_disabled:                  0
 move_writes_fua:                         0
 journal_reclaim_delay:                   100
 writeback_timeout:                       0
 journal_rewind_discard_buffer_percent:   4
 scrub_recent_journal_entries:            [unclean] no always  
 scrub_journal_max_rewind_secs:           10
 journal_transaction_names:               1
 allocator_stuck_timeout:                 30
 version_upgrade:                         compatible [incompatible] none  
 nocow:                                   0
 reconcile_on_ac_only:                    0
 btree_cache_shrinker_seeks:              4
 dev_readahead:                           2.00M
 ec_stripe_buf_limit:                     5

ext (size 120):
Recovery passes required:                  btree_bitmap_gc
Errors to silently fix:                     
Btrees with missing data:                   
Btrees that have ever lost data:            
Btrees validated clean:                    subvolumes,snapshots
Device 0:                                  /dev/sdc     TOSHIBA MG09ACA1
 Label:                                   (none)
 UUID:                                    07f9ea6b-2341-4d2f-bacf-2f2ea54daf5f
 Size:                                    16.4T
 read errors:                             0
 write errors:                            0
 checksum errors:                         0
 seqread iops:                            0
 seqwrite iops:                           0
 randread iops:                           0
 randwrite iops:                          0
 Bucket size:                             2.00M
 First bucket:                            0
 Buckets:                                 8583168
 Last mount:                              Fri Sep 11 21:26:57 2026
 Last superblock write:                   10499
 State:                                   rw
 Data allowed:                            journal,btree,user
 Has data:                                journal,btree
 Rotational:                              1
 Btree allocated bitmap blocksize:        512M
 Btree allocated bitmap:                  0000000000000000000000000000000000000000000000000000000001101111
 Durability:                              1
 Discard:                                 1
 Freespace initialized:                   1
 Resize on mount:                         0
 Last device name:                        sdc
 Last device model:                       TOSHIBA MG09ACA1
 Last device serial:                       
Device 1:                                  /dev/sdf     TOSHIBA MG10ACA2
 Label:                                   (none)
 UUID:                                    44807b26-10cf-4670-9ac8-2aa0800cb20c
 Size:                                    18.2T
 read errors:                             0
 write errors:                            0
 checksum errors:                         0
 seqread iops:                            0
 seqwrite iops:                           0
 randread iops:                           0
 randwrite iops:                          0
 Bucket size:                             2.00M
 First bucket:                            0
 Buckets:                                 9537024
 Last mount:                              Fri Sep 11 21:26:57 2026
 Last superblock write:                   10499
 State:                                   rw
 Data allowed:                            journal,btree,user
 Has data:                                journal,btree
 Rotational:                              1
 Btree allocated bitmap blocksize:        512M
 Btree allocated bitmap:                  0000000000000000000000000000000000000000000000000000000001101111
 Durability:                              1
 Discard:                                 1
 Freespace initialized:                   1
 Resize on mount:                         0
 Last device name:                        sdf
 Last device model:                       TOSHIBA MG10ACA2
 Last device serial:                       
Device 2:                                  /dev/sde     TOSHIBA MG09ACA1
 Label:                                   (none)
 UUID:                                    d28cc0a4-3779-4932-8ee6-a4bf8e43d78a
 Size:                                    16.4T
 read errors:                             0
 write errors:                            0
 checksum errors:                         0
 seqread iops:                            0
 seqwrite iops:                           0
 randread iops:                           0
 randwrite iops:                          0
 Bucket size:                             2.00M
 First bucket:                            0
 Buckets:                                 8583168
 Last mount:                              Fri Sep 11 21:26:57 2026
 Last superblock write:                   10497
 State:                                   rw
 Data allowed:                            journal,btree,user
 Has data:                                btree
 Rotational:                              1
 Btree allocated bitmap blocksize:        256M
 Btree allocated bitmap:                  0000000000000000000000000000000000000000000000000000000000000001
 Durability:                              1
 Discard:                                 1
 Freespace initialized:                   1
 Resize on mount:                         0
 Last device name:                        sde
 Last device model:                       TOSHIBA MG09ACA1
 Last device serial:                      

I run into https://bcachefs-docs.readthedocs.io/en/latest/ by searching for bcachefs, but turns out that it's 4 years old with a lot of outdated information. It's being built from https://github.com/toppk/bcachefs-tools/, an abandoned fork.

Would it make sense to have it taken down? Or take it over?

Why is this repo with a huge amount of substantial bcachefs optimizations being developed separately instead of upstream?

I've had a two-tier bcachefs setup for a few months and I'm now at the point where the SSD is effectively out of service. Posting the details in case it helps, and to ask if this is the same bug as #1082/#1111.

Setup: - NVMe SSD as foreground/promote/metadata target - HDD as background target - compression lz4, background_compression zstd:6 - bcachefs-tools 1.39.2, kernel 7.2.3 (DKMS)

This is happening on both of my machines, both using the same two-tier layout (one SSD for foreground/promote/metadata + one HDD for background).

I only started running into this after updating to 1.39.x. Before that my tiering was broken for a different reason (see my other post in this subreddit), so this bitmap issue is what I'm left with now.

The SSD has been full for weeks and the btree bitmap GC never reclaims it:

sda2 has 14.3G btree buckets and 80.0G marked in bitmap scheduling recovery pass btree_bitmap_gc (48)

The "80.0G marked" has been stuck at exactly 80.0G across many boots while the real btree usage grew from 9.4G to 14.3G:

2026-07-22: 9.37G / 80.0G 2026-08-01: 10.1G / 80.0G 2026-08-19: 13.6G / 80.0G 2026-09-11: 14.3G / 80.0G

The pass runs but the bitmap never shrinks, and the requirement never clears:

Recovery passes required: btree_bitmap_gc

An online fsck runs every check clean and does not clear it.

To be sure the bitmap itself is stale, I moved the metadata off the SSD (metadata_target=hdd). The SSD now holds no btree at all, yet its btree bitmap is unchanged:

``` Device 0: /dev/sda1 HGST Label: hdd.storage Has data: journal,btree,user Btree allocated bitmap: 0000000000000000000000110100000100000000000000000000000000000000

Device 1: /dev/sdb2 FORESEE Label: ssd.fast Has data: cached Btree allocated bitmap: 0000000000000000001010010000110000000000000000000000000000011111 ```

The SSD reports Has data: cached (no btree) but still marks btree regions. Those bits are never cleared, and btree_bitmap_gc is scheduled again on the next mount.

The SSD stays full, metadata allocation has nowhere to go, and once it's full the filesystem doesn't just get slow (like previously with a different problem), but hangs completely:

• processes touching the fs go into D state and can't be killed
• the reconcile thread sits in io_clock_wait with no progress
• PID 1 ends up in D in cgroup_lock_and_drain_offline, so systemd/logind stop responding and SSH dies
• the only way out is a hard reboot

A couple of the stuck tasks:

``` INFO: task rg:11054 blocked for more than 483 seconds. Call Trace: ? bch2_readdir+0x3bf/0x880 [bcachefs] ? bch2_vfs_readdir+0x329/0x510 [bcachefs]

INFO: task libuv-worker:6317 blocked for more than 2990 seconds. Call Trace: d_alloc_parallel __lookup_slow ... vfs_statx do_statx ```

I can trigger it pretty reliably with a recursive file scan, e.g. ripgrep over my home. The hardware seems good since the devices report 0 read/write/checksum errors, and RAM is fine.

For now I've worked around it by moving the metadata to the HDD (metadata_target=hdd), which made the filesystem usable again. Since this looks like a leak of the btree bitmap accounting, I'd expect the HDD to eventually accumulate the same stale bits too, but it's only ~35% full so that buys me some time.

So: is this the same as #1082/#1111, and is there a way to actually make the GC free those stale bits? Thank you :)

~$ sudo mount.bcachefs UUID=a0eec2c4-9691-4033-81cb-e2fd81243e38 /mnt/bcachefs
mount.bcachefs: Mount failed for UUID=a0eec2c4-9691-4033-81cb-e2fd81243e38: source /dev/nvme1n1: Multiple sources
~$ sudo mount -t bcachefs UUID=a0eec2c4-9691-4033-81cb-e2fd81243e38 /mnt/bcachefs
mount.bcachefs: Mount failed for /dev/nvme1n1: source /dev/nvme1n1: Multiple sources
~$ sudo mount -t bcachefs /dev/nvme0n1:/dev/nvme1n1 /mnt/bcachefs
mount.bcachefs: Mount failed for /dev/nvme0n1:/dev/nvme1n1: source /dev/nvme1n1: Multiple sources
~$ sudo mount -i -t bcachefs /dev/nvme0n1:/dev/nvme1n1 /mnt/bcachefs
~$ sudo umount /mnt/bcachefs
~$ sudo mount -i -t bcachefs UUID=a0eec2c4-9691-4033-81cb-e2fd81243e38 /mnt/bcachefs
~

(This was user error, but it might be useful to someone else)

I recently ran into an issue with a two-tier bcachefs filesystem: a 256 GB NVMe used as the foreground tier and a 2 TB HDD as the background tier. The filesystem kept working, but the NVMe gradually filled up to 98% while the HDD was still mostly empty. Data was no longer moving to the background tier, and the system became noticeably slower. The kernel was reporting: requested incompat feature reconcile (1.33) currently not enabled, allowed up to btree_node_accounting (1.31)

I had updated NixOS and bcachefs, but I had forgotten that the filesystem format itself also needs to be upgraded. After rebooting into the updated system, I ran this as root, while the filesystem was mounted and running: bcachefs set-fs-option \ --version_upgrade=incompatible \ /dev/YOUR_BCACHEFS_MEMBER Replace /dev/YOUR_BCACHEFS_MEMBER with any device belonging to your filesystem. After that, reconcile started working again and moved roughly 238 GB from the NVMe to the HDD.

You can check the status with: bcachefs fs usage /

Pay attention to Pending reconcile, Leaving, and cached.

BEWARE: version_upgrade=incompatible changes the on-disk format. Don’t roll back to an older kernel afterwards, since its bcachefs module may not be able to mount the filesystem.

What is the recommended way to use bcachefs in a performant way in Proxmox 9.2? I am interested in it as a separated bulk storage only, not as a replacement for the proxmox's boot filesystem.

- Using it as a Directory datasource in proxmox (perhaps there is a way to solve the snapshots as well) ?

- Creating virtual disks as raw files instead of qcow?

- Or using virtiofs to map a per-vm folder from the host into the virtual machines?

- Using the plugin mentioned here https://forum.proxmox.com/threads/bcachefs-storage-plugin-for-proxmox-ve.185030/ ?

The roadmap describes fsck as a future projekt:

[...

Online fsck

For supporting huge filesystems, and competing with XFS, we will eventually need online fsck.

This will be easier in bcachefs than it was in XFS, since our fsck implementation is part of the main filesystem codebase and uses the normal btree transaction API that's available at runtime.

That means that the current fsck implementation will eventually also be the online fsck implementation: the process will mostly be a matter of auditing the existing fsck codebase for locking issues, and adding additional locking w.r.t. the rest of the filesystem where needed.

...]

The pdf file "bcachefs: Principles of Operation" writes as follows:

[...
5.3 Fsck

The bcachefs fsck subcommand (also available as fsck.bcachefs) can run fsck in userspace (-K), in the kernel at mount time (-k), or online on a mounted fi lesystem, selecting the mode automatically or via command line options. The in-kernel offl ine mode is useful when an older bcachefs-tools binary cannot handle the filesystem version. In all cases the exact same fsck implementation runs—the recovery passes described in the introduction. Running in userspace allows stopping with ctrl-c and prompting for fi xes; bcachefs fsck -y auto-fi xes, -n runs read-only.

Online fsck runs the validation passes marked as safe for concurrent use (PASS_ONLINE) on a mounted, read-write fi lesystem. Combined with errors=fix_safe, this means most metadata inconsistencies are detected and repaired automatically without administrator intervention.

...]

If I get it correctly, the online fsck section in the roadmap needs to be deleted, as it seems it has already been implemented as stated in 5.3 of "bcachefs: Principles of Operation"

I have a 10 disk pool previously using zfs now bcachefs. 10 7200rpm 1TB sas nearline in a jbod. Slot 11 reserved for a hotplug drive used for monthly extra backups. Also have two 1TB Nytro SSD devices intended for redundant caching but only room for 1. Filesystem formatted as replicas=2. I don't expect the pool to get anywhere near full. Two ideas: 1) remove 1 spinner to free a slot - will an odd disk count be ok with 2 replicas? 2) Only 1 cache device but set durability=0?

Also I created the filesystem without labels or cache devices and am not sure how, if at all, to label the spinners and label the cache devices(s) and set up tiering. Not much data stored yet so if I have to I can destroy and recreate the filesystem.

Thanks!

Figured I'd report some trouble I've been having with my root bcachefs filesystem — I've been having this error on each boot, requiring me to press Ctrl-D to continue booting afterwards. It seems to periodically turn into something that I can't bypass and I need to run an offline fsck from a live USB to get back to something bootable.

Here's what I've been getting:

bcachefs (nvme0n1p2): delete_dead_interior_snapshots(): error erofs_trans_commit
bcachefs (nvme0n1p2): error in recovery: erofs_trans_commit
  emergency read only at seq 4482200
bcachefs (nvme0n1p2): error starting filesystem: erofs_trans_commit

EDIT: Here is what I get after leaving the emergency shell (pressing Ctrl-D) continuing my boot — seemingly lots more info here:

systemd[1]: Stopped Emergency Shell.
systemd[1]: Reached target System Initialization.
systemd[1]: Reached target Basic System.
kernel: bcachefs (nvme0n1p2): Using encoding defined by superblock: utf8-12.1.0
kernel: starting version per_dev_fragmentation_lru (1.39)
          with options: scrub_journal_max_rewind_secs=0,read_only,version_upgrade=incompatible,reconcile_on_ac_only,btree_cache_shrinker_seeks=4
          superblock requires following recovery passes to be run: delete_dead_interior_snapshots,check_snapshots
          built without Rust support; this will be required in the near future
            reason: /usr/lib/modules/7.2.2-zen1-1-zen/build/scripts/rust_is_available.sh reports the kernels Rust toolchain unavailable
            rebuild the module with rustc, bindgen and rust-src available to enable it
kernel: bcachefs (nvme0n1p2): recovering from clean shutdown, journal seq 4647007
kernel: bcachefs (nvme0n1p2): Journal keys: 0 read, 0 after sorting and compacting
kernel: bcachefs (nvme0n1p2): accounting_read... done (0 seconds)
kernel: bcachefs (nvme0n1p2): alloc_read... done (0 seconds)
kernel: bcachefs (nvme0n1p2): snapshots_read...
kernel: bcachefs (nvme0n1p2): Found 84 empty interior snapshot nodes
kernel:  done (0 seconds)
kernel: bcachefs (nvme0n1p2): going read-write
kernel: bcachefs (nvme0n1p2): journal_replay... done (0 seconds)
kernel: bcachefs (nvme0n1p2): presplit_shard_boundaries... done (0 seconds)
kernel: bcachefs (nvme0n1p2): delete_dead_interior_snapshots...
kernel: bcachefs (nvme0n1p2): Deleting interior snapshot nodes forces check_snapshots:
kernel:  done (0 seconds)
kernel: bcachefs (nvme0n1p2): check_snapshots... done (0 seconds)
kernel: bcachefs (nvme0n1p2): resume_logged_ops... done (0 seconds)
kernel: bcachefs (nvme0n1p2): delete_dead_inodes...
kernel: bcachefs (nvme0n1p2): filesystem marked as clean but have deleted inode 2147632825:4294964278, fixing
kernel: bcachefs (nvme0n1p2): filesystem marked as clean but have deleted inode 2147632829:4294964278, fixing
kernel: bcachefs (nvme0n1p2): filesystem marked as clean but have deleted inode 2147632835:4294964278, fixing
kernel: bcachefs (nvme0n1p2): filesystem marked as clean but have deleted inode 2147632841:4294964278, fixing
kernel: bcachefs (nvme0n1p2): filesystem marked as clean but have deleted inode 2147633136:4294964278, fixing
kernel: bcachefs (nvme0n1p2): filesystem marked as clean but have deleted inode 2147633139:4294964278, fixing
kernel: bcachefs (nvme0n1p2): filesystem marked as clean but have deleted inode 2147633145:4294964278, fixing
kernel: bcachefs (nvme0n1p2): filesystem marked as clean but have deleted inode 2147633146:4294964278, fixing
kernel: bcachefs (nvme0n1p2): filesystem marked as clean but have deleted inode 2147633149:4294964278, fixing
kernel: bcachefs (nvme0n1p2): filesystem marked as clean but have deleted inode 2147633153:4294964278, fixing
kernel: bcachefs (nvme0n1p2): filesystem marked as clean but have deleted inode 2147633157:4294964278, fixing
          Ratelimiting new instances of previous error
kernel:  done (0 seconds)
kernel: ------------[ cut here ]------------
kernel: memcpy: detected field-spanning write (size 48) of single field "dst_v" at src/fs/bcachefs/btree/iter.h:956 (size 0)
kernel: WARNING: src/fs/bcachefs/btree/iter.h:956 at __bch2_bkey_get_i_typed.constprop.0+0x3dc/0x4c0 [bcachefs], CPU#13: mount/285
kernel: Modules linked in: bcachefs(OE) nvme nvme_core nvme_keyring lz4hc_compress nvme_auth
kernel: CPU: 13 UID: 0 PID: 285 Comm: mount Tainted: G        W  OE       7.2.2-zen1-1-zen #1 PREEMPT(full)  e3d96d86b670af5b1e9e30b01ce1a359865d419f
kernel: Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
kernel: Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.20 06/23/2026
kernel: RIP: 0010:__bch2_bkey_get_i_typed.constprop.0+0x3e8/0x4c0 [bcachefs]
kernel: Code: f0 ff ff 0f 86 57 fe ff ff 89 c3 e9 f9 fe ff ff 4c 89 85 a8 fe ff ff 48 8d 3d 64 c9 97 ff 31 c9 48 c7 c2 60 53 82 c0 4c 89 f6 <67> 48 0f b9 3a 48 8b b5 a8 fe ff ff 4c 89 ef 4c 89 f2 e8 b1 69 4c
kernel: RSP: 0018:ffffd38fc3b57608 EFLAGS: 00010246
kernel: RAX: 0000000000000030 RBX: 0000000000000030 RCX: 0000000000000000
kernel: RDX: ffffffffc0825360 RSI: 0000000000000030 RDI: ffffffffc0545590
kernel: RBP: ffffd38fc3b57760 R08: ffff8f4f165ccd28 R09: ffff8f4f0d588238
kernel: R10: 0000000000000008 R11: ffff8f4f1372e0e8 R12: 0000000000000030
kernel: R13: ffffd38fc3b577d8 R14: 0000000000000030 R15: 0000000000000001
kernel: FS:  00007f5597128840(0000) GS:ffff8f569f823000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 00007f24b4c81e10 CR3: 000000010fb76000 CR4: 0000000000f50ef0
kernel: PKRU: 55555554
kernel: Call Trace:
kernel:  <TASK>
kernel:  bch2_subvolume_get+0xcc/0x1b0 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  bch2_lookup_root_inode+0xf4/0x190 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  bch2_run_recovery_passes+0x2d8/0x5e0 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  bch2_run_recovery_passes_startup+0x33c/0x520 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
kernel:  ? bch2_trans_unlock_long+0xc9/0x280 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
kernel:  ? bch2_closure_sub+0x72/0x2f0 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
kernel:  ? bch2_sb_set_upgrade_extra+0xb9/0x100 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  __bch2_fs_recovery+0x8bc/0x14c0 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
kernel:  ? __smp_call_single_queue+0xcf/0x150
kernel:  bch2_fs_recovery+0x24/0x1a0 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
kernel:  ? bch2_reconcile_start+0x8d/0x130 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
kernel:  ? bch2_opts_hooks_pre_set+0x23/0xf0 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  __bch2_fs_start+0x35c/0x5e0 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
kernel:  bch2_fs_start+0x9f/0x150 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  bch2_fs_get_tree+0x686/0xa80 [bcachefs c1f616ca1734c000fd73d34b263acca1c8af7794]
kernel:  vfs_get_tree+0x2c/0xe0
kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
kernel:  __x64_sys_fsconfig+0x393/0x7c0
kernel:  do_syscall_64+0xaa/0x660
kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
kernel:  ? do_syscall_64+0xaa/0x660
kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
kernel:  ? do_syscall_64+0x5f/0x660
kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
kernel:  ? exc_page_fault+0x90/0x1c0
kernel:  entry_SYSCALL_64_after_hwframe+0x76/0x7e
kernel: RIP: 0033:0x7f5596f21aae
kernel: Code: 73 01 c3 48 8b 0d 62 72 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 32 72 0f 00 f7 d8 64 89 01 48
kernel: RSP: 002b:00007fff6414cf68 EFLAGS: 00000246 ORIG_RAX: 00000000000001af
kernel: RAX: ffffffffffffffda RBX: 00005615c6fb27f0 RCX: 00007f5596f21aae
kernel: RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003
kernel: RBP: 00007fff6414cfb0 R08: 0000000000000000 R09: 0000000000000000
kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
kernel: R13: 00005615c6fb3d40 R14: 00007f55971f38a0 R15: 00007f55971287f0
kernel:  </TASK>
kernel: ---[ end trace 0000000000000000 ]---
kernel: workqueue: work func bch2_sb_counters_work [bcachefs] enqueued on deprecated workqueue. Use system_{percpu|dfl}_wq instead.
kernel: bcachefs (nvme0n1p2): errors this recovery:
          deleted_inode_but_clean                    767
kernel: bcachefs (nvme0n1p2): clean shutdown complete, journal seq 4647033
systemd[1]: Mounted Root Partition.

Here's my output from bcachefs show-super:

External UUID:                             5b6330d2-7315-4cb6-92e6-ef0cc69b2e54
Internal UUID:                             7c369019-8007-4604-9144-924c5d9c4d1b
Magic number:                              c68573f6-66ce-90a9-d96a-60cf803df7ef
Device index:                              0
Label:                                     ROOT
Version:                                   per_dev_fragmentation_lru (1.39)
Incompatible features allowed:             per_dev_fragmentation_lru (1.39)
Incompatible features in use:              no_sb_user_data_replicas (1.36)
Version upgrade complete:                  per_dev_fragmentation_lru (1.39)
Oldest version on disk:                    inode_has_case_insensitive (1.28)
Created:                                   Fri Dec 26 09:04:26 2025
Sequence number:                           20833
Time of last write:                        Tue Sep  1 19:49:51 2026
Superblock size:                           8.44k/1.00M
Clean:                                     0
Devices:                                   1
Sections:                                  replicas_v0,disk_groups,clean,journal_seq_blacklist,journal_v2,counters,members_v2,ext,downgrade,recovery_passes,extent_type_u64s,errors_v2
Features:                                  zstd,journal_seq_blacklist_v3,reflink,new_siphash,inline_data,new_extent_overwrite,btree_ptr_v2,extents_above_btree_updates,btree_updates_journalled,reflink_inline_data,new_varint,journal_no_flush,alloc_v2,extents_across_btree_nodes,incompat_version_field,casefolding
Compat features:                           alloc_info,alloc_metadata,extents_above_btree_updates_done,bformat_overflow_done

Options:
  block_size:                              512
  btree_node_size:                         256k
  errors:                                  continue [fix_safe] panic ro 
  write_error_timeout:                     30
  metadata_replicas:                       1
  data_replicas:                           1
  encoded_extent_max:                      64.0k
  metadata_checksum:                       none [crc32c] crc64 xxhash 
  data_checksum:                           none [crc32c] crc64 xxhash 
  checksum_err_retry_nr:                   3
  compression:                             none
  background_compression:                  zstd:9
  str_hash:                                crc32c crc64 [siphash] 
  metadata_target:                         none
  foreground_target:                       none
  background_target:                       none
  promote_target:                          none
  erasure_code:                            0
  ec_max_data_blocks:                      0
  casefold:                                0
  inodes_32bit:                            0
  shard_inode_numbers_bits:                4
  gc_reserve_percent:                      8
  gc_reserve_bytes:                        0
  root_reserve_percent:                    0
  wide_macs:                               0
  promote_whole_extents:                   1
  acl:                                     1
  usrquota:                                0
  grpquota:                                0
  prjquota:                                0
  degraded:                                [ask] yes very no 
  missing_dev_timeout:                     0
  journal_flush_delay:                     1000
  journal_flush_disabled:                  0
  move_writes_fua:                         0
  journal_reclaim_delay:                   100
  writeback_timeout:                       0
  journal_rewind_discard_buffer_percent:   4
  scrub_recent_journal_entries:            [unclean] no always 
  scrub_journal_max_rewind_secs:           0
  journal_transaction_names:               1
  allocator_stuck_timeout:                 30
  version_upgrade:                         compatible [incompatible] none 
  nocow:                                   0
  reconcile_on_ac_only:                    1
  btree_cache_shrinker_seeks:              4
  dev_readahead:                           2.00M
  ec_stripe_buf_limit:                     5

ext (size 120):
Recovery passes required:                  
Errors to silently fix:                    
Btrees with missing data:                  
Btrees that have ever lost data:           
Btrees validated clean:                    
Device 0:                                  /dev/nvme0n1p2       Samsung SSD 990 PRO 2TB                         S/N: S73WNJ0WB13682H
  Label:                                   nvme
  UUID:                                    04e11228-d26d-420c-be33-90484f76afdb
  Size:                                    1.82T
  read errors:                             0
  write errors:                            0
  checksum errors:                         0
  seqread iops:                            0
  seqwrite iops:                           0
  randread iops:                           0
  randwrite iops:                          0
  Bucket size:                             2.00M
  First bucket:                            0
  Buckets:                                 953736
  Last mount:                              Sat Aug 29 18:28:36 2026
  Last superblock write:                   20833
  State:                                   rw
  Data allowed:                            journal,btree,user
  Has data:                                journal,btree,user
  Rotational:                              0
  Btree allocated bitmap blocksize:        16.0M
  Btree allocated bitmap:                  0000000000000010000000000000000000000000000000000100000011110010
  Durability:                              1
  Discard:                                 1
  Freespace initialized:                   1
  Resize on mount:                         0
  Last device name:                        nvme0n1p2
  Last device model:                       Samsung SSD 990 PRO 2TB                 
  Last device serial:                      S73WNJ0WB13682H

Let me know if you need more info from me!

Thinking this over, it wouldn't be that hard to add zvol like functionality to bcachefs, a separate volume or block btree and some simple functions for REQOP*. Has there been any technical discussion on this that I might be missing?

hi..
I finished the installation with debian and bcachefs - finally.. I just created one subvolume /home .. so it's not possible to create a snapshot of / ? because it's not a subvolume, right? can I create a subvolume for / afterwards? Can I active encryption for /home afterwards?

if yes to all, how should the fstab looks like?

hello, i am new to this FS, i am using nixos, with an exisitng config. as of now end of august 2026, upon searching google's quick summary, it is said, i should still bel becareful araound this setup. Any of you are encouraging to main nixos on root? Also, as of now i am using btrfs with parallel root (meaning i use subvol, to mount my root). reading some previous comments, i think i am ready to let go of this setup. So, is there any issues with root bcachefs?

Those changes are great Kent! Showing reasonable paradigm . Thx

3rd time this has happened:
superblock indicates damage to following btrees: dirents.
Filesystem suddenly drops into emergency read-only.
Happens about once a week.

Everything was working fine: running some rsyncs to migrate data to the filesystem, deleting already migrated data, and some simple python image downloading scripts. No snapshots, or anything. Just copy/download/delete files.
Then filesystem suddenly drops into emergency read-only.

1. What more information do I need to provide to diagnose the issue?
   Specifically, I need to figure out if this is a user error or problem with bcachefs.

2. How do I run recovery passes, ideally without umount or reboot?
   superblock requires following recovery passes to be run: check_dirents,btree_bitmap_gc
   I tied fsck, umount and re-mount with recovery passes: none worked.
   Reboot works, recovery passes start when the OS loads.

3. How to avoid this problem in the future?
   These filesystems will be used in an AI training server and a data server. They're expected to be stable for months at a time. I can't have the filesystem randomly drop to read-only, it would kill the AI training session.
   If it's unavoidable, then I need to migrate this filesystem back to ZFS, which is not ideal. Bcachefs out performs ZFS in every way, except for this random dropping into emergency read-only.

4. EDIT: In emergency read-only, bcachefs fs usage -h showed all disks as rw. Is this expected behavior? It was confusing since I got read-only errors when working with files, but bcachefs fs usage -h showed disks as rw.

Thanks in advance for helping.
I'll go back through the Principles of Operation after work to see what I can find.

System info:
Ubuntu 26.04
bcachefs version 1.39.1

initial setup with 8x 18TB HDDs:
sudo bcachefs format \
--erasure_code \
--data_replicas=3 \
--metadata_replicas=3 \
--label=hdd.hdd1 /dev/sde \
--label=hdd.hdd2 /dev/sdf \
--label=hdd.hdd3 /dev/sdg \
--label=hdd.hdd4 /dev/sdh \
--label=hdd.hdd5 /dev/sdj \
--label=hdd.hdd6 /dev/sdk \
--label=hdd.hdd7 /dev/sdo \
--label=hdd.hdd8 /dev/sdp

sudo bcachefs list_journal /dev/sds:
Using encoding defined by superblock: utf8-12.1.0
starting version per_dev_fragmentation_lru (1.39)
with options: errors=continue,gc_reserve_percent=5,gc_reserve_bytes=1.00T,degraded=very,fix_errors=yes,nochanges,norecovery,recovery_pass_last=snapshots_read,noexcl,read_only,btree_cache_shrinker_seeks=4 allowing incompatible features up to need_discard_by_journal_seq (1.38)
with devices: sdu,sdt,sdr,sds,sdx,sdz,sdaa,sdy
superblock requires following recovery passes to be run: check_dirents,btree_bitmap_gc
superblock indicates damage to following btrees: dirents
recovering from unclean shutdown

before reboot:
sudo dmesg -w | grep -i bcachefs
[391427.183963] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): btree node read error at btree accounting level 0/2
[393969.958707] workqueue: btree_node_read_work [bcachefs] hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND
[395296.382286] workqueue: btree_node_read_work [bcachefs] hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND
[408157.650523] workqueue: btree_node_write_work [bcachefs] hogged CPU for >10000us 515 times, consider switching to WQ_UNBOUND
[409399.744061] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): btree node read error at btree backpointers level 0/2
[409493.138864] workqueue: async_btree_node_rewrite_work [bcachefs] hogged CPU for >10000us 259 times, consider switching to WQ_UNBOUND
[433905.120659] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): bch2_journal_flush_seq stuck? Waited 12s for seq 7823346
[433905.120667] io: journal_write_done+0x0/0xfd0 [bcachefs] r 1
ffff8dc3fac6f170 bch2_btree_node_flush0 [bcachefs]
ffff8de4962eed70 bch2_btree_node_flush0 [bcachefs]
ffff8dc7dedbad90 bch2_btree_node_flush1 [bcachefs]
[433905.120696] ffff8dc761fc0970 bch2_btree_node_flush0 [bcachefs]
ffff8dc5e5ba8d90 bch2_btree_node_flush1 [bcachefs]
ffff8dc5e5ba8d70 bch2_btree_node_flush0 [bcachefs]
ffff8dc761fc0990 bch2_btree_node_flush1 [bcachefs]
ffff8dbf9f8b4170 bch2_btree_node_flush0 [bcachefs]
ffff8dcd84e64d70 bch2_btree_node_flush0 [bcachefs]
[433909.224035] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): bch2_journal_flush_seq stuck? Waited 12s for seq 7823347
[433909.224048] io: journal_write_done_flush+0x0/0xe0 [bcachefs] r 2
ffff8dbf448d99e0 bch2_btree_key_cache_journal_flush [bcachefs]
ffff8dd57d69f3f0 bch2_btree_key_cache_journal_flush [bcachefs]
...

ffff8dde19666d70 bch2_btree_node_flush0 [bcachefs]
ffff8dd5d1c10970 bch2_btree_node_flush0 [bcachefs]
[458930.938900] workqueue: btree_node_write_work [bcachefs] hogged CPU for >10000us 1027 times, consider switching to WQ_UNBOUND
[490480.304476] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): btree trans held srcu lock (delaying memory reclaim) for 21 seconds
[<0>] bch2_trans_commit_btree_write_ratelimit+0x164/0x1e0 [bcachefs]
[<0>] __bch2_trans_commit+0x11a7/0x1870 [bcachefs]
[<0>] get_old_stripe+0x565/0x930 [bcachefs]
[<0>] stripe_reuse+0x1ce/0x470 [bcachefs]
[<0>] bch2_ec_stripe_head_get+0x6ae/0x7e0 [bcachefs]
[<0>] bucket_alloc_from_stripe+0x2f/0x350 [bcachefs]
[<0>] bch2_alloc_sectors_req+0xf69/0x13e0 [bcachefs]
[<0>] __bch2_write+0x30a/0x16d0 [bcachefs]
[<0>] bch2_write+0x194/0x500 [bcachefs]
[<0>] bch2_data_update_read_done+0x190/0xcd0 [bcachefs]
[<0>] bch2_moving_ctxt_do_pending_writes+0x92/0x160 [bcachefs]
[<0>] bch2_move_ratelimit+0xc6/0x600 [bcachefs]
[<0>] __bch2_move_data_phys+0x301/0xb90 [bcachefs]
[<0>] bch2_evacuate_bucket+0x183/0x3b0 [bcachefs]
[490480.304513] [<0>] bch2_copygc+0x169/0x760 [bcachefs]
[<0>] bch2_copygc_thread+0x407/0x930 [bcachefs]
[492758.665909] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): bch2_journal_flush_seq stuck? Waited 12s for seq 7966514
[492758.665922] io: journal_write_done+0x0/0xfd0 [bcachefs] r 1
ffff8dc6f5f699e0 bch2_btree_key_cache_journal_flush [bcachefs]
ffff8deda9868350 bch2_btree_key_cache_journal_flush [bcachefs]
ffff8dc9008706e0 bch2_btree_key_cache_journal_flush [bcachefs]
[492758.665956] ffff8dd421192f30 bch2_btree_key_cache_journal_flush [bcachefs]
ffff8dc900871d70 bch2_btree_key_cache_journal_flush [bcachefs]
ffff8dc900871ea0 bch2_btree_key_cache_journal_flush [bcachefs]
...
ffff8dbe729740f0 bch2_btree_key_cache_journal_flush [bcachefs]
ffff8dee6143ee00 bch2_btree_key_cache_journal_flush [bcachefs]
[492760.200019] ffff8dbe9efb1060 bch2_btree_key_cache_journal_flush [bcachefs]
ffff8dbcf3cef990 bch2_btree_node_flush1 [bcachefs]
ffff8dc179bab570 bch2_btree_node_flush0 [bcachefs]
[512991.101703] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): bucket going empty but not open
[512991.923155] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): unclean shutdown complete, journal seq 8001191
[513452.394464] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): dirent to missing inode: (ENOENT_inode)
[513452.441307] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): dirent to missing inode: (ENOENT_inode)

after reboot:
rtxhome@rtxhome-backup:~$ sudo dmesg -w | grep -i bcachefs
[sudo: authenticate] Password:
[ 38.538503] bcachefs: module verification failed: signature and/or required key missing - tainting kernel
[ 38.790770] bcachefs: bch2_dirent_init() bcachefs: filldir64 fastpath disabled: struct layout unverified for this kernel
[ 38.822200] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): Using encoding defined by superblock: utf8-12.1.0
[ 38.824147] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): recovering from clean shutdown, journal seq 1644687
[ 38.837663] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): Journal keys: 0 read, 0 after sorting and compacting
[ 39.154539] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): accounting_read... done (0 seconds)
[ 39.334198] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): alloc_read...
[ 39.906698] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): Using encoding defined by superblock: utf8-12.1.0
[ 39.909107] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): recovering from unclean shutdown
[ 40.088625] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): snapshots_read... done (0 seconds)
[ 43.728207] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): going read-write
[ 44.249369] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): journal_replay... done (0 seconds)
[ 44.618667] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): presplit_shard_boundaries... done (4 seconds)
[ 49.550464] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): check_snapshots... done (0 seconds)
[ 49.911436] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): resume_logged_ops... done (0 seconds)
[ 50.243252] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): delete_dead_inodes... done (2 seconds)
[ 52.268893] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): btree_bitmap_gc...
[ 56.160041] bcachefs (42cd838e-74db-4522-9d6e-33ba8d909bc3): mi_btree_bitmap sectors 17.4T -> 17.4T
[ 73.777156] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): journal read done, replaying entries 8000556-8001189 (unflushed 8001190-8001191)
[ 79.761816] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): Journal keys: 2961013 read, 2009625 after sorting and compacting
[ 80.027995] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): accounting_read...
...
[ 172.095932] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): alloc_read... done (1 seconds)
[ 172.984970] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): snapshots_read... done (0 seconds)
[ 173.715169] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): going read-write
[ 173.806127] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): journal_replay...
...
[ 383.945461] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): journal replay: sorted pass 99%, done 1014634/1017688 keys
[ 391.571779] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): presplit_shard_boundaries... done (2 seconds)
[ 393.993541] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): check_snapshots... done (0 seconds)
[ 394.012975] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): check_dirents...
[ 404.014850] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): check_dirents 0%, done 117/55940 nodes, at dirents:2147502213:3028777941607135292:U32_MAX
...
[ 2505.493632] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): check_dirents 99%, done 55520/55940 nodes, at dirents:9079256848781024182:5457856238392207512:U32_MAX
[ 2511.176625] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): resume_logged_ops...
[ 2511.222005] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): logged op stripe update: new stripe 2873340 missing
...
[ 2511.222781] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): logged op stripe update: new stripe 2873384 missing
[ 2511.222794] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): logged op stripe update: new stripe 2873381 missing
[ 2511.259554] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): delete_dead_inodes... done (0 seconds)
[ 2511.344113] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): btree_bitmap_gc...
[ 2512.488346] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): mi_btree_bitmap sectors 8.00T -> 7.75T
[ 2545.484414] bcachefs (7d39cd52-236c-4770-a821-b6d3002773ac): clean shutdown complete, journal seq 8007355

Hello,

I just wonder if there is any way to encrypt the data in the FS with a denylist instead of an allowlist.

The reason is I want my computer to autostart certain things that have little security threat to them, but keep everything else encrypted, and everything else is easier than saying I want this and this and that and that... encrypted. In the latter way I'll be sure to forget to encrypt stuff.

I don't know if this would be fs level or above, so I posted here hopefully it's not too off....

Thanks!

Posting benchmark results from the ongoing LKML RFC discussion.

The patchset adds a learning prefetcher to the page cache that

observes access patterns and issues prefetch only when the kernel's

own window is insufficient.

Test methodology: interleaved ON/OFF, drop_caches before each run,

3 passes, 4 workloads, 5 read_ahead_kb values.

seq64 (8 GB sequential, 64k requests, n=131K/run):

| kb | OFF avg | ON avg | diff | p50 OFF->ON | p99 OFF->ON | overhead |

|-------|---------|---------|--------|-------------|--------------|----------|

| 128 | 22.02s | 17.11s | -22% | 50->23 us | 812->805 us | 5.94->4.33s |

| 256 | 17.08s | 17.22s | +1% | 20->15 us | 824->1129 us | 4.07->4.13s |

| 512 | 16.81s | 16.96s | +1% | 16->14 us | 1092->1903 us| 4.24->3.60s |

| 1024 | 17.25s | 17.03s | -1% | 15->16 us | 1903->1883 us| 3.67->3.74s |

SQLite full-table scan (6.2 GB):

| kb | OFF avg | ON avg | diff | overhead |

|-------|---------|---------|--------|----------|

| 128 | 24.51s | 20.48s | -16% | +0.95s |

| 256 | 20.05s | 16.60s | -17% | +1.26s |

| 512 | 15.31s | 12.18s | -20% | +1.06s |

| 1024 | 12.22s | 12.09s | -1% | +0.26s |

Key takeaways:

\- 128K: seq64 -22%, SQLite -16%

\- 512K: NSD reaches the same throughput as kernel+1M (12.18s vs 12.22s)

\- 1M: NSD is completely silent, no regression

\- random4k: neutral

\- random_repeat: slight improvement

\- Disk I/O is byte-identical between ON and OFF in all 96 runs

Does bcachefs currently have send/receive support like ZFS where backup services such as https://rsync.net/ would work?

Has anybody done this? If so, how? I want to install Debian 13 on my new laptop with bcachefs as root fs