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

Anand Jain
2020-03-24T04:55:53Z

On 3/21/20 1:56 AM, Goffredo Baroncelli wrote:
> Hi all,
>
> for a btrfs filesystem, how an user can understand which is the
> {data,mmetadata,system} [raid] profile in use ? E.g. the next chunk
> which profile will have ?
> For simple filesystem it is easy looking at the output of (e.g)  "btrfs
> fi df" or "btrfs fi us". But what if the filesystem is not simple ?
>
> btrfs fi us t/.
> Overall:
>     Device size:          40.00GiB
>     Device allocated:          19.52GiB
>     Device unallocated:          20.48GiB
>     Device missing:             0.00B
>     Used:              16.75GiB
>     Free (estimated):          12.22GiB    (min: 8.27GiB)
>     Data ratio:                  1.90
>     Metadata ratio:              2.00
>     Global reserve:           9.06MiB    (used: 0.00B)
>
> Data,single: Size:1.00GiB, Used:512.00MiB (50.00%)
>    /dev/loop0       1.00GiB
>
> Data,RAID5: Size:3.00GiB, Used:2.48GiB (82.56%)
>    /dev/loop1       1.00GiB
>    /dev/loop2       1.00GiB
>    /dev/loop3       1.00GiB
>    /dev/loop0       1.00GiB
>
> Data,RAID6: Size:4.00GiB, Used:3.71GiB (92.75%)
>    /dev/loop1       2.00GiB
>    /dev/loop2       2.00GiB
>    /dev/loop3       2.00GiB
>    /dev/loop0       2.00GiB
>
> Data,RAID1C3: Size:2.00GiB, Used:1.88GiB (93.76%)
>    /dev/loop1       2.00GiB
>    /dev/loop2       2.00GiB
>    /dev/loop3       2.00GiB
>
> Metadata,RAID1: Size:256.00MiB, Used:9.14MiB (3.57%)
>    /dev/loop2     256.00MiB
>    /dev/loop3     256.00MiB
>
> System,RAID1: Size:8.00MiB, Used:16.00KiB (0.20%)
>    /dev/loop2       8.00MiB
>    /dev/loop3       8.00MiB
>
> Unallocated:
>    /dev/loop1       5.00GiB
>    /dev/loop2       4.74GiB
>    /dev/loop3       4.74GiB
>    /dev/loop0       6.00GiB
>
> This is an example of a strange but valid filesystem. So the question
> is: the next chunk which profile will have ?
> Is there any way to understand what will happens ?
>
> I expected that the next chunk will be allocated as the last "convert".
> However I discovered that this is not true.
>
> 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. 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
>