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

[Kai Krakow]

Chris Murphy <lists at colorremedies.com> schrieb:

>> It's not a mmap problem, it's a small writes with an msync or fsync
>> after each one problem.
>> 
>> For the case of sequential writes (via write or mmap), padding writes
>> to page boundaries would help, if the wasted space isn't an issue.
>> Another approach, again assuming all other writes are appends, would
>> be to periodically (but frequently enough that the pages are still in
>> cache) read a chunk of the file and write it back in-place, with or
>> without an fsync. On the other hand, if you can afford to lose some
>> logs on a crash, not fsyncing/msyncing after each write will also
>> eliminate the fragmentation.
> 
> Normally I'd be willing to give up ~30 seconds of journal to not have
> fragmented journals. But then if I use systemd.log_level=debug I'd like
> that to trigger more frequent flushing to make sure as little of the
> journaling is lost as possible. Does that make sense?

AFAIR systemd-journald already does explicit flushing when "more important" 
log entries hit the log. Well, of course "debug" is one of the least 
important log levels in that chain. But using the same code paths, it should 
be trivial to implement a configurable trigger which also forces explicit 
flushing...

-- 
Replies to list only preferred.