[systemd-devel] consider dropping defrag of journals on btrfs

[Chris Murphy]

More data points.

1.
An ext4 file system with a 112M system.journal, it has 15 extents.
>From FIEMAP we can pretty much see it's really made from 14 8MB
extents, consistent with multiple appends. And it's the exact same
behavior seen on Btrfs with nodatacow journals.

https://pastebin.com/6vuufwXt

2.
A Btrfs file system with a 24MB system.journal, nodatacow, 4 extents.
The fragments are consistent with #1 as a result of nodatacow
journals.

https://pastebin.com/Y18B2m4h

3.
Continuing from #2, 'journalctl --rotate'

strace shows this results in:
ioctl(31, BTRFS_IOC_DEFRAG)             = 0

filefrag shows the result, 17 extents. But this is misleading because
9 of them are in the same position as before, so it seems to be a
minimalist defragment. Btrfs did what was requested but with both
limited impact and efficacy, at least on nodatacow files having
minimal fragmentation to begin with.
https://pastebin.com/1ufErVMs

4.
Continuing from #3, 'btrfs fi defrag -l 32M' pointed to this same file
results in a single extent file.

strace shows this uses
ioctl(3, BTRFS_IOC_DEFRAG_RANGE, {start=0, len=33554432, flags=0,
extent_thresh=33554432, compress_type=BTRFS_COMPRESS_NONE}) = 0

and filefrag shows the single extent mapping:
https://pastebin.com/429fZmNB

While this is a numeric improvement (no fragmentation), again there's
no proven advantage of defragmenting nodatacow journals on Btrfs. It's
just needlessly contributing to write amplification.

--

The original commit description only mentions COW, it doesn't mention
being predicated on nodatacow. In effect commit
f27a386430cc7a27ebd06899d93310fb3bd4cee7 is obviated by commit
3a92e4ba470611ceec6693640b05eb248d62e32d four months later. I don't
think they were ever intended to be used together, and combining them
seems accidental.

Defragmenting datacow files makes some sense on rotating media. But
that's the exception, not the rule.

--
Chris Murphy