I hit an issue with btrfs compression; I reported it to Debian, which I was using, and they suggested that I take it upstream.
Thanks, Salvatore. My apologies to everyone if I misunderstood. -James On Tue, Sep 23, 2025 at 1:50 PM Salvatore Bonaccorso <[email protected]> wrote: > > Control: tags -1 + moreinfo > > Hi James, > > On Tue, Sep 23, 2025 at 08:04:25PM +0200, James Young wrote: > > Package: src:linux > > Version: 6.1.129-1 > > Severity: normal > > X-Debbugs-Cc: [email protected] > > > > Dear Maintainer, > > > > > > * What led up to the situation? > > We made empty files in a loop, in parallel, under CPU and I/O load. > > We had an outer Btrfs image file with compression, which contained a Btrfs > > image file, which contained billions of empty files. > > We wrote around 100TB to the inner image file. > > Around 60TB in, compression quietly shut off. > > We ran out of space; both mounts presented i/o errors. > > > > * What exactly did you do (or not do) that was effective (or ineffective)? > > * I unmounted the inner and outer images. > > I didn't take note of memory usage before this point. > > * dump debug info for the outer image - `btrfs inspect-internal dump-tree > > --dfs ...` > > * We started a btrfsck. (twice, actually; breadth-first hit memory > > limits, I think) > > After that, I learned about `btrfs check`, but didn't interrupt the > > btrfsck, due to Sunk Cost Fallacy. > > The btrfsck is still running. It's of extremely dubious value now. > > * check the kernel logs > > * I grepped for btrfs, the mount points, compress, and zstd. I didn’t > > find a smoking gun in the right timeframe. > > > > not done yet: > > * mount the outer image > > * rebooted > > * tried a newer kernel. we're currently on kernel 6.1.129; we could go to > > newer 6.1 or 6.12 kernels > > * redo live file system compression, with e.g. `btrfs filesystem defrag > > -czstd` > > * fstrim the outer image > > > > goals: > > * work out what happened. > > How can we help? > > * help avoid it happening again, to others > > * salvage what we can > > > > I've run `bugreport` as a non-privileged user. Let me know if root access > > would give a fuller picture. > > I believe the best thing you could do here is to contact actually > upstream people directly. get_maintainers and the MAINTAINERS file > has: > > BTRFS FILE SYSTEM > M: Chris Mason <[email protected]> > M: Josef Bacik <[email protected]> > M: David Sterba <[email protected]> > L: [email protected] > S: Maintained > W: https://btrfs.readthedocs.io > Q: https://patchwork.kernel.org/project/linux-btrfs/list/ > C: irc://irc.libera.chat/btrfs > T: git git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git > F: Documentation/filesystems/btrfs.rst > F: fs/btrfs/ > F: include/linux/btrfs* > F: include/trace/events/btrfs.h > F: include/uapi/linux/btrfs* > > So I would suggest you to contact above maintainers including the > list. > > Please keep this downstream bugreport as well in the recipients list. > > Regards, > Salvatore
