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