Re: consider dropping defrag of journals on btrfs

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 05.02.21 10:24, Phillip Susi (phill@xxxxxxxxxxxx) wrote:

>
> Lennart Poettering writes:
>
> > You are focussing only on the one-time iops generated during archival,
> > and are ignoring the extra latency during access that fragmented files
> > cost. Show me that the iops reduction during the one-time operation
> > matters and the extra latency during access doesn't matter and we can
> > look into making changes. But without anything resembling any form of
> > profiling we are just blind people in the fog...
>
> I'm curious why you seem to think that latency accessing old logs is so
> important.  I would think that old logs tend to be accessed very
> rarely.  On such a rare occasion, a few extra mS doesn't seem very
> important to me.  Even if it's on a 5400 rpm drive, typical latency is
> what?  8 mS?  Even with a fragment every 8 MB, that's only going to add
> up to an extra 128 mS to read and parse a 128 MB log file.  Even with no
> fragments it's going to take over 1 second to read that file, so we're
> only talking about a ~11% slow down here, on an operation that is rare
> and you're going to be spending far more time actually looking at the
> log than it took to read off the disk.

journalctl gives you one long continues log stream, joining everything
available, archived or not into one big interleaved stream.

Lennart

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