On 1/17/21 1:54 PM, Goffredo Baroncelli wrote:
Hi all,
This is an RFC; I wrote this patch because I find the idea interesting
even though it adds more complication to the chunk allocator.
The basic idea is to store the metadata chunk in the fasters disks.
The fasters disk are marked by the "preferred_metadata" flag.
BTRFS when allocate a new metadata/system chunk, selects the
"preferred_metadata" disks, otherwise it selectes the non
"preferred_metadata" disks. The intial patch allowed to use the other
kind of disk in case a set is full.
This patches set is based on v5.11-rc2.
For now, the only user of this patch that I am aware is Zygo.
However he asked to further constraint the allocation: i.e. avoid to
allocated metadata on a not "preferred_metadata"
disk. So I extended the patch adding 4 modes to operate.
Ok this discussion is going in a few different directions, and there's a lot of
moving parts here. I don't want Goffredo to wander off and do V6 only to have
us go off into the weeds on random particulars of how we think this thing is
supposed to work. To that end, I've opened a design issue in github
https://github.com/btrfs/btrfs-todo/issues/19
and filled out what I think are all the questions and points we've all brought
up throughout these discussions. Everybody please weigh in on the task, laying
out what they think is the best way forward for some/all of these questions.
Once we have an agreed upon design then Goffredo can go and do V6, and then we
only have to argue about the code and not the design. Thanks,
Josef
