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
