is it safe to change BTRFS_STRIPE_LEN?

is it safe to change BTRFS_STRIPE_LEN?

[john terragon]

Hi.

I'm playing around with (software) raid0 on SSDs and since I remember
I read somewhere that intel recommends 128K stripe size for HDD arrays
but only 16K stripe size for SSD arrays, I wanted to see how a
small(er) stripe size would work on my system. Obviously with btrfs on
top of md-raid I could use the stripe size I want. But if I'm not
mistaken the stripe size with the native raid0 in btrfs is fixed to
64K in BTRFS_STRIPE_LEN (volumes.h).
So I was wondering if it would be reasonably safe to just change that
to 16K (and duck and wait for the explosion ;) ).

Can anyone adept to the inner workings of btrfs raid0 code confirm if
that would be the right way to proceed? (obviously without absolutely
any blame to be placed on anyone other than myself if things should go
badly :) )

Thanks

john

Re: is it safe to change BTRFS_STRIPE_LEN?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

On 05/24/2014 12:44 PM, john terragon wrote:
> Hi.
> 
> I'm playing around with (software) raid0 on SSDs and since I remember
> I read somewhere that intel recommends 128K stripe size for HDD arrays
> but only 16K stripe size for SSD arrays, I wanted to see how a
> small(er) stripe size would work on my system. Obviously with btrfs on
> top of md-raid I could use the stripe size I want. But if I'm not
> mistaken the stripe size with the native raid0 in btrfs is fixed to
> 64K in BTRFS_STRIPE_LEN (volumes.h).
> So I was wondering if it would be reasonably safe to just change that
> to 16K (and duck and wait for the explosion ;) ).
> 
> Can anyone adept to the inner workings of btrfs raid0 code confirm if
> that would be the right way to proceed? (obviously without absolutely
> any blame to be placed on anyone other than myself if things should go
> badly :) )
I personally can't render an opinion on whether changing it would make
things break or not, but I do know that it would need to be changed both
in the kernel and the tools, and the resultant kernel and tools would
not be entirely compatible with filesystems produced by the regular
tools and kernel, possibly to the point of corrupting any filesystem
they touch.

As for the 64k default strip size, that sounds correct, and is probably
because that's the largest block that the I/O schedulers on Linux will
dispatch as a single write to the underlying device.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]

Re: is it safe to change BTRFS_STRIPE_LEN?

[john terragon]

Yes the btrfs-tools would have to be recompiled too ( BTRFS_STRIPE_LEN
is defined in a volumes.h in there too).
And yes, kernel and tools would certainly kill any raid0 btrfs fs and
maybe any other multidevice kind of setting.


On Sat, May 24, 2014 at 9:07 PM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
> On 05/24/2014 12:44 PM, john terragon wrote:
>> Hi.
>>
>> I'm playing around with (software) raid0 on SSDs and since I remember
>> I read somewhere that intel recommends 128K stripe size for HDD arrays
>> but only 16K stripe size for SSD arrays, I wanted to see how a
>> small(er) stripe size would work on my system. Obviously with btrfs on
>> top of md-raid I could use the stripe size I want. But if I'm not
>> mistaken the stripe size with the native raid0 in btrfs is fixed to
>> 64K in BTRFS_STRIPE_LEN (volumes.h).
>> So I was wondering if it would be reasonably safe to just change that
>> to 16K (and duck and wait for the explosion ;) ).
>>
>> Can anyone adept to the inner workings of btrfs raid0 code confirm if
>> that would be the right way to proceed? (obviously without absolutely
>> any blame to be placed on anyone other than myself if things should go
>> badly :) )
> I personally can't render an opinion on whether changing it would make
> things break or not, but I do know that it would need to be changed both
> in the kernel and the tools, and the resultant kernel and tools would
> not be entirely compatible with filesystems produced by the regular
> tools and kernel, possibly to the point of corrupting any filesystem
> they touch.
>
> As for the 64k default strip size, that sounds correct, and is probably
> because that's the largest block that the I/O schedulers on Linux will
> dispatch as a single write to the underlying device.
>