On 3/24/20 5:55 AM, Anand Jain wrote:
On 3/21/20 1:56 AM, Goffredo Baroncelli wrote:
Hi all,
[..]
Looking at the code it seems to me that the logic is the following (from btrfs_reduce_alloc_profile())
if (allowed & BTRFS_BLOCK_GROUP_RAID6)
allowed = BTRFS_BLOCK_GROUP_RAID6;
else if (allowed & BTRFS_BLOCK_GROUP_RAID5)
allowed = BTRFS_BLOCK_GROUP_RAID5;
else if (allowed & BTRFS_BLOCK_GROUP_RAID10)
allowed = BTRFS_BLOCK_GROUP_RAID10;
else if (allowed & BTRFS_BLOCK_GROUP_RAID1)
allowed = BTRFS_BLOCK_GROUP_RAID1;
else if (allowed & BTRFS_BLOCK_GROUP_RAID0)
allowed = BTRFS_BLOCK_GROUP_RAID0;
flags &= ~BTRFS_BLOCK_GROUP_PROFILE_MASK;
So in the case above the profile will be RAID6. And in the general if a RAID6 chunk is a filesystem, it wins !
That's arbitrary and doesn't make sense to me, IMO mkfs should save
default profile in the super-block (which can be changed using ioctl)
and kernel can create chunks based on the default profile.
I'm working on this idea (storing the target profile in super-block). Of course this increase the consistency, but
doesn't prevent the possibility that a mixed profiles filesystem could happen. And in this case is the user that
has to solve the issue.
Zygo, suggested also to add a mixed profile warning to btrfs (prog). And I agree with him. I think that we can use
the space info ioctl (which doesn't require root privileges).
BR
G.Baroncelli
This
approach also fixes chunk size inconsistency between progs and kernel
as reported/fixed here
https://patchwork.kernel.org/patch/11431405/
Thanks, Anand
But I am not sure.. Moreover I expected to see also reference to DUP and/or RAID1C[34] ...
Does someone have any suggestion ?
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
