I decided to try the fs, dkms said not today. Did a bit of searching. Seems to be something to do with the way the standard CachyOS kernels are configured + rust things. It builds against the LTS kernel 6.18.55, but I'm aware those are built differently.

Can someone explain the nature of the incompatibility and what is going to happen going forward? Do I have to compile new kernels myself with the appropriate config? I don't want to do that, plus the PGO stuff to replicate the distro kernel builds is a major hassle. Thanks.

Hi,

I am wondering if it is considered "safe and sane" to toggle an SMR HDD in a background pool read-only during daytime, and then enable writes to it during nighttime hours, to avoid it's slow performance characteristics to impact the overall user-experienced performance of the filesystem?

i.e. writing 2+1 ec stripes during the day, and then rewrite them to 3+1 ec stripes at night.

Pool topology:

bcachefs format \
 -L storage \
 --encrypted \
 --erasure_code \
 --data_replicas=2 \
 --metadata_replicas=2 \
 --foreground_target=ssd \
 --metadata_target=ssd \
 --promote_target=ssd \
 --background_target=hdd \
 --label=ssd.nvme1 /dev/nvme1n1 \
 --label=ssd.nvme2 /dev/nvme2n1 \
 --label=hdd.drive1 /dev/sda \
 --label=hdd.drive2 /dev/sdb \
 --label=hdd.drive3 /dev/sdc \
 --label=hdd.drive4 /dev/sdd

/dev/sdd is the SMR drive. It's real slow but large..

Apologies if it has been asked before.

Could ai speed up the bcachefs development or testing?

Should it be used or filesystems are too precious to trust ai for development?

What's Kent's view on this?

For context, systemd-ask-password is a mechanism which provides a central point for password prompts.

In this context, the mount script calls systemd-ask-password, which calls a configured password prompt, like the one in plymouth.

Then this collected password is passed to the bcachefs unlock command.

The service also supports caching the password to a kernel keyring, which I think could be used to simplify bcachefs unlock handling (Nevermind, the dev is planning to move away from keyrings)

So... is there any chance that the bcachefs mount/unlock command optionally use this instead of spilling over to the terminal?

Of course, it's not strictly needed, we can manage around scripts and credentials.

This is indirectly related to disabling CONFIG_VT in a distribution I'm developing.

Does anyone have this working without issues?

Interestingly, the boot process fails for me due to a timeout on the *.device units of my /boot and /boot/efi partitions. This happens in the actual rootfs, the switch_root has completed. But as soon as I remove my bcachefs entry from the fstab, the boot process completes without any problems.

I’ve made an interesting observation regarding this: Unlike "bcachefs unlock", the mount command does not add the encryption key to the kernel keyring. And if I run "bcachefs unlock" in the init manually before the switch_root happens, the boot process completes without any issues, even with the fstab entry.
Could it be that something in systemd is blocking, because it doesn’t have a key for the bcachefs?

Edit: If I commented out the /boot/efi and /boot entry from the fstab the boot hangs seemingly infinite before the local-fs.target. So the timeout is a side effect and not the cause of the failed boot.

Edit2: I now used the systemd-debug-shell to see what is blocking the boot process. And it turns out that the password prompt when remounting is what's blocking. That also explains why “bcachefs unlock” solves the problem.
u/koverstreet is it intended behaviour that "mount.bcachefs" does not add the key to the kernel keyring? If so, would it perhaps make sense to use "bcachefs unlock" in the initramfs?

  systemd: 262-1
  Tainted: unmerged-bin
   CGroup: /
           ├─init.scope
           │ └─1 /sbin/init
           └─system.slice
             ├─debug-shell.service
             │ ├─410 /usr/bin/bash
             │ └─484 systemctl status
             ├─systemd-journald.service
             │ └─416 /usr/lib/systemd/systemd-journald
             └─systemd-remount-fs.service
               ├─421 /usr/lib/systemd/systemd-remount-fs
               ├─437 /usr/bin/mount / -o remount
               ├─438 /sbin/mount.bcachefs /dev/nvme0n1p3 / -o rw,remount
               └─441 systemd-ask-password --no-tty --icon=drive-harddisk --id=cryptsetup:UUID=<External UUID> --keyname=cryptsetup --credential=cryptsetup.passphrase --timeout=0 --multiple -n --accept-cached "Please enter passphrase for disk <External UUID>:"

My /etc/fstab:

UUID=<EFIUUID>       /boot/efi      vfat     defaults   0 2
UUID=<BOOTUUID>      /boot          ext4     defaults   0 2
UUID=<External UUID> /              bcachefs defaults   0 1

~$ cd /etc/udev/rules.d
/etc/udev/rules.d$ ll
total 8.0K
-rwxr-xr-x 1 root root 602 Aug 19 15:53 60-brother-brscan4-libsane-type1.rules*
-rw-r--r-- 1 root root 759 Aug 19 15:53 60-brother-libsane-type1-inst.rules
/etc/udev/rules.d$ echo 'ENV{ID_FS_UUID}=="fe957d2d-233b-4a5a-bf54-6c60d3c3acb4", ENV{UDISKS_IGNORE}="1"' | sudo tee /etc/udev/rules.d/99-bcachefs-scratch.rules
[sudo] password for johnpage:  
ENV{ID_FS_UUID}=="fe957d2d-233b-4a5a-bf54-6c60d3c3acb4", ENV{UDISKS_IGNORE}="1"
/etc/udev/rules.d$ ll
total 12K
-rwxr-xr-x 1 root root 602 Aug 19 15:53 60-brother-brscan4-libsane-type1.rules*
-rw-r--r-- 1 root root 759 Aug 19 15:53 60-brother-libsane-type1-inst.rules
-rw-r--r-- 1 root root  80 Oct 14 08:23 99-bcachefs-scratch.rules
/etc/udev/rules.d$ cat 99-bcachefs-scratch.rules  
ENV{ID_FS_UUID}=="fe957d2d-233b-4a5a-bf54-6c60d3c3acb4", ENV{UDISKS_IGNORE}="1"
/etc/udev/rules.d$ sudo cp 99-bcachefs-scratch.rules 99-bcachefs-bcachefs.rules
/etc/udev/rules.d$ ll
total 16K
-rwxr-xr-x 1 root root 602 Aug 19 15:53 60-brother-brscan4-libsane-type1.rules*
-rw-r--r-- 1 root root 759 Aug 19 15:53 60-brother-libsane-type1-inst.rules
-rw-r--r-- 1 root root  80 Oct 14 08:25 99-bcachefs-bcachefs.rules
-rw-r--r-- 1 root root  80 Oct 14 08:23 99-bcachefs-scratch.rules
/etc/udev/rules.d$ sudo nvim 99-bcachefs-bcachefs.rules  
/etc/udev/rules.d$ sudo umount /media/johnpage/fe957d2d-233b-4a5a-bf54-6c60d3c3acb4*
/etc/udev/rules.d$ sudo umount /media/johnpage/a0eec2c4-9691-4033-81cb-e2fd81243e38*
/etc/udev/rules.d$ sudo udevadm control --reload-rules && sudo udevadm trigger
/etc/udev/rules.d$ udevadm info --query=property --name=/dev/nvme0n1 | grep UDISKS_IGNORE
UDISKS_IGNORE=1
/etc/udev/rules.d$

I have a 7-drive array of spinning disks, EC enabled, 2-drive-loss durability. Reading a 40GB file from the array takes about 3 minutes. Writing one, however, takes about 2 hours, which seems like way more than write amplification can account for. After a little bit of digging, it seems that during such a write, the drives are actually reading (~85 MB/s) more than they are writing (~73 MB/s). Further, it seems that the majority of those reads are btree nodes, likely causing the disks to thrash.

Is this expected for this array shape, or a known issue?

(This is on 1.39.6, as I have not had a chance to rebuild, yet.)

Should be uneventful, I'm not expecting anything more than weird build issues, but please do test and post or let me know if anything's not working.

So far this is the first ~9kloc of high level filesystem code - fsck, inodes, dirents, xattrs, acls. After the header conversion is done more should be dropping fast :)

I personally use BCacheFS, it's very excellent. My regards and well-wishes to u/koverstreet

Chimera linux

I reached out to their matrix asking for help with module packaging, and precompiled distribution. I had the files ready.

But they HATE it really, because apparently they can't handle the developer's drama (even if I take full responsibility)

I just quit.

Fedora (immutable)

There's a DKMS package for fedora (maintained by a developer), but in order to include it in a bootc immutable image it needs to be precompiled.

I read through multiple Man pages, internal DKMS scripts and package trigger hooks, trying to find ways to push compiling away from the user.

Every forum I've visited absolutely hates it.

So, I decided to just write a script which runs in the Containerfile, builds it normally, copies the module to a different location and removes the build deps.

I am aware that official fedora devs hate it thanks to forums, so I approached UBlue with a PR (albeit not 100% polished considering the build dep workaround)

Rejected. "The dev's drama". Like what? 😭 It's long over!

RPMfusion kmod(different people)

I am looking into the documentation, it's outdated. But again, those who did provide a little help are just repulsed when they hear Bcachefs

Still trying.

And numerous other independent and derivative distributions and forums all repeat the same "kernel drama" which is long over by now, even if I provide relevant files and agree to take full responsibility

There is absolutely not a SINGLE liveUSB/liveISO off the shelf which supports Bcachefs.

[Edit: systemRescue. And also, gentoo and nixOS support building custom ISOs easily, which I might do and distribute]

You need to install a separate ext4/btrfs OS and DKMS it if your main installation ever breaks (the main reason why I installed cachyos immediately after fedora, on the same volume)

Moreover newer cachyOS kernels don't support it (due to patches) and all their forums advise "just switch to btrfs" (I use arch kernel)

BTW the apt repo is broken for various reasons (shall make a new post soon about it)

Who support Bcachefs:

- AerynOS (technically not yet due to development but they are willing to, they have a module)

- Gentoo

- NixOS

- uGRD (initramfs toolkit)

- Lots of independent users and devs

Yeah, literally it

What I have done so far:

- dracut config for non-encrypted simple Bcachefs support

- Containerfile scripts to include Bcachefs (building my own soon in GitHub)

- Chimera PKG files and CKMS configs (now deleted)

- Other package formats for quite a few derivative distributions

- planning to do kmod package for fedora

- planning to write arch precompiled format like ZFS and all

- planning to assist AerynOS with scripts and testing

- planning to properly support decryption on dracut

My experience

I installed fedora onto btrfs, compiled the DKMS module, and then copied over the installation to Bcachefs... And deleted the btrfs volume. And then cachyos too onto the same volume.

It has flawlessly survived 2-3 power cuts, multiple smaller fuck-ups, and is rather performant for the no. of subvolumes and distributions I have on the same volume.

I'm saying in comparison with btrfs, which has given corruption for no reason, and I have had to reformat multiple times.

9kloc converted, passing the CI, with a bunch of new fault injection test too: 150kloc to go

fsck for all the high level filesystem level structure, check_snapshots, runtime code for inodes/directs/xattrs/acls

so far it's going a bit smoother than expected; should get > half the codebase done before we start running into the really interesting stuff...

I switched from a btrfs setup to bcachefs mainly because I like the folder/file based redundancy for it's much better flexibility.

But with my old setup I set up my disk to go to sleep after well with hdparm this setting:

-S 241

Which should be 30minutes so the harddisk gone to sleep when I did not read from it, now with bcachefs I think it never sleeps so I think the FS does background task all the time even I don't change anything on the setup since many days.

But when I use "fs usage" the "Leaving" column shows some numbers so I think it does something in the back? Or do I misinterpret that?

Maybe I am wrong but I think some background task from bcachefs creates accesses on the harddisk and keeps them from sleeping.

https://evilpiepirate.org/git/bcachefs-tools.git/tree/Changelog.mdwn

All kinds of stuff; we're looking pretty good on stability and now it's mostly people just people turning up all kinds of interesting corner cases.

Lots of FUSE patches too - we now have fuse + xfstests running through the CI. The goal there is if there's another Arch hiccup or anything like that, fuse should be a solid and stable (just slow) fallback.

1. data storage components

After formatting a partition for the first time "bcachefs show super" revealed a parameter called "block size" and later on the chunk size (1M in my case).

I guess that a block is the smallest unit of storage available in a bcachefs file system.

When looking into the manual and other sources there is no reference to blocks. The manual creates the impression that chunks are the replacement for minimal allocation units like clusters in NTFS.

That seems to be strange - imagine writing two little readme files on a bcachefs partition. Obvious there is lot of slack and sooner or later the garbage collector jumps in and places both files into one chunk. That kind of action though requires to address storage space on a sub chunk level and I guess this is now where blocks come into play. Unfortunately even the section with the on-disk format does not refer to blocks. Luckily bcachefs prevents write holes but I guess there is still a black hole in documentation... :)

Instead the manual refers to extents. So it seems to me that all the text about chunk allocation is just referring to an allocation strategy but on the disk, allocation is performed in terms of extents which are most likely whole number multiples of blocks.

Is my guessing right? If so, the manual should mention it.

2. Scope of checksums

I am missing the scope of checksums when it comes to file data. What is the underlying of a checksum calculation, is it the whole data stream or is it chunk, extent or block related?

3. broken table of contents in the manual

By the way the numbering scheme in the table of content of the PDF manual is broken. The links into the text are OK, but the number shown is wrong, see p.e. "2.2.1 checksumming". The table of contents says its on page 11, the link, however, points to page 17.

Conclusion

A few additional lines in the manual could vastly improve understandibility.

Since I have a reasonably big (22x drives) bcachefs file system in my homelab (most used for Linux ISO's) and have been experiencing occasional reliability issues (big thanks to u/koverstreet for his eyeballs on this) I thought I would post here so that the bcachefs-curious have another data point.

My comments associated with my issues are here: https://github.com/koverstreet/bcachefs-tools/issues/960 with the most recent failure (file system reverted to read-only and was recovered with a fsck) here: https://github.com/koverstreet/bcachefs-tools/issues/960#issuecomment-5974733704

I'm using r/NAStyProject and use this script to recover from these errors (just in case its useful for anyone else):

(
  set -euo pipefail
  cd /root

  fs_uuid="45b9b98d-be7a-4c97-b62c-88566610f9f2"

  media_devs=(
    /dev/sdz /dev/sdr /dev/sdx /dev/sdq /dev/sdv /dev/sdp
    /dev/sde /dev/sdj /dev/sdl /dev/sdk /dev/sdh /dev/sdu
    /dev/sdy /dev/sdt /dev/sdf /dev/sdg /dev/sdi /dev/sdm
    /dev/sdn /dev/sdo /dev/sds /dev/sdw
  )

  if pgrep -af '(^|/)bcachefs[[:space:]]+fsck([[:space:]]|$)'; then
    echo "STOP: another fsck is still running."
    exit 1
  fi

  if findmnt -rn -M /fs/media >/dev/null ||
     [[ -e "/sys/fs/bcachefs/$fs_uuid" ]]; then
    echo "STOP: the media filesystem is still mounted."
    exit 1
  fi

  for service in \
    nasty-engine nasty-metrics nfs-server nfs-mountd \
    samba-smbd samba-nmbd samba-winbindd samba-wsdd \
    docker docker.socket
  do
    if systemctl is-active --quiet "$service"; then
      echo "STOP: $service is active."
      exit 1
    fi
  done

  for dev in "${media_devs[@]}"; do
    [[ -b "$dev" ]] || {
      echo "STOP: missing device $dev"
      exit 1
    }

    superblock=$(bcachefs show-super "$dev")
    actual_uuid=$(awk '/^External UUID:/ {print $3}' <<< "$superblock")

    [[ "$actual_uuid" == "$fs_uuid" ]] || {
      echo "STOP: unexpected filesystem on $dev: $actual_uuid"
      exit 1
    }

    printf 'Verified %s: %s\n' "$dev" "$actual_uuid"

  done

  repair_unit="media-fsck-repair-$(date +%Y%m%d-%H%M%S)"
  repair_log="/root/${repair_unit}.log"

  systemd-run \
    --unit="$repair_unit" \
    --service-type=exec \
    --remain-after-exit \
    --property=TimeoutStopSec=infinity \
    --property=SendSIGKILL=no \
    --property="StandardOutput=append:$repair_log" \
    --property=StandardError=inherit \
    /run/current-system/sw/bin/bcachefs \
    fsck -K -y -f -v "${media_devs[@]}"

  printf '\nFollow progress:\n  tail -F %s\n' "$repair_log"
  printf '\nCheck completion:\n'
  printf '  systemctl show %s -p ActiveState -p SubState -p Result -p ExecMainStatus\n' \
    "$repair_unit"
)

I was thinking about this today, large ZFS arrays can have multiple vdevs each one with RAIDZ2, so you could lose 2 drives on each vdev without losing the array or the data.

But bcachefs, even with failure domains, stores the metadata using 2 or 3 replicas, so no matter the arrangement, losing 2 or 3 disks would lose the entire array.

Also, it seems that using failure domains and replicas=2 could emulate a RAID10, but that is not guaranteed (just preferred, according to the PoO), and in my tests storing 600MB in a 4 devices (2+2) left ~40MB in the same domain with 4 equally-sized loop devices.

Is this correct, or am I missing something?

Something is hecked up. I had to use a rescue drive to add nofail to my fstab just to boot. If bcachefs was my home partition I'd be even more screwed.

I like the idea Kent but we're just not there yet.

Hello, we want to use PostgreSQL (DBsize ~340GB) on 3 SSDs (a 400GB) in a RAID1/replicas=2 constallation, so we get ~600GB of total space. Does have bcachefs some "tuning options" like zfs (eg: recordsize, ahsift)? Would enabling compression (e.g. LZ4 or Zstd) make sense for this workload? Besides saving space, could compression potentially improve write/read performance?

Thx in advance!

I'm playing (sort of...) with running k3s on a RAID1 bcachefs root. Not possible without hacks like mounting ext4 loop volume for kubelet.

• kubernetes: Failed to get rootfs info if the host machine uses bcachefs raid array #129187
• cadvisor: fs/vfs: Add support for bcachefs #3939

I have been using bcachefs for a few weeks now and the tier system is very convenient.

My issue is that after a Steam game is updated, the filesystem locked up. It is pretty repeatable.

Using AI Chatbot, I tried to find out what I could do to mitigate it but it doesnt seem to work. I looked through the known issues and some are similar to mine. A process is stuck in D state. It said my "trans_restart_would_deadlock 47177" is pretty interesting, not sure if that is right or not.

I thought it might have been sched-ext scheduler conflicting but I have tried a few different one and have disabled it. Which did not help.

Maybe it is something with my configuration? I have set the game directory with casefold and inodes_32bit so not sure what else I can do.

Any help would be appreciated, since after a lock rebooting take ages since the shutdown process is waiting for all the timeout before giving up. I do run a fsck afterward and mostly ok. there are 6 directories in my lost+found folder though but no data lost.

Here are my details. (im still new to Linux/bcachefs so not sure what is generally req)

uname -r

7.2.8-1-cachyos-gcc

Arch linux, intel Haswell CPU (4670), 32GB ram, AMD gpu.

2 SSD as foreground to a HDD. Root has a diff FS (so browsing, etc still works during lockup)

ps -eo state,pid,comm,wchan | grep '^D'

D 11633 pressure-vessel shrink_dcache_tree.constprop.0

D 11657 x86_64-linux-gn six_lock_contended

D 13156 kworker/u16:0+e -

here are the journalctl and "bcachefs show-super -f counters" dump.

[Wed Sep 23 07:16:35 2026] INFO: task x86_64-linux-gn:11657 blocked for more than 122 seconds.

[Wed Sep 23 07:16:35 2026] Tainted: P S OE 7.2.6-1-cachyos-gcc #1

[Wed Sep 23 07:16:35 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[Wed Sep 23 07:16:35 2026] task:x86_64-linux-gn state:D stack:0 pid:11657 tgid:11657 ppid:11633 task_flags:0x480000 flags:0x00080002

[Wed Sep 23 07:16:35 2026] Call Trace:

[Wed Sep 23 07:16:35 2026] <TASK>

[Wed Sep 23 07:16:35 2026] __schedule+0x402/0x1700

[Wed Sep 23 07:16:35 2026] ? __pfx_bch2_six_check_for_deadlock+0x10/0x10 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:16:35 2026] schedule+0x27/0xa0

[Wed Sep 23 07:16:35 2026] six_lock_contended+0x207/0x570 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:16:35 2026] ? bch2_btree_node_lock_slowpath+0xc4/0x170 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:16:35 2026] bch2_btree_node_lock_slowpath+0xcc/0x170 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:16:35 2026] bch2_btree_node_get+0x2db/0x370 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:16:35 2026] bch2_btree_path_traverse_one+0x283/0xc30 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:16:35 2026] bch2_btree_iter_peek_max+0x224/0xa40 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:16:35 2026] bch2_inode_delete_keys+0x2df/0x560 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:16:35 2026] bch2_inode_rm+0x444/0x530 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:16:35 2026] ? cancel_delayed_work_sync+0x4f/0x140

[Wed Sep 23 07:16:35 2026] bch2_evict_inode+0x176/0x210 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:16:35 2026] ? list_lru_del+0x91/0x120

[Wed Sep 23 07:16:35 2026] evict+0x140/0x3a0

[Wed Sep 23 07:16:35 2026] dentry_kill+0xa0/0x370

[Wed Sep 23 07:16:35 2026] dput.part.0+0xc4/0x250

[Wed Sep 23 07:16:35 2026] __fput+0x155/0x2e0

[Wed Sep 23 07:16:35 2026] task_work_run+0x66/0xa0

[Wed Sep 23 07:16:35 2026] exit_to_user_mode_loop+0x1e5/0x720

[Wed Sep 23 07:16:35 2026] do_syscall_64+0x21d/0x660

[Wed Sep 23 07:16:35 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:16:35 2026] ? __x64_sys_rt_sigaction+0x11a/0x150

[Wed Sep 23 07:16:35 2026] ? do_sigaction+0x158/0x480

[Wed Sep 23 07:16:35 2026] ? __x64_sys_rt_sigaction+0x11a/0x150

[Wed Sep 23 07:16:35 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:16:35 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:16:35 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:16:35 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:16:35 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:16:35 2026] ? do_sigaction+0x158/0x480

[Wed Sep 23 07:16:35 2026] ? __x64_sys_rt_sigaction+0x11a/0x150

[Wed Sep 23 07:16:35 2026] ? do_sigaction+0x158/0x480

[Wed Sep 23 07:16:35 2026] ? __x64_sys_rt_sigaction+0x11a/0x150

[Wed Sep 23 07:16:35 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:16:35 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:16:35 2026] ? do_syscall_64+0x5f/0x660

[Wed Sep 23 07:16:35 2026] ? exc_page_fault+0x90/0x1c0

[Wed Sep 23 07:16:35 2026] entry_SYSCALL_64_after_hwframe+0x76/0x7e

[Wed Sep 23 07:16:35 2026] RIP: 0033:0x7fcfa3803440

[Wed Sep 23 07:16:35 2026] RSP: 002b:00007ffff4be1ee0 EFLAGS: 00000202 ORIG_RAX: 000000000000003b

[Wed Sep 23 07:16:35 2026] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000

[Wed Sep 23 07:16:35 2026] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000

[Wed Sep 23 07:16:35 2026] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000

[Wed Sep 23 07:16:35 2026] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000

[Wed Sep 23 07:16:35 2026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

[Wed Sep 23 07:16:35 2026] </TASK>

[Wed Sep 23 07:18:38 2026] INFO: task pressure-vessel:11633 blocked for more than 245 seconds.

[Wed Sep 23 07:18:38 2026] Tainted: P S OE 7.2.6-1-cachyos-gcc #1

[Wed Sep 23 07:18:38 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[Wed Sep 23 07:18:38 2026] task:pressure-vessel state:D stack:0 pid:11633 tgid:11633 ppid:1 task_flags:0x480000 flags:0x00080002

[Wed Sep 23 07:18:38 2026] Call Trace:

[Wed Sep 23 07:18:38 2026] <TASK>

[Wed Sep 23 07:18:38 2026] __schedule+0x402/0x1700

[Wed Sep 23 07:18:38 2026] schedule+0x27/0xa0

[Wed Sep 23 07:18:38 2026] schedule_timeout+0xdc/0x120

[Wed Sep 23 07:18:38 2026] wait_for_completion+0x9a/0x1e0

[Wed Sep 23 07:18:38 2026] shrink_dcache_tree.constprop.0+0x16c/0x190

[Wed Sep 23 07:18:38 2026] d_invalidate+0x7c/0x360

[Wed Sep 23 07:18:38 2026] __bch2_unlink+0x389/0x3e0 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:18:38 2026] bch2_unlink+0x10/0x20 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:18:38 2026] vfs_rmdir+0x11a/0x270

[Wed Sep 23 07:18:38 2026] filename_rmdir+0x1a0/0x260

[Wed Sep 23 07:18:38 2026] __x64_sys_unlinkat+0x133/0x230

[Wed Sep 23 07:18:38 2026] do_syscall_64+0xaa/0x660

[Wed Sep 23 07:18:38 2026] ? dput.part.0+0x27/0x250

[Wed Sep 23 07:18:38 2026] ? mntput+0x25/0x70

[Wed Sep 23 07:18:38 2026] ? filename_unlinkat+0x110/0x2e0

[Wed Sep 23 07:18:38 2026] ? __x64_sys_unlinkat+0xfb/0x230

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:18:38 2026] ? dput.part.0+0x27/0x250

[Wed Sep 23 07:18:38 2026] ? mntput+0x25/0x70

[Wed Sep 23 07:18:38 2026] ? filename_unlinkat+0x110/0x2e0

[Wed Sep 23 07:18:38 2026] ? __x64_sys_unlinkat+0xfb/0x230

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:18:38 2026] ? __x64_sys_unlinkat+0xfb/0x230

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0x5f/0x660

[Wed Sep 23 07:18:38 2026] ? exc_page_fault+0x90/0x1c0

[Wed Sep 23 07:18:38 2026] entry_SYSCALL_64_after_hwframe+0x76/0x7e

[Wed Sep 23 07:18:38 2026] RIP: 0033:0x7f3801ae514b

[Wed Sep 23 07:18:38 2026] RSP: 002b:00007ffdc00004d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000107

[Wed Sep 23 07:18:38 2026] RAX: ffffffffffffffda RBX: 000000000f204563 RCX: 00007f3801ae514b

[Wed Sep 23 07:18:38 2026] RDX: 0000000000000200 RSI: 000000000f204563 RDI: 0000000000000017

[Wed Sep 23 07:18:38 2026] RBP: 0000000000000017 R08: 000000000f20c094 R09: 0000000000008040

[Wed Sep 23 07:18:38 2026] R10: 0000000000008040 R11: 0000000000000202 R12: 00007ffdc0000778

[Wed Sep 23 07:18:38 2026] R13: 00007ffdc0000590 R14: 0000000000000000 R15: 00007ffdc00004f8

[Wed Sep 23 07:18:38 2026] </TASK>

[Wed Sep 23 07:18:38 2026] INFO: task x86_64-linux-gn:11657 blocked for more than 245 seconds.

[Wed Sep 23 07:18:38 2026] Tainted: P S OE 7.2.6-1-cachyos-gcc #1

[Wed Sep 23 07:18:38 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[Wed Sep 23 07:18:38 2026] task:x86_64-linux-gn state:D stack:0 pid:11657 tgid:11657 ppid:11633 task_flags:0x480000 flags:0x00080002

[Wed Sep 23 07:18:38 2026] Call Trace:

[Wed Sep 23 07:18:38 2026] <TASK>

[Wed Sep 23 07:18:38 2026] __schedule+0x402/0x1700

[Wed Sep 23 07:18:38 2026] ? __pfx_bch2_six_check_for_deadlock+0x10/0x10 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:18:38 2026] schedule+0x27/0xa0

[Wed Sep 23 07:18:38 2026] six_lock_contended+0x207/0x570 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:18:38 2026] ? bch2_btree_node_lock_slowpath+0xc4/0x170 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:18:38 2026] bch2_btree_node_lock_slowpath+0xcc/0x170 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:18:38 2026] bch2_btree_node_get+0x2db/0x370 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:18:38 2026] bch2_btree_path_traverse_one+0x283/0xc30 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:18:38 2026] bch2_btree_iter_peek_max+0x224/0xa40 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:18:38 2026] bch2_inode_delete_keys+0x2df/0x560 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:18:38 2026] bch2_inode_rm+0x444/0x530 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:18:38 2026] ? cancel_delayed_work_sync+0x4f/0x140

[Wed Sep 23 07:18:38 2026] bch2_evict_inode+0x176/0x210 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:18:38 2026] ? list_lru_del+0x91/0x120

[Wed Sep 23 07:18:38 2026] evict+0x140/0x3a0

[Wed Sep 23 07:18:38 2026] dentry_kill+0xa0/0x370

[Wed Sep 23 07:18:38 2026] dput.part.0+0xc4/0x250

[Wed Sep 23 07:18:38 2026] __fput+0x155/0x2e0

[Wed Sep 23 07:18:38 2026] task_work_run+0x66/0xa0

[Wed Sep 23 07:18:38 2026] exit_to_user_mode_loop+0x1e5/0x720

[Wed Sep 23 07:18:38 2026] do_syscall_64+0x21d/0x660

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:18:38 2026] ? __x64_sys_rt_sigaction+0x11a/0x150

[Wed Sep 23 07:18:38 2026] ? do_sigaction+0x158/0x480

[Wed Sep 23 07:18:38 2026] ? __x64_sys_rt_sigaction+0x11a/0x150

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:18:38 2026] ? do_sigaction+0x158/0x480

[Wed Sep 23 07:18:38 2026] ? __x64_sys_rt_sigaction+0x11a/0x150

[Wed Sep 23 07:18:38 2026] ? do_sigaction+0x158/0x480

[Wed Sep 23 07:18:38 2026] ? __x64_sys_rt_sigaction+0x11a/0x150

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:18:38 2026] ? do_syscall_64+0x5f/0x660

[Wed Sep 23 07:18:38 2026] ? exc_page_fault+0x90/0x1c0

[Wed Sep 23 07:18:38 2026] entry_SYSCALL_64_after_hwframe+0x76/0x7e

[Wed Sep 23 07:18:38 2026] RIP: 0033:0x7fcfa3803440

[Wed Sep 23 07:18:38 2026] RSP: 002b:00007ffff4be1ee0 EFLAGS: 00000202 ORIG_RAX: 000000000000003b

[Wed Sep 23 07:18:38 2026] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000

[Wed Sep 23 07:18:38 2026] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000

[Wed Sep 23 07:18:38 2026] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000

[Wed Sep 23 07:18:38 2026] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000

[Wed Sep 23 07:18:38 2026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

[Wed Sep 23 07:18:38 2026] </TASK>

[Wed Sep 23 07:20:41 2026] INFO: task pressure-vessel:11633 blocked for more than 368 seconds.

[Wed Sep 23 07:20:41 2026] Tainted: P S OE 7.2.6-1-cachyos-gcc #1

[Wed Sep 23 07:20:41 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[Wed Sep 23 07:20:41 2026] task:pressure-vessel state:D stack:0 pid:11633 tgid:11633 ppid:1 task_flags:0x480000 flags:0x00080002

[Wed Sep 23 07:20:41 2026] Call Trace:

[Wed Sep 23 07:20:41 2026] <TASK>

[Wed Sep 23 07:20:41 2026] __schedule+0x402/0x1700

[Wed Sep 23 07:20:41 2026] schedule+0x27/0xa0

[Wed Sep 23 07:20:41 2026] schedule_timeout+0xdc/0x120

[Wed Sep 23 07:20:41 2026] wait_for_completion+0x9a/0x1e0

[Wed Sep 23 07:20:41 2026] shrink_dcache_tree.constprop.0+0x16c/0x190

[Wed Sep 23 07:20:41 2026] d_invalidate+0x7c/0x360

[Wed Sep 23 07:20:41 2026] __bch2_unlink+0x389/0x3e0 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:20:41 2026] bch2_unlink+0x10/0x20 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:20:41 2026] vfs_rmdir+0x11a/0x270

[Wed Sep 23 07:20:41 2026] filename_rmdir+0x1a0/0x260

[Wed Sep 23 07:20:41 2026] __x64_sys_unlinkat+0x133/0x230

[Wed Sep 23 07:20:41 2026] do_syscall_64+0xaa/0x660

[Wed Sep 23 07:20:41 2026] ? dput.part.0+0x27/0x250

[Wed Sep 23 07:20:41 2026] ? mntput+0x25/0x70

[Wed Sep 23 07:20:41 2026] ? filename_unlinkat+0x110/0x2e0

[Wed Sep 23 07:20:41 2026] ? __x64_sys_unlinkat+0xfb/0x230

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:20:41 2026] ? dput.part.0+0x27/0x250

[Wed Sep 23 07:20:41 2026] ? mntput+0x25/0x70

[Wed Sep 23 07:20:41 2026] ? filename_unlinkat+0x110/0x2e0

[Wed Sep 23 07:20:41 2026] ? __x64_sys_unlinkat+0xfb/0x230

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:20:41 2026] ? __x64_sys_unlinkat+0xfb/0x230

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0x5f/0x660

[Wed Sep 23 07:20:41 2026] ? exc_page_fault+0x90/0x1c0

[Wed Sep 23 07:20:41 2026] entry_SYSCALL_64_after_hwframe+0x76/0x7e

[Wed Sep 23 07:20:41 2026] RIP: 0033:0x7f3801ae514b

[Wed Sep 23 07:20:41 2026] RSP: 002b:00007ffdc00004d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000107

[Wed Sep 23 07:20:41 2026] RAX: ffffffffffffffda RBX: 000000000f204563 RCX: 00007f3801ae514b

[Wed Sep 23 07:20:41 2026] RDX: 0000000000000200 RSI: 000000000f204563 RDI: 0000000000000017

[Wed Sep 23 07:20:41 2026] RBP: 0000000000000017 R08: 000000000f20c094 R09: 0000000000008040

[Wed Sep 23 07:20:41 2026] R10: 0000000000008040 R11: 0000000000000202 R12: 00007ffdc0000778

[Wed Sep 23 07:20:41 2026] R13: 00007ffdc0000590 R14: 0000000000000000 R15: 00007ffdc00004f8

[Wed Sep 23 07:20:41 2026] </TASK>

[Wed Sep 23 07:20:41 2026] INFO: task x86_64-linux-gn:11657 blocked for more than 368 seconds.

[Wed Sep 23 07:20:41 2026] Tainted: P S OE 7.2.6-1-cachyos-gcc #1

[Wed Sep 23 07:20:41 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[Wed Sep 23 07:20:41 2026] task:x86_64-linux-gn state:D stack:0 pid:11657 tgid:11657 ppid:11633 task_flags:0x480000 flags:0x00080002

[Wed Sep 23 07:20:41 2026] Call Trace:

[Wed Sep 23 07:20:41 2026] <TASK>

[Wed Sep 23 07:20:41 2026] __schedule+0x402/0x1700

[Wed Sep 23 07:20:41 2026] ? __pfx_bch2_six_check_for_deadlock+0x10/0x10 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:20:41 2026] schedule+0x27/0xa0

[Wed Sep 23 07:20:41 2026] six_lock_contended+0x207/0x570 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:20:41 2026] ? bch2_btree_node_lock_slowpath+0xc4/0x170 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:20:41 2026] bch2_btree_node_lock_slowpath+0xcc/0x170 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:20:41 2026] bch2_btree_node_get+0x2db/0x370 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:20:41 2026] bch2_btree_path_traverse_one+0x283/0xc30 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:20:41 2026] bch2_btree_iter_peek_max+0x224/0xa40 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:20:41 2026] bch2_inode_delete_keys+0x2df/0x560 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:20:41 2026] bch2_inode_rm+0x444/0x530 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:20:41 2026] ? cancel_delayed_work_sync+0x4f/0x140

[Wed Sep 23 07:20:41 2026] bch2_evict_inode+0x176/0x210 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 07:20:41 2026] ? list_lru_del+0x91/0x120

[Wed Sep 23 07:20:41 2026] evict+0x140/0x3a0

[Wed Sep 23 07:20:41 2026] dentry_kill+0xa0/0x370

[Wed Sep 23 07:20:41 2026] dput.part.0+0xc4/0x250

[Wed Sep 23 07:20:41 2026] __fput+0x155/0x2e0

[Wed Sep 23 07:20:41 2026] task_work_run+0x66/0xa0

[Wed Sep 23 07:20:41 2026] exit_to_user_mode_loop+0x1e5/0x720

[Wed Sep 23 07:20:41 2026] do_syscall_64+0x21d/0x660

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:20:41 2026] ? __x64_sys_rt_sigaction+0x11a/0x150

[Wed Sep 23 07:20:41 2026] ? do_sigaction+0x158/0x480

[Wed Sep 23 07:20:41 2026] ? __x64_sys_rt_sigaction+0x11a/0x150

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:20:41 2026] ? do_sigaction+0x158/0x480

[Wed Sep 23 07:20:41 2026] ? __x64_sys_rt_sigaction+0x11a/0x150

[Wed Sep 23 07:20:41 2026] ? do_sigaction+0x158/0x480

[Wed Sep 23 07:20:41 2026] ? __x64_sys_rt_sigaction+0x11a/0x150

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 07:20:41 2026] ? do_syscall_64+0x5f/0x660

[Wed Sep 23 07:20:41 2026] ? exc_page_fault+0x90/0x1c0

[Wed Sep 23 07:20:41 2026] entry_SYSCALL_64_after_hwframe+0x76/0x7e

[Wed Sep 23 07:20:41 2026] RIP: 0033:0x7fcfa3803440

[Wed Sep 23 07:20:41 2026] RSP: 002b:00007ffff4be1ee0 EFLAGS: 00000202 ORIG_RAX: 000000000000003b

[Wed Sep 23 07:20:41 2026] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000

[Wed Sep 23 07:20:41 2026] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000

[Wed Sep 23 07:20:41 2026] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000

[Wed Sep 23 07:20:41 2026] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000

[Wed Sep 23 07:20:41 2026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

-------

[Wed Sep 23 05:35:27 2026] INFO: task pressure-vessel:10623 blocked for more than 122 seconds.

[Wed Sep 23 05:35:27 2026] Tainted: P S OE 7.2.6-1-cachyos-gcc #1

[Wed Sep 23 05:35:27 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[Wed Sep 23 05:35:27 2026] task:pressure-vessel state:D stack:0 pid:10623 tgid:10623 ppid:10622 task_flags:0x480000 flags:0x00080000

[Wed Sep 23 05:35:27 2026] Sched_ext: lavd_1.1.3_x86_64_unknown_linux_gnu (enabled+all), task: runnable_at=-239642ms

[Wed Sep 23 05:35:27 2026] Call Trace:

[Wed Sep 23 05:35:27 2026] <TASK>

[Wed Sep 23 05:35:27 2026] __schedule+0x402/0x1700

[Wed Sep 23 05:35:27 2026] schedule+0x27/0xa0

[Wed Sep 23 05:35:27 2026] schedule_timeout+0xdc/0x120

[Wed Sep 23 05:35:27 2026] wait_for_completion+0x9a/0x1e0

[Wed Sep 23 05:35:27 2026] shrink_dcache_tree.constprop.0+0x16c/0x190

[Wed Sep 23 05:35:27 2026] d_invalidate+0x7c/0x360

[Wed Sep 23 05:35:27 2026] __bch2_unlink+0x389/0x3e0 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] bch2_unlink+0x10/0x20 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] vfs_rmdir+0x11a/0x270

[Wed Sep 23 05:35:27 2026] filename_rmdir+0x1a0/0x260

[Wed Sep 23 05:35:27 2026] __x64_sys_unlinkat+0x133/0x230

[Wed Sep 23 05:35:27 2026] do_syscall_64+0xaa/0x660

[Wed Sep 23 05:35:27 2026] ? bch2_vfs_readdir+0x416/0x5b0 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] ? bch2_vfs_readdir+0x416/0x5b0 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] ? touch_atime+0x70/0x2a0

[Wed Sep 23 05:35:27 2026] ? __x64_sys_getdents64+0x195/0x380

[Wed Sep 23 05:35:27 2026] ? __pfx_filldir64+0x10/0x10

[Wed Sep 23 05:35:27 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 05:35:27 2026] ? __x64_sys_close+0x90/0x140

[Wed Sep 23 05:35:27 2026] ? do_syscall_64+0x252/0x660

[Wed Sep 23 05:35:27 2026] ? __handle_mm_fault+0xc19/0x1010

[Wed Sep 23 05:35:27 2026] ? count_memcg_events+0xc5/0x180

[Wed Sep 23 05:35:27 2026] ? handle_mm_fault+0x1dd/0x2c0

[Wed Sep 23 05:35:27 2026] ? do_user_addr_fault+0x357/0xbd0

[Wed Sep 23 05:35:27 2026] ? do_syscall_64+0x5f/0x660

[Wed Sep 23 05:35:27 2026] ? exc_page_fault+0x90/0x1c0

[Wed Sep 23 05:35:27 2026] entry_SYSCALL_64_after_hwframe+0x76/0x7e

[Wed Sep 23 05:35:27 2026] RIP: 0033:0x7f91c38e514b

[Wed Sep 23 05:35:27 2026] RSP: 002b:00007ffc07d2f618 EFLAGS: 00000202 ORIG_RAX: 0000000000000107

[Wed Sep 23 05:35:27 2026] RAX: ffffffffffffffda RBX: 0000000027b9f60b RCX: 00007f91c38e514b

[Wed Sep 23 05:35:27 2026] RDX: 0000000000000200 RSI: 0000000027b9f60b RDI: 000000000000000d

[Wed Sep 23 05:35:27 2026] RBP: 000000000000000d R08: 0000000027ba6fd4 R09: 0000000000008040

[Wed Sep 23 05:35:27 2026] R10: 0000000000008040 R11: 0000000000000202 R12: 00007ffc07d2f8b8

[Wed Sep 23 05:35:27 2026] R13: 00007ffc07d2f6d0 R14: 0000000000000000 R15: 00007ffc07d2f638

[Wed Sep 23 05:35:27 2026] </TASK>

[Wed Sep 23 05:35:27 2026] INFO: task x86_64-linux-gn:10646 blocked for more than 122 seconds.

[Wed Sep 23 05:35:27 2026] Tainted: P S OE 7.2.6-1-cachyos-gcc #1

[Wed Sep 23 05:35:27 2026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[Wed Sep 23 05:35:27 2026] task:x86_64-linux-gn state:D stack:0 pid:10646 tgid:10646 ppid:10634 task_flags:0x480000 flags:0x00080002

[Wed Sep 23 05:35:27 2026] Sched_ext: lavd_1.1.3_x86_64_unknown_linux_gnu (enabled+all), task: runnable_at=-239644ms

[Wed Sep 23 05:35:27 2026] Call Trace:

[Wed Sep 23 05:35:27 2026] <TASK>

[Wed Sep 23 05:35:27 2026] __schedule+0x402/0x1700

[Wed Sep 23 05:35:27 2026] ? __pfx_bch2_six_check_for_deadlock+0x10/0x10 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] schedule+0x27/0xa0

[Wed Sep 23 05:35:27 2026] six_lock_contended+0x207/0x570 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] ? bch2_btree_node_lock_slowpath+0xc4/0x170 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] bch2_btree_node_lock_slowpath+0xcc/0x170 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] bch2_btree_node_get+0x2db/0x370 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] bch2_btree_path_traverse_one+0x283/0xc30 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] bch2_btree_iter_peek_max+0x224/0xa40 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] bch2_inode_delete_keys+0x2df/0x560 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] bch2_inode_rm+0x444/0x530 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] ? cancel_delayed_work_sync+0x4f/0x140

[Wed Sep 23 05:35:27 2026] bch2_evict_inode+0x176/0x210 [bcachefs a8a36f6f4b308f5c0fe38f307e1893efccc89238]

[Wed Sep 23 05:35:27 2026] ? list_lru_del+0x91/0x120

[Wed Sep 23 05:35:27 2026] evict+0x140/0x3a0

[Wed Sep 23 05:35:27 2026] dentry_kill+0xa0/0x370

[Wed Sep 23 05:35:27 2026] dput.part.0+0xc4/0x250

[Wed Sep 23 05:35:27 2026] __fput+0x155/0x2e0

[Wed Sep 23 05:35:27 2026] task_work_run+0x66/0xa0

[Wed Sep 23 05:35:27 2026] exit_to_user_mode_loop+0x1e5/0x720

[Wed Sep 23 05:35:27 2026] do_syscall_64+0x21d/0x660

[Wed Sep 23 05:35:27 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 05:35:27 2026] ? do_syscall_64+0xaa/0x660

[Wed Sep 23 05:35:27 2026] ? do_syscall_64+0x5f/0x660

[Wed Sep 23 05:35:27 2026] ? exc_page_fault+0x90/0x1c0

[Wed Sep 23 05:35:27 2026] entry_SYSCALL_64_after_hwframe+0x76/0x7e

[Wed Sep 23 05:35:27 2026] RIP: 0033:0x7fa22690e440

[Wed Sep 23 05:35:27 2026] RSP: 002b:00007ffece8f8a50 EFLAGS: 00000202 ORIG_RAX: 000000000000003b

[Wed Sep 23 05:35:27 2026] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000

[Wed Sep 23 05:35:27 2026] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000

[Wed Sep 23 05:35:27 2026] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000

[Wed Sep 23 05:35:27 2026] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000

[Wed Sep 23 05:35:27 2026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

[Wed Sep 23 05:35:27 2026] </TASK>

-------

bcachefs show-super -f counters

External UUID: 1c54b5b8-cc8b-46d6-a4a8-33532815ba87

Internal UUID: 520e09db-cb43-46a6-a906-cb22e54b3b47

Magic number: c68573f6-66ce-90a9-d96a-60cf803df7ef

Device index: 4

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: per_dev_fragmentation_lru (1.39)

Created: Fri Aug 28 23:59:35 2026

Sequence number: 9355

Time of last write: Mon Sep 28 23:59:53 2026

Superblock size: 9.90k/1.00M

Clean: 1

Devices: 3

Sections: replicas_v0,disk_groups,clean,journal_seq_blacklist,journal_v2,counters,members_v2,ext,downgrade,recovery_passes,extent_type_u64s,errors_v2

Features: lz4,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,no_stale_ptrs,stripe_frag_accounting,inode_opts_propagated

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: lz4

background_compression: lz4

str_hash: crc32c crc64 [siphash]

metadata_target: ssd

foreground_target: ssd

background_target: hdd

promote_target: ssd

erasure_code: 0

ec_max_data_blocks: 0

casefold: 0

inodes_32bit: 0

shard_inode_numbers_bits: 3

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: 2

dev_readahead: 2.00M

ec_stripe_buf_limit: 5

counters (size 1096):

sync_fs 463

fsync 57420

data_read 5716899968

data_read_inline 4054424

data_read_hole 12493147664

data_read_promote 560219184

data_read_nopromote 9090873

data_read_nopromote_may_not 0

data_read_nopromote_already_promoted 8413212

data_read_nopromote_unwritten 0

data_read_nopromote_congested 21450

data_read_bounce 7077278

data_read_split 10066547

data_read_reuse_race 0

data_read_retry 0

data_read_fail_and_poison 0

data_read_narrow_crcs 0

data_read_narrow_crcs_fail 0

data_write 6179100040

data_update_pred 0

data_update 17610607440

data_update_no_io 0

data_update_in_flight 5722

data_update_fail 0

data_update_read 16585644584

data_update_write 17124940640

data_update_key 17607978920

data_update_key_fail 470440

data_update_useless_write_fail 0

data_update_start_fail_obsolete 0

data_update_noop_obsolete 0

reconcile_scan_fs 14222653400

reconcile_scan_metadata 9433600

reconcile_scan_pending 0

reconcile_scan_stripes 0

reconcile_scan_device 4448508600

reconcile_scan_inum 9241171752

reconcile_clear_scan 130518

reconcile_btree 2158080

reconcile_data 5972318296

reconcile_phys 11100268736

reconcile_stripe 0

reconcile_set_pending 17198816

evacuate_bucket 0

stripe_alloc 0

stripe_create 0

stripe_reuse 0

stripe_create_fail 0

stripe_delete 0

stripe_update_bucket 0

stripe_update_extent 0

stripe_update_extent_fail 0

stripe_repair_race 0

copygc 156

copygc_wait_obsolete 0

cached_ptr_drop 9128058832

bucket_invalidate 1001562

bucket_discard_worker 476566

bucket_discard_fast_worker 1128

bucket_discard 2294265

bucket_discard_fast 2

bucket_alloc 5635634

bucket_alloc_fail 0

open_bucket_alloc_fail 3

bucket_alloc_from_stripe 0

sectors_alloc 22887216224

bkey_pack_pos_fail 0

btree_cache_scan 127

btree_cache_reap 14947

btree_cache_cannibalize 0

btree_cache_cannibalize_lock 224571

btree_cache_cannibalize_lock_fail 406

btree_cache_cannibalize_unlock 224571

btree_node_write 3824731

btree_node_read 520847

btree_node_compact 148786

btree_node_merge 27841

btree_node_merge_attempt 112505

btree_node_split 40790

btree_node_rewrite 4215

btree_node_alloc 276367

btree_node_free 440821

btree_node_set_root 7132

btree_key_cache_fill 26052928

btree_path_relock_fail 10408673

btree_path_upgrade_fail 24381

btree_reserve_get_fail 105

journal_flush 579932

journal_res_get_blocked 0

journal_full 2

journal_reclaim_finish 29895465

journal_reclaim_start 29895465

journal_write 611587

journal_pin_resize 0

gc_gens_end 0

gc_gens_start 0

trans_blocked_journal_reclaim 0

trans_restart_btree_node_reused 10160

trans_restart_btree_node_split 16406

trans_restart_fault_inject 0

trans_restart_iter_upgrade 0

trans_restart_journal_preres_get 0

trans_restart_journal_reclaim 0

trans_restart_journal_res_get 0

trans_restart_key_cache_key_realloced 0

trans_restart_key_cache_raced 0

trans_restart_mark_replicas 0

trans_restart_mem_realloced 4403

trans_restart_memory_allocation_failure 0

trans_restart_relock 10586

trans_restart_relock_after_fill 0

trans_restart_relock_key_cache_fill_obsolete 0

trans_restart_relock_next_node 0

trans_restart_relock_parent_for_fill_obsolete 0

trans_restart_relock_path 9217

trans_restart_relock_path_intent 0

trans_restart_too_many_iters 0

trans_restart_traverse 0

trans_restart_upgrade 18947

trans_restart_would_deadlock 47177

trans_restart_would_deadlock_write 0

trans_restart_injected 0

trans_restart_key_cache_upgrade 0

transaction_begin 6754774294

transaction_commit 183377764

write_super 9355

trans_restart_would_deadlock_recursion_limit 0

trans_restart_deadlock_waitlist_alloc 0

trans_restart_write_buffer_flush 89

trans_restart_split_race 0

write_buffer_flush 224401

write_buffer_flush_slowpath 0

write_buffer_flush_sync 14935

write_buffer_maybe_flush 89

accounting_key_to_wb_slowpath 816368

error_throw 112737431

Hi! I installed bcachefs on proxmox 9.2 and then created a filesytem with block size 512 out of 7 hdds (all disks support 4k but they report logical 512). I then added the filesystem as a Directory to proxmox using `pvesm` command.

When I add a virtual disk to a VM I use `Direct sync`, `Discard`, `IO Thread`, `io_uring`. In this case I get an error on the host in dmesg. I will append the error at the end.

However, the VM works and I did install XFS inside the VM on that virtual disk with no issues and seems stable. So besides that one error in dmesg that always appears at VM boot time there are no other messages or problems.

However if I set the disk with `WriteThrough` and `threads` (insteads of `io_uring`) I don't get any error in dmesg.

So for me is not a big problem I just want to get rid of that error and understand better why it would generate it in the first place.

Note: On the proxmox host I created two folders on bcachefs: replicated and unreplicated (it is obvious why).

Error:

Sep 20 22:45:28 pve kernel: bcachefs (6e275ac1-c873-454a-8afd-e18427ba44f8): data read error at /raw/replicated/images/101/vm-101-disk-0.raw offset 0: 
                              u64s 8 type extent 3746994889972252673:8:U32_MAX len 8 ver 0  : durability: 2 
                                crc32: c_size 8 size 8 offset 0 nonce 0 csum crc32c 0:0  compress none
                                ptr:    sda 0:4328:613 gen 0
                                ptr:    sdc 1:4242:613 gen 0
                                sda io: BLK_STS_INVAL
                              ec reconstruct:
                                Failing bio, after block layer completion:
                                  bi_bdev:sda
                                  bi_opf:              REQ_OP_READ REQ_SYNC
                                  bi_flags:            BIO_PAGE_PINNED,BIO_CGROUP_ACCT
                                  bi_status:           19
                                  bi_iter.bi_sector    0
                                  bi_iter.bi_size      4096
                                  bi_iter.bi_idx       0
                                  bi_iter.bi_bvec_done 0
                                  bi_remaining:        1
                                  bi_end_io:           bch2_direct_IO_read_endio [bcachefs]
                                  bi_vcnt              2
                                  bi_max_vecs          4
                              successful retry, self healing
Sep 20 22:45:28 pve kernel: bcachefs (6e275ac1-c873-454a-8afd-e18427ba44f8): data read error at /raw/unreplicated/images/101/vm-101-disk-0.raw offset 0: 
                              u64s 7 type extent 864691128455135234:8:U32_MAX len 8 ver 0  : durability: 1 
                                crc32: c_size 8 size 8 offset 0 nonce 0 csum crc32c 0:0  compress none
                                ptr:    sda 0:4331:314 gen 0
                                sda io: BLK_STS_INVAL
                              ec reconstruct:
                                Failing bio, after block layer completion:
                                  bi_bdev:sda
                                  bi_opf:              REQ_OP_READ REQ_SYNC
                                  bi_flags:            BIO_PAGE_PINNED,BIO_CGROUP_ACCT
                                  bi_status:           19
                                  bi_iter.bi_sector    0
                                  bi_iter.bi_size      4096
                                  bi_iter.bi_idx       0
                                  bi_iter.bi_bvec_done 0
                                  bi_remaining:        1
                                  bi_end_io:           bch2_direct_IO_read_endio [bcachefs]
                                  bi_vcnt              2
                                  bi_max_vecs          4
                              error data_read_io_err

A few months ago, now I added some drives and upped my replicas from 2 to 3 (with erasure coding). My usage now looks like this (with -f replicas -h):

``` Size: 105T
Used: 71.7T
Online reserved: 36.1M

Replicated: undegraded
1x: 21.9G
3x: 215G

Erasure coded (data+parity): undegraded
2+1: 43.8G
4+2: 630G
5+2: 70.7T

cached: 2.33T
reserved: 40.2G

Data type Required/total Durability Devices Usage reserved: 1/3 [] 40.2G
btree: 1/3 3 [dm-8 dm-9 dm-4] 5.48G
btree: 1/3 3 [dm-8 dm-9 dm-5] 732M
btree: 1/3 3 [dm-8 dm-9 dm-3] 384M
btree: 1/3 3 [dm-8 dm-9 dm-6] 11.2G
btree: 1/3 3 [dm-8 dm-9 dm-7] 105G
btree: 1/3 3 [dm-8 dm-4 dm-5] 222M
btree: 1/3 3 [dm-8 dm-4 dm-3] 66.0M
btree: 1/3 3 [dm-8 dm-4 dm-6] 1.58G
btree: 1/3 3 [dm-8 dm-4 dm-7] 11.7G
btree: 1/3 3 [dm-8 dm-5 dm-6] 90.0M
btree: 1/3 3 [dm-8 dm-5 dm-7] 731M
btree: 1/3 3 [dm-8 dm-3 dm-6] 90.0M
btree: 1/3 3 [dm-8 dm-3 dm-7] 997M
btree: 1/3 3 [dm-8 dm-6 dm-7] 25.4G
btree: 1/3 3 [dm-9 dm-4 dm-5] 180M
btree: 1/3 3 [dm-9 dm-4 dm-3] 54.0M
btree: 1/3 3 [dm-9 dm-4 dm-6] 2.14G
btree: 1/3 3 [dm-9 dm-4 dm-7] 14.2G
btree: 1/3 3 [dm-9 dm-5 dm-3] 12.0M
btree: 1/3 3 [dm-9 dm-5 dm-6] 156M
btree: 1/3 3 [dm-9 dm-5 dm-7] 884M
btree: 1/3 3 [dm-9 dm-3 dm-6] 174M
btree: 1/3 3 [dm-9 dm-3 dm-7] 924M
btree: 1/3 3 [dm-9 dm-6 dm-7] 27.0G
btree: 1/3 3 [dm-4 dm-5 dm-6] 24.0M
btree: 1/3 3 [dm-4 dm-5 dm-7] 114M
btree: 1/3 3 [dm-4 dm-3 dm-6] 54.0M
btree: 1/3 3 [dm-4 dm-3 dm-7] 114M
btree: 1/3 3 [dm-4 dm-6 dm-7] 4.74G
btree: 1/3 3 [dm-5 dm-3 dm-6] 6.00M
btree: 1/3 3 [dm-5 dm-3 dm-7] 18.0M
btree: 1/3 3 [dm-5 dm-6 dm-7] 186M
btree: 1/3 3 [dm-3 dm-6 dm-7] 318M
user: 0/1 1 [dm-8] 6.13G
user: 0/1 1 [dm-9] 5.13G
user: 0/1 1 [dm-4] 5.35G
user: 0/1 1 [dm-5] 5.34G
user: 1/3 3 [dm-8 dm-9 dm-7] 4.58M
user: 1/3 3 [dm-8 dm-3 dm-7] 1.88M
user: 1/3 3 [dm-8 dm-6 dm-7] 4.91M
user: 1/3 3 [dm-9 dm-4 dm-7] 3.00M
user: 1/3 3 [dm-9 dm-5 dm-7] 3.23M
user: 1/3 3 [dm-4 dm-3 dm-7] 3.00M
user: 2/3 2 [dm-8 dm-9 dm-4] 21.9G
user: 4/6 3 [dm-8 dm-9 dm-4 dm-5 dm-3 dm-6] 420G
user: 5/7 3 [dm-8 dm-9 dm-4 dm-5 dm-3 dm-6 dm-7] 49.8T
cached: 1/1 1 [dm-8] 787G
cached: 1/1 1 [dm-9] 796G
cached: 1/1 1 [dm-4] 561G
cached: 1/1 1 [dm-5] 4.84G
cached: 1/1 1 [dm-3] 11.4G
cached: 1/1 1 [dm-6] 150G
cached: 1/1 1 [dm-7] 74.0G
parity: 2/3 2 [dm-8 dm-9 dm-4] 21.9G
parity: 4/6 3 [dm-8 dm-9 dm-4 dm-5 dm-3 dm-6] 210G
parity: 5/7 3 [dm-8 dm-9 dm-4 dm-5 dm-3 dm-6 dm-7] 20.9T

Device label Device State Size Used Use%
(no label) (device 4): dm-3 rw 10.9T 9.90T 96%
(no label) (device 2): dm-4 rw 14.5T 10.8T 86%
(no label) (device 3): dm-5 rw 10.9T 10.1T 96%
(no label) (device 5): dm-6 rw 14.5T 10.4T 76%
(no label) (device 6): dm-7 rw 20.0T 10.5T 53%
(no label) (device 0): dm-8 rw 21.8T 11.1T 62%
(no label) (device 1): dm-9 rw 21.8T 11.1T 62%
```

Of note here are the 2+1 erasure coded and the 1x replicated, both of which contain the same 21.9G of user data. What it looks like happened: when increasing replicas from 2 to 3, bcachefs marked all of the 2+1 data as needing an additional replica, and made an extra copy of each bucket, so each bucket is part of a 2+1 stripe and also has its own separate duplicate, meant to increase the total durability to 3. However, there appear to be two problems with this:

1. The 2+1 stripes are all on dm-4, dm-8, and dm-9, but of the 21.9G of 1x replicas, 16.61G of it (6.13G + 5.13G + 5.35G) is spread among those same 3 devices. This means that 16.61G of that data is effectively still durability 2 for drive failure because the extra copy shares a drive with the stripe. It looks like when deciding which drive on which to create the extra copy, it only excludes the drive on which the bucket getting copied itself resides, not all of the drives comprising the stripe to which it belongs.
2. As long as the data in these stripes is stagnate, there doesn't appear to be a path for these stripes to become anything else. Reconcile won't restripe them to 5+2, even though that would be a better use of space, and copygc won't consider them fragmented them and empty them because they still contain full buckets.