On 2020-02-01 4:17 p.m., Matt Zagrabelny wrote:
>
> I've also tried resizing the disks smaller and then larger - I found a
> (perhaps misleading) post on an online forum suggesting such things to
> retrieve space.
>
> I have no idea how to proceed to fix things.
>
As Qu said, a known bug. However, this mostly just affects the display
of df.. if you use the btrfs filesystem usage command, you'll see the
the true free space.
Sometimes, there are processes which check free space before trying to
write data, and those will fail if you trigger this condition. Zygo
posted great script to this list a few days ago that will get you past
this by force allocating metadata space on the filesystem.
His script looks like this:
btrfs sub create sub_tmp
mkdir sub_tmp/single
head -c 2047 /dev/urandom > sub_tmp/single/inline_file
for x in $(seq 1 18); do
cp -a sub_tmp/single sub_tmp/double
mv sub_tmp/double sub_tmp/single/$x
done
sync
btrfs sub del sub_tmp
Note, Until this is properly patched, do not balance metadata. doing so
will actually bring you to this problem, rather than fixing it.
Attachment:
signature.asc
Description: OpenPGP digital signature
