Hi,
This is on a Fedora 26 workstation (systemd-233-3.fc26.x86_64) that's
maybe a couple weeks old and was clean installed. Drive is NVMe.
# filefrag *
system.journal: 9283 extents found
user-1000.journal: 3437 extents found
# lsattr
C-- ./system.journal
C-- ./user-1000.journal
I do manual snapshots before software updates, which means new writes
to these files are subject to COW, but additional writes to the same
extents are overwrites and are not COW because of chattr +C. I've used
this same strategy for a long time, since systemd-journald defaults to
+C for journal files; but I've not seen them get this fragmented this
quickly.
Meanwhile on a Fedora 25 Server, which has systemd-231-14.fc25.x86_64,
and SD Card based, I've made a modification where /var/log is a nested
subvolume so that when I snapshot the root subvolume, the contents of
/var/log are not snapshot, therefore these files should always be
no-COW, and yet they too are rather fragmented.
# filefrag *
system@00054c130c57bb79-5df6c2871d1edf1e.journal~: 1 extent found
system@00054cb3cd18d71b-6a815220d62cc6ea.journal~: 1 extent found
system@01b44589014542e3b48df31f152c0916-0001-000542e1fb4550e7.journal:
1 extent found
system@01b44589014542e3b48df31f152c0916-ca2b-00054546539416e8.journal:
1 extent found
system@01b44589014542e3b48df31f152c0916-000198f3-000547aac217c85b.journal:
1 extent found
system.journal: 2992 extents found
user-1000@00054c130a314ee9-4bb9fd0a9268dc1c.journal~: 1 extent found
user-1000@ac4b2e5ded7d4e0dbcac6fc45430c857-05a9-000542e1fe209094.journal:
1 extent found
user-1000@ac4b2e5ded7d4e0dbcac6fc45430c857-cafe-0005454b13a0349f.journal:
1 extent found
user-1000@ac4b2e5ded7d4e0dbcac6fc45430c857-0001abe0-0005482397f286a5.journal:
1 extent found
user-1000.journal: 405 extents found
There are many 4096 byte extents is what's going on. Maybe this is a
consequence of frequent fsync?
On the plus side, even a 'reboot -f' or forced power off, and I get
pretty much everything within the last few seconds in the journal on
the next boot. That's pretty good. Maybe to do better is too much
hassle - like no fsyncing on Btrfs and just let its normal 30s commit
time apply; if things start crashing then journald could start
fsyncing... some sort of dynamic trigger.
There could be 8000 things higher priority than this though, this isn't broken.
Output from
# filefrag -v system.journal
# btrfs-debugfs -f system.journal
https://drive.google.com/open?id=0B_2Asp8DGjJ9UEdyVFRfU0c2V2s
--
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
