On Mon, 17.04.17 13:49, Chris Murphy (li...@colorremedies.com) wrote: > 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.
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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
