On Tue, Nov 16, 2010 at 4:04 PM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2010-11-16 at 12:24 -0800, Greg Freemyer wrote:
On Tue, Nov 16, 2010 at 3:24 AM, Carlos E. R. <> wrote:
Carlos,
You made mention of Raid 8 earlier in this thread, which I've never heard of.
Opps! I intended to say raid 10, made of 8 disks, which is what you proposed.
I suspect you think a Raid 5 is any raid made of 5 disks.
No, never.
As to an earlier comment of yours that a Raid 1 + 0 made of 8 disks would be slower than a Raid 0 made of 4 disks, that can be true, but in theory the actual writing is done in parallel, so the slow down should be negligible.
The bus would be used double time. He has to write all that data, which has to enter the system from somewhere, and perhaps treated. It is a lot of data. If redundancy is needed, better use two computers, which has the advantage of having really dual hardware. If one disk of the raid 10 fails during the process, there will be a severe hiccup till it is removed.
Severe hiccup? Not really. Assuming mdraid 1+0, if a drive is marked failed, then it would simply not be written to. No hiccup at all. And if it is marginal and occasionally failing on writes, mdraid should identify it rather quickly and mark it as failed. ie. mdraid is not very tolerant of drive issues. If a drive is reporting occasional errors, it gets hard failed almost immediately. FYI: Are you aware of "Enterprise SATA" drives? They sound more robust, but in reality they are less robust by design. It's basically just a different set of firmware. Their firmware is specifically coded to "fail fast". Thus if you read from a enterprise drive and it gets an internal CRC error due to a media issue, it will immediately fail that back to the kernel which should immediately retry the read from the other mirror half. Thus the failover is millisecs. If you use standard desktop drives with standard read retry logic, it can take as long as 30 seconds for media error to trigger a drive failure. Not good. With both desktop and enterprise firmware, I think the latest mdraid code will then re-write the data to the drive that reported the error, but with the enterprise drives it all happens very quickly and so it should not be much of a hiccup at all. fyi2: media errors never happen on write. The drive simply seeks to the right place and starts writing. The drive does not attempt to read/verify that data, so a write media error is not generated even if the media has a bad spot where the write went to. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org