On Mon, 13 Jan 2020, Chris Murphy wrote:
> It's a reporting bug. File system is fine.
Well, I received some ENOSPC notifications from various apps, so it was a
real problem.
> > I'm running a --full-balance now and it's progressing, slowly. I've seen
> > tricks on the interwebs to temporarily add a ramdisk, run another balance,
> > remove the ramdisk again - but that seems hackish.
>
> I'd stop the balance. Balancing metadata in particular appears to make
> the problem more common. And you're right, it's hackish, it's not a
> great work around for anything these days, and if it is, good chance
> it's a bug.
For now, the balancing "helped", but the fs still shows only 391 GB
allocated from the 924 GB device:
=======================================================================
# btrfs filesystem show /
Label: 'root' uuid: 75a6d93a-5a5c-48e0-a237-007b2e812477
Total devices 1 FS bytes used 388.00GiB
devid 1 size 824.40GiB used 391.03GiB path /dev/mapper/luks-root
# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/luks-root 825G 390G 433G 48% /
=======================================================================
> In theory it should be enough to unmount then remount the file system;
> of course for sysroot that'd be a reboot.
OK, I'll try a reboot next time.
> There may be certain workloads that encourage it, that could be worked
> around temporarily using mount option metadata_ratio=1.
I'll do that after it happens again, to see if this was a one-off or
happens regularily. The file system is rather new (created Dec 14) and
apart from spinning up some libvirt VMs (but no snapshots involved) the
workload is a mix of web browsing and compiling things, no nothing too
fancy.
Thanks for your input, and thanks for taking the time to respond.
Christian.
--
BOFH excuse #69:
knot in cables caused data stream to become twisted and kinked
