Re: Btrfs autodefrag wrote 5TB in one day to a 0.5TB SSD without a measurable benefit

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

On Mon, Mar 14, 2022 at 06:24:43PM -0400, Remi Gauvin wrote:
> On 2022-03-14 5:53 p.m., Jan Ziak wrote:
> 
> 
> > ....
> > 
> > In this test case, "Disk Usage" is 60% higher than the file's size:
> > 
> > $ compsize data
> > Processed 1 file, 612 regular extents (1221 refs), 0 inline.
> > Type       Perc     Disk Usage   Uncompressed Referenced
> > TOTAL      100%       16M          16M          10M
> 
> 
> It would be nice if we could get a mount option to specify maximum
> extent size, so this effect could be minimized on SSD without having to
> use compress-force.  (Or maybe this should be the default When ssd mode
> is automaticallyd detected.)

If you never use prealloc or defrag, it's usually not a problem.

Files mostly fall into two categories:  big sequential writes (where
big extents are better) or small random writes (where big extents are
bad, but you don't have any of those because you're doing small random
writes all the time).  Writeback gets this right most of the time,
so the extents end up the right sizes on disk.

If all your writes are random, short, and aligned to a multiple of 4K,
then you'll end up in a steady state with a lot of short extents and
little to no wasted space.  If you run defrag on that, you end up with
half the space wasted, and if the writes continue, lots of small extents
either way.

Prealloc's bad effects are similar to defrag, but with more reliable
losses.

A mount option to disable prealloc globally might be very useful--I
run a number of apps that think prealloc doesn't waste huge amounts of
CPU time and disk space on datacow files, and I grow weary of patching
or LD_PRELOAD-hacking them all the time to not call fallocate().