Bug#1116067: linux-image-6.1.0-32-amd64: btrfs compression quietly stopped around 60TB in
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 <carnil@debian.org> 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: 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: