On Sun, Jan 24, 2016 at 1:22 PM, Chris Murphy <lists@colorremedies.com> wrote: You can end up in a situation where the file system
first becomes nearly full (no unallocated space for a chunk to be created), but via file deletion it can seem there's plenty of unused space, but only for one type of chunk. The typical case is when data chunks have free space, but metadata chunks don't.
A better qualification is to say "when people have bad disk full Btrfs experiences" the typical case is because data chunks have free space but metadata chunks don't. If metadata chunks are completely full, and there's no unallocated space to create more metadata chunks, the file system will ENOSPC and some really unpredictable things can happen including inability to delete files. OK so today, the opposite happened to me. Data chunks became totally full, but there was still unused space in metadata chunks. Result? Graceful failure and I could easily delete some files and didn't even have to reboot. What happened was an intentionally misconfigured VM went a bit crazy, overfilled some qcow2 files on the host, and then this: [root@f23m images]# btrfs fi usage / Overall: Device size: 56.00GiB Device allocated: 56.00GiB Device unallocated: 1.00MiB Device missing: 0.00B Used: 55.33GiB Free (estimated): 1.22MiB (min: 1.22MiB) Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 128.00MiB (used: 0.00B) Data,single: Size:54.97GiB, Used:54.97GiB /dev/sda7 54.97GiB Metadata,single: Size:1.00GiB, Used:370.31MiB /dev/sda7 1.00GiB System,single: Size:32.00MiB, Used:16.00KiB /dev/sda7 32.00MiB Unallocated: /dev/sda7 1.00MiB And of course (regular) df says it's 100% full, which is more true than not. But see there's 700MiB unused in metadata chunks. So it was not a problem for the file system to delete some big qcow2 files and continue on without further problems. It may be this is really common because it's so graceful, no one would complain about it. Some time later however: [root@f23m images]# btrfs fi usage / Overall: Device size: 56.00GiB Device allocated: 52.97GiB Device unallocated: 3.03GiB Device missing: 0.00B Used: 22.45GiB Free (estimated): 32.87GiB (min: 32.87GiB) Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 128.00MiB (used: 0.00B) Data,single: Size:51.94GiB, Used:22.10GiB /dev/sda7 51.94GiB Metadata,single: Size:1.00GiB, Used:358.73MiB /dev/sda7 1.00GiB System,single: Size:32.00MiB, Used:16.00KiB /dev/sda7 32.00MiB Unallocated: /dev/sda7 3.03GiB A lot of "free" space is not unallocated. Those are data chunks only, and they aren't reverting back to unallocated. Only 3GiB of unallocated is available for becoming metadata chunks. So if I were to do a bunch of small file writes, very metadata intensive writing, it's possible I'll end up in the originally described situation: Plenty of unused space in data chunks, but full metadata chunks and no more unallocated space to create more metadata chunks. That's asking for what I call a "wedged into a corner" file system. There is almost always a way out though, which is to 'btrfs device add /dev/sdXY /" by just pointing this to a small USB stick or partition on it, it can be just enough unallocated space for a metadata chunk, now files can be deleted and the fs can be balanced with a -dusage=15 limit, and then the stick removed 'btrfs dev del /dev/sdXY /" and any little bit of data or metadata that's since been put on the stick will get moved back to the original/big partition. Done. But for now I'm going to pre-empt that: [root@f23m images]# btrfs balance start -dusage=15 / Done, had to relocate 25 out of 54 chunks This took about 20 seconds on an SSD. And now: [root@f23m images]# btrfs fi usage / Overall: Device size: 56.00GiB Device allocated: 29.03GiB Device unallocated: 26.97GiB Device missing: 0.00B Used: 22.45GiB Free (estimated): 32.87GiB (min: 32.87GiB) Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 128.00MiB (used: 0.00B) Data,single: Size:28.00GiB, Used:22.10GiB /dev/sda7 28.00GiB Metadata,single: Size:1.00GiB, Used:358.55MiB /dev/sda7 1.00GiB System,single: Size:32.00MiB, Used:16.00KiB /dev/sda7 32.00MiB Unallocated: /dev/sda7 26.97GiB That's much better. There's now only 6GiB unused data chunks, and there's no point doing a more aggressive balance for that anyway. I could even have done -dusage=5 or 10 and any future concern would be gone. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org