<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:4958E1C3.1000803@mari1938.org" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I have a dedicated BE with 576MB RAM and an old SCSI card with 6x180GB
drives in a software RAID5. It's no trouble recording 2 shows, comm
flagging them, and watching 3 other shows on my different FEs. It
sits in the basement, and is obviously not suitable for a living room
or bedroom, but it's hardware I had lying around or was able to
procure inexpensively.
[deleted]
</pre>
</blockquote>
<pre wrap="">Those are rather high end disks, with low seek times. I was/am using
generic ATA drives.
</pre>
</blockquote>
<pre wrap=""><!---->
Even with generic drives, you can get better overall bandwidth and a
higher number of I/O operations per second with a group of disks than
with one drive.
</pre>
</blockquote>
That's true, but if you write 2 streams to 2 disks individually vs 2
streams to the same disks with RAID, the seek load on the 2 disks 2
streams is going to be lower. <br>
<br>
essentially it all boils down to this<br>
Seek time is not improved with RAID.<b><br>
<br>
</b>The max transfer rate, and max IO operations cannot both happen at
the same time. Xfering one file can happen at say 70MB/sec, if you copy
2 files your going to see probably 25MB/sec per file, ie a total of
50MB/sec.<br>
Scale it to RAID and storage groups.<br>
The RAID gets 100MB/sec because even though its peak transfer is faster
(140mb/sec for one stream) the seek load brings its performance down to
just 2x the single disk. Seek time is not improved with RAID.<br>
The storage pool style can xfer 140MB/sec because it has
no(practically) seeking to worry about.<br>
<br>
<br>
</body>
</html>