Bug#1116067: linux-image-6.1.0-32-amd64: btrfs compression quietly stopped around 60TB in
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: pronoiac@gmail.com
>
> 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 <clm@fb.com>
M: Josef Bacik <josef@toxicpanda.com>
M: David Sterba <dsterba@suse.com>
L: linux-btrfs@vger.kernel.org
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
Reply to: