[systemd-devel] Slow startup of systemd-journal on BTRFS

Duncan 1i5t5.duncan at cox.net
Tue Jun 17 19:03:23 PDT 2014


Kai Krakow posted on Tue, 17 Jun 2014 23:02:14 +0200 as excerpted:

>  I'm pretty sure it really
> doesn't matter if your 500G image file is split across 10000 extents -
> as long as at least chunks of extents are kept together and rebuilt as
> one extent.

It's worth noting that in btrfs terms, "chunk" has a specific meaning.  
Btrfs allocates "chunks" from free space, 1 GiB at a time for data 
chunks, 256 MiB at a time for metadata.[1]  And that btrfs-specific 
meaning does tend to distort your example case, somewhat, tho I expect 
most folks understand what you mean.  The problem is that we're running 
out of generic terms that mean "chunk-like" and are thus experiencing 
namespace collision!

Anyway, btrfs chunks, data chunks being of interest here, get allocated 
on demand.  The practical effect is thus that the maximum btrfs extent 
size is 1 GiB.  As such, the least-extents-possible ideal for that 500 
GiB image file would be 500 extents.

> That means, instead of letting autodefrag work on the whole
> file just let it operate on a chunk of it within some sane boundaries -
> maybe 8MB chunks, - of course without splitting existing extents if
> those already cross a chunk boundary.

As stated, "chunk" has a special meaning in btrfs.  Data chunks are 1 GiB 
in size and no extent can cross a btrfs chunk boundary.

> BTW: Is it possible to physically relocate files in btrfs?

Currently, ENOTIMPLEMENTED.  AFAIK it's possible and is on the list, but 
so are a number of other "nice-to-haves", so it might be awhile.  
Actually just checked the wiki.  The closest specific feature point 
listed says "hot-data-tracking and moving to faster devices", noting that 
there's actually some current work on the generic (not-btrfs-specific) 
feature, to be made available via VFS.  Your specific use-case will 
probably be part of that general implementation.

---
[1] Btrfs chunk allocation: 1 GiB data chunks size, 256 MiB metadata 
chunk size by default, but there are various exceptions.  The first of 
course is when space gets tight.  The last allocation will be whatever is 
left.  Second, there's mixed-data/metadata mode, the default when the 
filesystem is <= 1 GiB.  Mixed chunks are (like metadata) 256 MiB but 
contain data and metadata mixed, sacrificing speed efficiency for more 
efficient space management.  Third, it's worth noting that the single-
device-btrfs default is dup-mode-metadata (with the same default for 
mixed-mode), so while they're 256 MiB each, two get allocated at once, 
thus allocating metadata half a GiB at a time.  Multi-device-btrfs 
metadata defaults to raid1-mode, still allocated in chunk pairs but one 
on each of two separate devices.  Data mode always defaults to single, 
tho on multi-device-btrfs both data and metadata can be (individually) 
set to various raid modes, each with its own specific allocation pattern.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman



More information about the systemd-devel mailing list