On Sat, Dec 9, 2017 at 1:28 PM, Wols Lists <[email protected]> wrote: > 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*.
I'm not sure why it would be "crazy." Granted, most parity RAID systems seem to operate just as you describe, but I don't see why with Reed Solomon you couldn't store ONLY parity data on all the drives. All that matters is that you generate enough to recover the data - the original data contains no more information than an equivalent number of Reed-Solomon sets. Of course, with the original data I imagine you need to do less computation assuming you aren't bothering to check its integrity against the parity data. In case my point is clear a RAID would work perfectly fine if you had 5 drives with the capacity to store 4 drives wort of data, but instead of storing the original data across 4 drives and having 1 of parity, you instead compute 5 sets of parity so that now you have 9 sets of data that can tolerate the loss of any 5, then throw away the sets containing the original 4 sets of data and store the remaining 5 sets of parity data across the 5 drives. You can still tolerate the loss of one more set, but all 4 of the original sets of data have been tossed already. -- Rich
