[systemd-devel] journal fragmentation on Btrfs

[Andrei Borzenkov]

17.04.2017 22:49, Chris Murphy пишет:
> 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.
> 


What exactly "changes" mean? Write() syscall?

> #Storage=auto
> #Compress=yes
> #Seal=yes
> #SplitMode=uid
> #SyncIntervalSec=5m

This controls how often systemd calls fsync() on currently active
journal file. Do you see fsync() every 3 seconds?

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