Re: consider dropping defrag of journals on btrfs

[Vito Caputo <vcaputo@xxxxxxxxxxx>]

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)
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel