Brendan Hide posted on Mon, 05 May 2014 23:47:17 +0200 as excerpted: >> At the moment, we have two chunk allocation strategies: "dup" and >> "spread" (for want of a better word; not to be confused with the >> ssd_spread mount option, which is a whole different kettle of borscht). >> The dup allocation strategy is currently only available for 2c >> replication, and only on single-device filesystems. When a filesystem >> with dup allocation has a second device added to it, it's automatically >> upgraded to spread. > > I thought this step was manual - but okay! :)
AFAIK, the /allocator/ automatically updates to "spread" when a second device is added. That is, assuming previous dup metadata on a single device, adding a device will cause new allocations to be in raid1/spread mode, instead of dup. What's manual, however, is that /existing/ chunk allocations don't get automatically updated. For that, a balance must be done. But existing allocations are by definition already allocated, so the chunk allocator doesn't do anything with them. (A rebalance allocates new chunks, rewriting the contents of the old chunks into the new ones before unmapping the now unused old chunks, so again, existing chunks stay where they are until unmapped, it's the NEW chunks that get mapped by the updated allocation policy.) -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
