[systemd-devel] Slow startup of systemd-journal on BTRFS

[Kai Krakow]

Andrey Borzenkov <arvidjaar at gmail.com> schrieb:

>> journald's write pattern looks something like this: append something to
>> the end, make sure it is written, then update a few offsets stored at
>> the beginning of the file to point to the newly appended data. This is
>> of course not easy to handle for COW file systems. But then again, it's
>> probably not too different from access patterns of other database or
>> database-like engines...
>>
> 
> ... which traditionally experienced severe sequential read performance
> degradation in this case. As I understand this is exactly what happens
> - readahead attempts to preload files which gives us heavy random read
> access.
> 
> The only real remedy was to defragment files. It should work
> relatively well for journal where files are mostly "write once" at the
> expense of additional read/write activity.

This is an interesting point because it means: Readahead may hurt systemd 
boot performance a lot if it is hitting a heavily fragmented file like those 
affected journal files.

So, readahead should probably ignore these files? It may look obvious but I 
don't think so...

On my system, readahead will process system.journal and thus defragment it, 
so it won't fragment too much and by that won't slow the boot down. This may 
also explain why in Goffredo's tests the readahead process never got into 
recording the system.journal - because the boot process was finished 
(readahead-done) before any process started reading system.journal - but 
still the high fragmentation of the other journals causes very high IO and 
the boot process becomes slower and slower.

The root fix should be to make journald not causing high fragmentation. But 
I think Andrey's point should be given some thoughts, too.

-- 
Replies to list only preferred.