Re: Never balance metadata?

[Martin Steigerwald <martin@lichtvoll.de>]

Andrei Borzenkov - 11.02.23, 12:42:49 CET:
> Balancing creates larger free space pool which allows large writes
> which is faster and requires less metadata. If every second 4K block
> in each chunk is free, you have exactly 50% free space like if half
> of chunks are free. But in the former case each write will be split
> into 4K pieces, each 4K becomes separate extent and needs additional
> metadata. Whether you will actually observe impact depends heavily on
> your workload.

Okay so it can save metadata size. And on a full BTRFS filesystem with no 
unallocated space it can reduce fragmentation of new writes. I get that 
much.

But what if I have for example

% btrfs filesystem usage -T /home
Overall:
    Device size:                 400.00GiB
    Device allocated:            300.02GiB
    Device unallocated:           99.98GiB
[…]
    Free (estimated):            113.60GiB      (min: 113.60GiB)
    Free (statfs, df):           113.60GiB
[…]

(metadata usage is 3.52GiB of 5.01 GiB)

on a filesystem that is heavily written to and

% btrfs filesystem usage -T /some/dir
Overall:
    Device size:                   1.20TiB
    Device allocated:              1.19TiB
    Device unallocated:            8.78GiB
[…]
    Free (estimated):             44.77GiB      (min: 44.77GiB)
    Free (statfs, df):            44.77GiB
[…]

(metadata usage is 2.88GiB of 4.01 GiB)

on a filesystem that is used mostly for the purpose of placing larger 
files there to archive them? Both are using single profiles. 

Why would I balance those? They are stored on the same 2TB NVMe SSD in 
this laptop and I did not yet see any performance related issues with 
them so far.

What I went with is this: If it is heavily written to leave enough space 
free to begin with. And if its just for storing larger files without 
receiving any regular writes by applications then I can fill it a bit 
more. Just similar to what I would do with XFS filesystem for example as 
well. Having "/home" on a 95% full XFS filesystem would not be a good 
idea either – mind you I had something like that with a BTRFS filesystem 
before and before kernel 4.5 or 4.6 actually sometimes the kernel came 
to a halt while with BTRFS searching for free space. These some times 
were related to no unallocated space free and then I balanced until next 
time it happened, but since kernel 4.5 or 4.6 this issue was gone for 
good. And before that as long as unallocated space was free it was 
working fine.

So if I plan like that, I still do not get why I would balance my 
filesystems regularly. And if I do not plan like that and let /home usage 
grow to 95% or even more… I am not sure how much "relief" balancing 
would really give to the filesystem. Is it more than the amount of work 
done during the regular balances?

Well probably that is the "depends heavily on your workload" thing you 
wrote about :)

Thanks,
-- 
Martin