[systemd-devel] journal fragmentation on Btrfs

Chris Murphy lists at colorremedies.com
Mon Apr 17 19:49:26 UTC 2017


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.

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.

#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.


-- 
Chris Murphy


More information about the systemd-devel mailing list