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

From: Goffredo Baroncelli <kreijack@inwind.it>
To: Andrei Borzenkov <arvidjaar@gmail.com>
Cc: Anand Jain <anand.jain@oracle.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Subject: Re: Question: how understand the raid profile of a btrfs filesystem
Date: Wed, 25 Mar 2020 18:14:05 +0100	[thread overview]
Message-ID: <3dfbf173-7ac2-887f-d3eb-ec1b6c610d01@inwind.it> (raw)
In-Reply-To: <8a53cf8d-980d-8c41-e35d-c8b70db1bbdc@gmail.com>

On 3/25/20 5:09 AM, Andrei Borzenkov wrote:
> 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?

The idea is nice. However I fear the mess that it could cause. Even now, with a
more simpler system where there is a "per filesystem" profile, there are a lot of corner
cases when something goes wrong (an interrupted balance, or a disk failed).
In case of multiple profiles on sub-volume basis there is no simple answer in situation like:
- when I make a snapshot of a sub-volumes, and then I change the profile of the original one,
which is the profile of the files contained in the snapshot and in the original subvolumes ?

Frankly speaking, if you want different profiles you need different filesystem...

BR
G.Baroncelli

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