Henk Slager posted on Mon, 11 Jan 2016 21:29:37 +0100 as excerpted: > The Data increments with 1G (or 10G?) chunks if there is no well-fitting > space in existing chunks. One of the devs (Qu?) explained this rather well in a followup to something or other, probably about a week or two ago. I remember replying to the effect of how much more I knew of the exact numbers at the time. Based on that, nominal data chunk size is 1 GiB, on btrfs upto 100 GiB in size (tho real small ones will have smaller data chunk sizes as well, not sure of the small end numbers, tho when mixed-mode was introduced until progs 4.3(.1 I think), mixed-mode was the default below 1 GiB size, and it uses metadata sized chunks). Above 100 GiB, data chunk size increases to 10 GiB. Similarly, metadata chunk sizes are 256 MiB below 100 GiB, I think 1 GiB above. As we're talking multi-TB in this case, obviously well above 100 GiB, data chunk sizes are likely to be 10 GiB, tho I'm not 100% sure if that applies on single device, or only to striped chunks, with 1 GiB strips and stripes of up to 10 GiB if there's 10 devices in the stripe. (As regulars here will know if they've kept track, I use multiple, much smaller btrfs here, the largest of which is 24 GiB per device, pair- device raid1 for both data/metadata, so 48 GiB total fs size, 24 GiB each on two devices in raid1, 24 GiB capacity. Obviously I see only 1 GiB data chunks, smaller of course on my 256 MiB /boot and its backup on the other device, both of which are single-device mixed-mode dup, so 128 MiB capacity.) -- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
