[systemd-devel] consider dropping defrag of journals on btrfs
Vito Caputo
vcaputo at pengaru.com
Thu Feb 11 18:28:21 UTC 2021
On Thu, Feb 11, 2021 at 09:19:07AM -0500, Phillip Susi wrote:
>
> Phillip Susi writes:
>
> > Wait, what do you mean the inode nr changes? I thought the whole point
> > of the block donating thing was that you get a contiguous set of blocks
> > in the new file, then transfer those blocks back to the old inode so
> > that the inode number and timestamps of the file don't change.
>
> I just tested this with e4defrag and the inode nr does not change.
> Oddly, it refused to improve my archived journals which had 12-15
> fragments. I finally found /var/log/btmp.1 which despite being less
> than 8mb had several hundred fragments. e4defrag got it down to 1
> fragment, but for some reason, it is still described by 3 separate
> entries in the extent tree.
>
> Looking at the archived journals though, I wonder why am I seeing so
> many unwritten areas? Just the last extent of this file has nearly 4 mb
> that were never written to. This system has never had an unexpected
> shutdown. Attached is the extent map.
>
<snip>
The mid-journal unwritten areas are likely entry arrays. They grow
exponentially and get filled in as more entries are appended
containing their respective objects. If you're unfamiliar with the
format, there's a chain of entry arrays constructed per recurring data
object.
At the end of the journal, it's currently expected to find some
unwritten space due to the 8MiB fallocate. A future version will
likely truncate this off while archiving.
I added a journal object layout introspection feature to jio [0],
which might be interesting for you to correlate the extent list with
the application-level object list.
You can access the feature by running `jio report layout`, it will
produce a .layout file in the cwd for every journal it opened. Here's
a sample:
---8<-------8<-------8<-------8<----
Layout for "user-1000.journal"
Legend:
? OBJECT_UNUSED
d OBJECT_DATA
f OBJECT_FIELD
e OBJECT_ENTRY
D OBJECT_DATA_HASH_TABLE
F OBJECT_FIELD_HASH_TABLE
A OBJECT_ENTRY_ARRAY
t OBJECT_TAG
|N| object spans N page boundaries (page size used=4096)
| single page boundary
+N N bytes of alignment padding
+ single byte of alignment padding
F|5344 D|448|1834896 d81+7 f50+6 d74+6 f48 d82+6 f55+ d84+4 f57+7 d79+ f50+6 d104 f47+ d73+7 f44+4 d73+7 f44+4 d73+7 f44+4 d72 f45+3 d76+4 f44+4 d75+5 f48 d90+6 f54+2 d80 f54+2 d84+4 f55+ d123+5 f55+ d82+6 f56 d87+ f58+6 d93+3 f53+3 d|94+2 f54+2 d91+5 f59+5 d119+ f62+2 d107+5 f66+6 d105+7 f48 d108+4 f51+5 d82+6 f49+7 e480 A56 d97+7 d107+5 e480 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 A56 d142+2 d70+2 d107+5 e|480 d74+6 d148+4 d107+5 e480 A56 d78+2 d122+6 d72 d107+5 e480 A88 d79+ d73+7 d107+5 e480 A88 A88 A88 A56 A88 A88 A88 A88 A88 A88 A88 A88 A|88 A88 A88 A88 A88 A88 A88 A88 A88 d97+7 d107+5 e480 A88 A56 A56 d107+5 e480 A56 d107+5 e480 A56 A56 d107+5 e480 A88 A56
---8<-------8<-------8<-------8<----
Regards,
Vito Caputo
[0] git://git.pengaru.com/jio (clone recursively w/--recursive)
More information about the systemd-devel
mailing list