[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