Open combor opened 1 week ago
The same problem occurs here, but after I upgraded kernel to the latest mainline version, the issue seems to be resolved.
I'm on latest stable 6.9.7-arch1-1 and it didnt go unfortunatelly.
I am seeing the same messages every few minutes this morning. I did updates yesterday, but I didn't upgrade my bootloader config so I'm still on an older kernel (6.8.12).
EDIT: Shutdown has hung at "unmounting filesystems", something is quite unhappy.
EDIT2: Kernel 6.9.7 is just as broken. Random stuff is just hanging, like using 'su' or starting certain applications. Not a good day :| Hung at unmounting filesystems again. I'll try a memtest next, then an older older kernel.
Problem still manifests in an older kernel (6.7.12) and I passed a memtest, so I think the filesystem itself or my NVME might be hosed.
My /home filesystem is bcachefs whilst my root filesystem is ext4. That makes me wonder how 'su' failed earlier, perhaps some shared resource?
The most important things I did yesterday were run backups (yay) and then update my distro (Voidlinux). My timing might have been good.
bcachefs fsck /dev/nvme0n1p2: Passes fine. bcachefs fsck -k /dev/nvme0n1p2: Lots of errors that it wants me to fix, see bcachefs fsck kernel.log
Could this be an issue caused by the kernel and bcachefs-tools being mismatched? Or the latter having been upgraded? I'll hop on IRC and ask for help before blindly saying yes to anything.
@ssfdust @combor Could you please report your kernel version (uname -a), tools version (run "bcachefs version") and if you are seeing similar results to me from "bcachefs fsck -k /dev/yourdisk" ?
bcachefs-tools verison 1.9.1 kernel 6.9.7_1
@SorrelArticulata
Kernel Version: 6.10.0-rc6-1-mainline
Bcachefs Tool Version: 1.9.1
In-kernel Filesystem Check Result: Error occurs, the fsck complains unreachable inode
.
Although I have reservations about the safety of running fsck on a mounted bcachefs device, the command appears to execute successfully.
Problem seems to be solved now that I've pulled and compiled the latest kernel sources from this repo (d6d793ae55897afe5871b8bf7eb3599ba25890fa). All my programs work, dmesg doesn't report anything weird, "bcachefs fsck -k" no longer claims that my filesystem is damaged and it looks like my kernel now supports version 1.9 of the disk format.
It looks like the issue might be related to having mismatched versions of bcachefs-tools and kernel (and bcachefs-tools upgrading the filesystem from v1.7 format to v1.9 format). I am glad that I didn't tell "bcachefs fsck -k" to make any fixes.
Although I have reservations about the safety of running fsck on a mounted bcachefs device, the command appears to execute successfully.
@ssfdust IIRC it used to throw that same error when I ran it on a mounted volume, even mounted ro. I think it's a limitation of the tool.
Hi, I've got a very repeatable issue with bcachefs. It happens immediately after any write attempt to the filesystem. dmesg reports:
or
steps to reproduce:
some debug info:
Any other logs I could provide to help debug? Thanks