Re: consider dropping defrag of journals on btrfs

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 05.01.21 10:04, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote:

> f27a386430cc7a27ebd06899d93310fb3bd4cee7
>     journald: whenever we rotate a file, btrfs defrag it
>
> Since systemd-journald sets nodatacow on /var/log/journal the journals
> don't really fragment much. I typically see 2-4 extents for the life
> of the journal, depending on how many times it's grown, in what looks
> like 8MiB increments. The defragment isn't really going to make any
> improvement on that, at least not worth submitting it for additional
> writes on SSD. While laptop and desktop SSD/NVMe can handle such a
> small amount of extra writes with no meaningful impact to wear, it
> probably does have an impact on much more low end flash like USB
> sticks, eMMC, and SD Cards. So I figure, let's just drop the
> defragmentation step entirely.

Quite frankly, given how iops-expensive btrfs is, one probably
shouldn't choose btrfs for such small devices anyway. It's really not
where btrfs shines, last time I looked.

> Further, since they are nodatacow, they can't be submitted for
> compression. There was a quasi-bug in Btrfs, now fixed, where
> nodatacow files submitted for decompression were compressed. So we no
> longer get that unintended benefit. This strengthens the case to just
> drop the defragment step upon rotation, no other changes.
>
> What do you think?

Did you actually check the iops this generates?

Not sure it's worth doing these kind of optimizations without any hard
data how expensive this really is. It would be premature.

That said, if there's actual reason to optimize the iops here then we
could make this smart: there's actually an API for querying
fragmentation: we could defrag only if we notice the fragmentation is
really too high.

But quite frankly, this sounds polishing things after the horse
already left the stable: if you want to optimize iops, then don't use
btrfs. If you bought into btrfs, then apparently you are OK with the
extra iops it generates, hence also the defrag costs.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel