Re: btrfs thinks fs is full, though 11GB should be still free

[Christoph Anton Mitterer <calestyo@scientia.org>]

Hey.

Had already sent the mail below this afternoon, but just got a bounce:
<linux-btrfs@vger.kernel.org>: lost connection with
    smtp.subspace.kernel.org[44.238.234.78] while receiving the initial server
    greeting


So here it's again,... effectively it just says that autodefrag didn't
help either.

Cheers,
Chris.


On Tue, 2023-12-12 at 14:43 +1030, Qu Wenruo wrote:
> The direct cause is frequent fsync()/sync() with overwrites.
> Btrfs is really relying on merging the writes between transactions,
> if
> fsync()/sync() is called too frequently (like some data base) and the
> program is doing overwrites, this is exactly what you would have.
> 
> IIRC we can set the AUTODEFRAG for an directory?

I have tried meanwhile with autodefrag for a few days, but that doesn't
cure the problem, not sure why it doesn't seem to kick in.


The way Prometheus writes together with btrfs, causes extensive loss of
space:
compsize /data/main/prometheus/metrics2
Processed 305 files, 567 regular extents (586 refs), 146 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL      100%       21G          21G          13G       
none       100%       21G          21G          13G       


I'll try with a manual defrag now, but it's a bit unfortunate that this
happens without manual intervention.
Or would it be better or even help to balance?


And nodatacow isn't IMO a real alternative either, as long as one
looses one of the greatest btrfs benefits with is (checksumming).


Cheers,
Chris.