Chris Murphy - 29.01.20, 23:55:06 CET: > On Wed, Jan 29, 2020 at 2:20 PM Martin Steigerwald <martin@xxxxxxxxxxxx> wrote: > > So if its just a cosmetic issue then I can wait for the patch to > > land in linux-stable. Or does it still need testing? > > I'm not seeing it in linux-next. A reasonable short term work around > is mount option 'metadata_ratio=1' and that's what needs more testing, > because it seems decently likely mortal users will need an easy work > around until a fix gets backported to stable. And that's gonna be a > while, me thinks. > > Is that mount option sufficient? Or does it take a filtered balance? > What's the most minimal balance needed? I'm hoping -dlimit=1 Does not make a difference. I did: - mount -o remount,metadata_ratio=1 /daten - touch /daten/somefile - dd if=/dev/zero of=/daten/someotherfile bs=1M count=500 - sync - df still reporting zero space free > I can't figure out a way to trigger this though, otherwise I'd be > doing more testing. Sure. I am doing the balance -dlimit=1 thing next. With metadata_ratio=0 again. % btrfs balance start -dlimit=1 /daten Done, had to relocate 1 out of 312 chunks % LANG=en df -hT /daten Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/sata-daten btrfs 400G 311G 0 100% /daten Okay, doing with metadata_ratio=1: % mount -o remount,metadata_ratio=1 /daten % btrfs balance start -dlimit=1 /daten Done, had to relocate 1 out of 312 chunks % LANG=en df -hT /daten Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/sata-daten btrfs 400G 311G 0 100% /daten Okay, other suggestions? I'd like to avoid shuffling 311 GiB data around using a full balance. Thanks, -- Martin
