home  bbs  files  messages ]

      ZZLI4424             linux.debian.kernel             1332 messages      

[ previous | next | reply ]

[ list messages | list forums ]

  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  
 M:      Josef Bacik  
 M:      David Sterba  
 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 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2) 

[ list messages | list forums | previous | next | reply ]

search for:

328,121 visits
(c) 1994,  bbs@darkrealms.ca