Re: Question: how understand the raid profile of a btrfs filesystem

[Andrei Borzenkov <arvidjaar@gmail.com>]

24.03.2020 20:59, Goffredo Baroncelli пишет:
> 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).

What about per-subvolume profile? This comes up every now and then, like

https://lore.kernel.org/linux-btrfs/cd82d247-5c95-18cd-a290-a911ff69613c@dirtcellar.net/

May be it could be subvolume property?

> 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
>>>
>>
> 
>