Re: consider dropping defrag of journals on btrfs

[Chris Murphy <lists@xxxxxxxxxxxxxxxxx>]

On Tue, Jan 5, 2021 at 10:04 AM 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.
>
> 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?

A better idea.

Default behavior: journals are nodatacow and are not defragmented.

If '/etc/tmpfiles.d/journal-nocow.conf ` exists, do the reverse.
Journals are datacow, and files are defragmented (and compressed, if
it's enabled).


-- 
Chris Murphy
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel