| 1 |
On Sat, Dec 9, 2017 at 1:28 PM, Wols Lists <antlists@××××××××××××.uk> wrote: |
| 2 |
> On 09/12/17 16:58, J. Roeleveld wrote: |
| 3 |
>> On Friday, December 8, 2017 12:48:45 AM CET Wols Lists wrote: |
| 4 |
>>> On 07/12/17 22:35, Frank Steinmetzger wrote: |
| 5 |
>>>>> (Oh - and md raid-5/6 also mix data and parity, so the same holds true |
| 6 |
>>>>> |
| 7 |
>>>>>> there.) |
| 8 |
>>>> |
| 9 |
>>>> Ok, wasn’t aware of that. I thought I read in a ZFS article that this were |
| 10 |
>>>> a special thing. |
| 11 |
>>> |
| 12 |
>>> Say you've got a four-drive raid-6, it'll be something like |
| 13 |
>>> |
| 14 |
>>> data1 data2 parity1 parity2 |
| 15 |
>>> data3 parity3 parity4 data4 |
| 16 |
>>> parity5 parity6 data5 data6 |
| 17 |
>>> |
| 18 |
>>> The only thing to watch out for (and zfs is likely the same) if a file |
| 19 |
>>> fits inside a single chunk it will be recoverable from a single drive. |
| 20 |
>>> And I think chunks can be anything up to 64MB. |
| 21 |
>> |
| 22 |
>> Except that ZFS doesn't have fixed on-disk-chunk-sizes. (especially if you use |
| 23 |
>> compression) |
| 24 |
>> |
| 25 |
>> See: |
| 26 |
>> https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz |
| 27 |
>> |
| 28 |
> Which explains nothing, sorry ... :-( |
| 29 |
> |
| 30 |
> It goes on about 4K or 8K database blocks (and I'm talking about 64 MEG |
| 31 |
> chunk sizes). And the OP was talking about files being recoverable from |
| 32 |
> a disk that was removed from an array. Are you telling me that a *small* |
| 33 |
> file has bits of it scattered across multiple drives? That would be *crazy*. |
| 34 |
|
| 35 |
I'm not sure why it would be "crazy." Granted, most parity RAID |
| 36 |
systems seem to operate just as you describe, but I don't see why with |
| 37 |
Reed Solomon you couldn't store ONLY parity data on all the drives. |
| 38 |
All that matters is that you generate enough to recover the data - the |
| 39 |
original data contains no more information than an equivalent number |
| 40 |
of Reed-Solomon sets. Of course, with the original data I imagine you |
| 41 |
need to do less computation assuming you aren't bothering to check its |
| 42 |
integrity against the parity data. |
| 43 |
|
| 44 |
In case my point is clear a RAID would work perfectly fine if you had |
| 45 |
5 drives with the capacity to store 4 drives wort of data, but instead |
| 46 |
of storing the original data across 4 drives and having 1 of parity, |
| 47 |
you instead compute 5 sets of parity so that now you have 9 sets of |
| 48 |
data that can tolerate the loss of any 5, then throw away the sets |
| 49 |
containing the original 4 sets of data and store the remaining 5 sets |
| 50 |
of parity data across the 5 drives. You can still tolerate the loss |
| 51 |
of one more set, but all 4 of the original sets of data have been |
| 52 |
tossed already. |
| 53 |
|
| 54 |
|
| 55 |
-- |
| 56 |
Rich |
Archives