raid5e and raid5ee
This topic is quite interresting. I found some information about raid5e and raid5ee only on the german wikipedia, but the pictures could do just fine. http://de.wikipedia.org/wiki/RAID#RAID_5E http://de.wikipedia.org/wiki/Bild:RAID_5E.png http://de.wikipedia.org/wiki/Bild:RAID_5EE.png as i understand it, there is no real raid5 in place. raid5ee is basically a simple raid5 with 4 discs, but leaving the 4. disk virtually empty. so if 1 disk fails, the empty stripes are filled. i dont know much about this topic, and i dont know if the information in wikipedia is correct, but i hope i could help a bit yours stephan -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RAID5E
Where I was working most recently some systems were using RAID5E (RAID5 with both the parity and hot spare distributed). This seems to be highly desirable for small arrays, where spreading head motion over one more drive will improve performance, and in all cases where a rebuild to the hot spare will avoid a bottleneck on a single drive. Is there any plan to add this capability? -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RAID5E
On Wed, May 31, 2006 at 04:27:54PM +0200, Mattias Wadenstein wrote: On Wed, 31 May 2006, Bill Davidsen wrote: Where I was working most recently some systems were using RAID5E (RAID5 with both the parity and hot spare distributed). This seems to be highly desirable for small arrays, where spreading head motion over one more drive will improve performance, and in all cases where a rebuild to the hot spare will avoid a bottleneck on a single drive. Is there any plan to add this capability? What advantage does that have over raid6? You use exactly as many drives (n+2), with the disadvantage of having to do a rebuild without parity when a drive fails and a raid failure at a double disk failure. Advantage: - Easier to calculate the checksum (RAID5 XOR instead of a generator polynome with RAID6) - Higher throughput compared to standard RAID5 - Actually uses the hot spare Disadvantage: - Doesn't protect against double disk failures, but RAID5 also doesn't Note that you could also do RAID6E. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RAID5E
On Wednesday May 31, [EMAIL PROTECTED] wrote: Where I was working most recently some systems were using RAID5E (RAID5 with both the parity and hot spare distributed). This seems to be highly desirable for small arrays, where spreading head motion over one more drive will improve performance, and in all cases where a rebuild to the hot spare will avoid a bottleneck on a single drive. Is there any plan to add this capability? I thought about it briefly As I understand it, the layout of raid5e when non-degraded is very similar to raid6 - however the 'Q' block is simply not used. This would be trivial to implement. The interesting bit comes when a device fails and you want to rebuild that distributed spare. There are two possible ways that you could do this: 1/ Leave the spare where it is and write the correct data into each spare. This would be fairly easy but would leave an array with an very ... interesting layout of data. When you add a replacement you just move everything back. 2/ reshape the array to be a regular raid5 layout. This would be hard to do well without NVRAM as you are moving live data, but would result in a neat and tidy array. Ofcourse adding a drive back in would be interesting again... I had previously only thought of option '2', and so discarded the idea as not worth the effort. The more I think about it, the more possible option 1 sounds. I've put it back on my todo list, but I don't expect to get to it this year. Ofcourse if someone else wants to give it a try, I'm happy to make suggestions and review code. NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
