On Mon, Jan 13, 2020 at 4:38 PM Christian Kujau <lists@xxxxxxxxxxxxxxx> wrote: > > On Mon, 13 Jan 2020, Chris Murphy wrote: > > > Well, I received some ENOSPC notifications from various apps, so it was a > > > real problem. > > > > Oh it's a real problem and a real bug. But the file system itself is OK. > > Ah, OK. Good to know. > > > > For now, the balancing "helped", but the fs still shows only 391 GB > > > allocated from the 924 GB device: > > The first "balance start --full-balance /" finshed, with the following > message, of course: > > ERROR: error during balancing '/': No space left on device > > But afterwards at least "df" was happy and reported 48% usage again. While > writing the last email I started another "balance start --full-balance /" > to balance the extents that could not be balanced before because the file > system was at 100%. But this failed with the same message and now I'm back > to square one: That's why I suggesting cancelling the balance. > > ============================================================= > # btrfs filesystem df -h / > Data, single: total=391.00GiB, used=386.38GiB > System, single: total=32.00MiB, used=80.00KiB > Metadata, single: total=2.00GiB, used=1.55GiB > GlobalReserve, single: total=512.00MiB, used=0.00B > > # df -h / > Filesystem Size Used Avail Use% Mounted on > /dev/mapper/luks-root 825G 389G 0 100% / > ============================================================= > > Sigh. I can't reboot right now, will do later on and will try another > balance now. While it won't make things worse, it won't make it better either. Use mount option metadata_ratio=1 instead; man 5 btrfs if you want to know more about it's doing. The bug is a consequence of a series of older bugs that got exposed in 5.4 with a change in how metadata is overcommitted, so now all those older bugs will get fixed, but in the meantime the problem is more likely triggered if you have recently balanced metadata block groups. -- Chris Murphy
