17.04.2017 22:49, Chris Murphy пишет: > On Mon, Apr 17, 2017 at 11:27 AM, Andrei Borzenkov <arvidj...@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. > > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
