Roberto Spadim wrote:
hum, i asked this question one time, the point is:
raid1 code is very easy
raid10 code is more complex
easy = faster, less memory, less cpu
complex = faster?, more memory? more cpu?
check others raid system (freebsd, netbsd) and check how they do...
2011/5/6 Keld Jørn Simonsen<keld@xxxxxxxxxx>:
Keld Jørn Simonsen wrote:
As you say, RAID10,near on four disks is pretty much identical to
RAID1+0 - i.e., a stripe of two normal RAID1 pairs.
of course RAID10 offers the far option, and the option to run on an odd
number of drives (I currently use it on a couple of 4-drive servers, but
as I look at some replacement hardware I've been thinking that RAID10
on a 5-drive configuration offers a nice mix of reliability and performance)
re. easy/complex - I'm not sure I really believe that - when I've
reviewed options, I come to the conclusion that:
RAID1 - wastes a lot of drive space, particularly if you want to
maintain reliability after a single-drive failure (requires a minimum of
3 mirrored drives)
RAID5 and RAID6 are better when it comes to mixing efficiency with
multi-drive failures, but have a couple of odd failure modes and are a
real pain to rebuild after a failure
RAID1+0 and RAID0+1 are interesting combination - but my sense is that
every time you nest a layer, you're adding configuration complexity,
processing delays (low level cpu cycles and i/o transactions), and just
that much more complexity if you have to reconfigure or rebuild and
array (particularly if you're running LVM and DRBD on top of the basic
disk arrays, as I am)
md RAID10 chops out a layer of nesting and makes better use of disk
space - by combining block replication and striping into a single layer
- providing what, to me, is a good balance of disk use, multiple copies
of data, performance, and managability - so far, its worked well for me
--
In theory, there is no difference between theory and practice.
In<fnord> practice, there is. .... Yogi Berra
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html