Thank you. That's a very helpful explanation. I've just did balance start -dconvert=single ;) Fwiw, the best explanation about "single" I could find was in the Glossary[1]. I don't have an account on the wiki, but your first paragraph would fit great there!
[1] https://btrfs.wiki.kernel.org/index.php/Glossary On 06.07.2015 19:53, Hugo Mills wrote: > On Mon, Jul 06, 2015 at 06:22:52PM +0200, Johannes Pfrang wrote: > Not quite. In single mode, the FS will allocate linear chunks of > space 1 GiB in size, and use those to write into (fitting many files > into each chunk, potentially). The chunks are allocated as needed, and > will go on the device with the most unallocated space. > > So, with equal-sized devices, the first 1 GiB will go on the first > device, the second 1 GiB on the second device, and so on. > > With unequal devices, you'll put data on the largest device, until > its free space reaches the size of the next largest, and then the > chunks will be alternated between those two, until the free space on > each of the two largest reaches the size of the third-largest, and so > on. > > (e.g. for devices sized 6 TB, 4 TB, 3 TB, the first 2 TB will go > exclusively on the first device; the next 2 TB will go on the first > two devices, alternating in 1 GB chunks; the rest goes across all > three devices, again, alternating in 1 GB chunks.) > > This is all very well for an append-only filesystem, but if you're > changing the files on the FS at all, there's no guarantee as to where > the changed extents will end up -- not even on the same device, let > alone close to the rest of the file on the platter. > > I did work out, some time ago, a prototype chunk allocator (the 1 > GiB-scale allocations) that would allow enough flexibility to control > where the next chunk to be allocated would go. However, that still > leaves the extent allocator to deal with, which is the second, and > much harder, part of the problem. > > Basically, don't assume any kind of structure to the location of > your data on the devices you have, and keep good, tested, regular > backups of anything you can't stand to lose and can't replace. There > are no guarantees that would let you assume easily that any one file > is on a single device, or that anything would survive the loss of a > device. I promise I won't assume that. Two 4TB data disks: - 3TiB+3TiB data=single,meta=raid1 replaceable/unimportant - 654Gib|654Gib data/meta=raid1 important with regular backups efficient + safe enough (for my use-case) > > I'm sure this is an FAQ entry somewhere... It's come up enough > times. > > Hugo. > >
signature.asc
Description: OpenPGP digital signature
