systemd-journald journals on Btrfs default to nodatacow, upon log rotation it's submitted for defragmenting with BTRFS_IOC_DEFRAG. The result looks curious. I can't tell what the logic is from the results.
The journal file starts out being fallocated with a size of 8MB, and as it grows there is an append of 8MB increments, also fallocated. This leads to a filefrag -v that looks like this (ext4 and btrfs nodatacow follow the same behavior, both are provided for reference): ext4 https://pastebin.com/6vuufwXt btrfs https://pastebin.com/Y18B2m4h Following defragment with BTRFS_IOC_DEFRAG it looks like this: https://pastebin.com/1ufErVMs It appears at first glance to be significantly more fragmented. Closer inspection shows that most of the extents weren't relocated. But what's up with the peculiar interleaving? Is this an improvement over the original allocation? https://pastebin.com/1ufErVMs If I unwind the interleaving, it looks like all the extents fall into two localities and within each locality the extents aren't that far apart - so my guess is that this file is also not meaningfully fragmented, in practice. Surely the drive firmware will reorder the reads to arrive at the least amount of seeks? -- Chris Murphy
