Re: [gentoo-user] OT: btrfs raid 5/6

[Wols Lists]

On 09/12/17 16:58, J. Roeleveld wrote:
> On Friday, December 8, 2017 12:48:45 AM CET Wols Lists wrote:
>> On 07/12/17 22:35, Frank Steinmetzger wrote:
>>>> (Oh - and md raid-5/6 also mix data and parity, so the same holds true
>>>>
>>>>> there.)
>>>
>>> Ok, wasn’t aware of that. I thought I read in a ZFS article that this were
>>> a special thing.
>>
>> Say you've got a four-drive raid-6, it'll be something like
>>
>> data1   data2   parity1 parity2
>> data3   parity3 parity4 data4
>> parity5 parity6 data5   data6
>>
>> The only thing to watch out for (and zfs is likely the same) if a file
>> fits inside a single chunk it will be recoverable from a single drive.
>> And I think chunks can be anything up to 64MB.
>
> Except that ZFS doesn't have fixed on-disk-chunk-sizes. (especially if you use
> compression)
>
> See:
> https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz
>
Which explains nothing, sorry ... :-(

It goes on about 4K or 8K database blocks (and I'm talking about 64 MEG
chunk sizes). And the OP was talking about files being recoverable from
a disk that was removed from an array. Are you telling me that a *small*
file has bits of it scattered across multiple drives? That would be *crazy*.

If I have a file of, say, 10MB, and write it to an md-raid array, there
is a good chance it will fit inside a single chunk, and be written -
*whole* - to a single disk. With parity on another disk. How big does a
file have to be on ZFS before it is too big to fit in a typical chunk,
so that it gets split up across multiple drives?

THAT is what I was on about, and that is what concerned the OP. I was
just warning the OP that a chunk typically is rather more than just one
disk block, so anybody harking back to the days of 512byte sectors could
get a nasty surprise ...

Cheers,
Wol

Cheers,
Wol