Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

Sanidhya Solanki wrote on 2016/01/09 22:11 -0500:
> On Sun, 3 Jan 2016 09:37:04 +0800
> Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>> Btrfs checksum are calculated in 3 different method:
>> 1) Metadata: Per nodesize, stored in tree blocker header. (struct
>> btrfs_header->csum)
>> 2) Data: Per sectorsize, stored in csum tree.
>> 3) Superblock: Per 4K (fixed), stored in its header (struct
>> btrfs_super->csum)
>>
>> I didn't the need to change any of them, as you are not changing any
>> of the csum behavior.
>
> Good, that means I do not need to compare csums, just the data at the
> end of the re-sizing operation.
>
> I have finished most of the actual implementation details and
> documentation for the re-size. However, before I undertake the last
> part of the development, the integration of kernel-space and user-space,
> as well as the integration between my code and the kernel code.
>
>> Stripe size only affect how btrfs does IO, not the csum size.
>
> I have a question regarding this statement. I wanted to confirm that
> the re-size will result in all the data blocks being re-written. Is
> that correct?

AFAIK, Yes for stripe based RAID profile.

And I must admit that, the above statement is not completely right.
It also affect the on-disk data layout. But csum is still not affected.

> Because the single statement above may also mean that all that needs to
> be done is change one option and the kernel code takes care of the rest.
>
> Just clarify that for me.
>
>> And since you are making the stripe size configurable, then user is
>> responsible for any too large or too small stripe size setting.
>
> I have also left the option to use an un-conventional stripe size to the
> user, for e.g., 768, 3072, 6144, etc.

Although personally I prefer to restrict to power of 2, but that's a 
personal choice anyway.

Thanks,
Qu

>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>