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