Re: repeated enospc errors during balance on a filesystem with spare room - pls advise

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]

On Tue, Dec 31, 2019 at 04:10:40PM +0100, Ole Langbehn wrote:
> Excuse me for adding more information in a second mail:
> 
> # uname -a
> Linux leo 5.4.6-gentoo #1 SMP PREEMPT Sun Dec 22 10:27:05 CET 2019

That is the most likely problem.  A fix for 5.4's zero-free-space issue
is still being reviewed on the mailing list.

On btrfs you can run out of space as often as you like, it won't hurt
data on the filesystem.  A lot of applications are not so robust, though,
so you may encounter problems with embedded databases and configuration
data.  The current 5.4 bug just makes the kernel think there is 0 free
space, it has nothing to do with the filesystem on disk.

Two workarounds:

	- use 5.3.18 instead of 5.4.6

	- use the 'metadata_ratio=1' mount option after balancing a few
	data block groups

In your other mail you indicated you were running a full balance.  Full
balances are never useful(*) and will make this specific situation worse.

A full balance includes a metadata balance.  The primary effect
of metadata balance is to temporarily reduce space for metadata.
Reducing metadata space causes an assortment of problems for btrfs,
only one of which is hitting the 5.4 free space bug.  For all but a few
contrived test cases, btrfs manages metadata well without interference
from balance.  Too much metadata balancing (i.e. any at all) can make
a filesystem truly run out of metadata space on disk--a condition that
is sometimes difficult to reverse.

You should run data balances to temporarily reduce space available
for data.  This will allow btrfs to use more space for metadata,
which will avoid the bad things that happen when metadata runs out.
This will also compact free space areas into large contiguous areas for
future data allocations, which will improve fragmentation and may make
the filesystem run a little faster.

In your specific case, you probably have to do the first few block groups
of data balance on a 5.3 kernel until you have enough unallocated space
to make new metadata block groups.

Going forward, run something like 'btrfs balance start -dlimit=9' every
day (adjust the limit upwards if you write more than 10GB of data per
day, downwards if you write less).  Or use 'btrfs fi usage' and make
sure that the 'unallocated' space stays above a few GB at all times,
and run data balance with larger limits if it's not.

(*) A full balance contains a metadata balance, and you should never
balance metadata except to convert from one RAID profile to another.
Older kernels have bugs that lead to overallocation of metadata, but it
is better to upgrade than to continue using the old kernels with metadata
balances.  There are some obscure corner test cases where a metadata
balance is useful, but users will not encounter these by accident.

> x86_64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz GenuineIntel GNU/Linux
> 
> # btrfs --version
> btrfs-progs v5.4
> 




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]