
| Msg # 118 of 1332 on ZZLI4424, Thursday 9-24-25, 1:05 |
| From: SALVATORE BONACCORSO |
| To: JAMES YOUNG |
| Subj: Bug#1116067: linux-image-6.1.0-32-amd64: |
XPost: linux.debian.bugs.dist From: carnil@debian.org 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 |
328,121 visits
(c) 1994, bbs@darkrealms.ca