[systemd-devel] journal fragmentation on Btrfs

[Lennart Poettering]

On Mon, 17.04.17 13:49, Chris Murphy (lists at colorremedies.com) wrote:

> On Mon, Apr 17, 2017 at 11:27 AM, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
> > 17.04.2017 19:25, Chris Murphy пишет:
> >> This explains one system's fragmented journals; but the other system
> >> isn't snapshotting journals and I haven't figured out why they're so
> >> fragmented. No snapshots, and they are all +C at create time
> >> (systemd-journald default on Btrfs). Is it possible to prevent
> >> journald from setting +C on /var/log/journal and
> >> /var/log/journal/<machineid>? If I remove them, at next boot they get
> >> reset, so any new journals created inherit that.
> >>
> >
> > Yes, should be possible by creating empty
> > /etc/tmpfiles.d/journal-nocow.conf.
> 
> OK super.
> 
> How about inhibiting the defragmentation on rotate? I'm suspicious one
> of the things I'm seeing is due to ssd optimization mount options, but
> I need to see the predefrag state of the files.

You can't turn off the defrag-on-archive logic. But you can configure
journald to use mutch larger journal files, so that archival never
happens...

> Why do I see so many changes to the journal file, once ever 2-5
> seconds? This adds 4096 byte blocks to the file each time, and when
> cow, that'd explain why there are so many fragments.

We write to the journal files through mmap. If you see writes every
2-5 seconds then this indicates that there's something logging every 2-5s...

> 
> #Storage=auto
> #Compress=yes
> #Seal=yes
> #SplitMode=uid
> #SyncIntervalSec=5m
> #RateLimitIntervalSec=30s
> #RateLimitBurst=1000
> 
> A change every 5m is not what I'm seeing with stat. I have no crit,
> emerg, or alert messages happening. Just a bunch of drm debug messages
> which are constant. But if the flush should only happen every 5
> minutes, I'm confused.

SyncIntervalSec= configures the max time after each write that journald
will sync(). Or in other words, it means that sync() is called once
every 5min if you have a constant stream of log messages, but if you
have a long phase of no messages we'll not call it at al either.

Lennart

-- 
Lennart Poettering, Red Hat