<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- If individual disks, the recordings are written sequentially on each disk, with minimal head movement.<br>
</blockquote></div>
...<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just my recommendation... I'm sure others would argue otherwise.<br>
</blockquote>
<br></div>
No, seems a reasonable "layman's guide". Some slight corrections/observations though :<br>
<br>
When writing a recording, the file is synced about once/second. That involves a write of the data and then a write of the metadata. So each second there will be as a minimum "seek-write-seek-write" per stream. Some of the metadata writes will involve multiple seeks - perhaps reading some data on free space, updating that (and it's metadata), and then writing the data.<br>
So it's actually worse than the "one seek per thread per second" suggested. <br></blockquote><div><br>I over simplified things... but the end result holds true... the number of seeks on each drive increase if you put the drives in a stripe set rather than balance the load across independent disks.<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
RAID1 can turn in excellent read performances - potentially much higher than a single drive. </blockquote><div><br>Absolutely true... however it can never outperform an equal number of non-raided drives, assuming a equally distributed load, and write performance will suffer in raid1, lower than the slowest disk in the array. There is always some overhead with raid.<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the absence of writes, an intelligent controller can distribute read requests across the two drives according to their head locations - so seek distances can be significantly reduced on both drives and it's possible to think of a contrived (and artificial) situation where a 2 disk stripe could give more than twice the read performance of each disk individually.<br>
</blockquote><div><br>While I suspect that someone could devise a scenario where you could accomplish this, I have never heard of an array being faster than the combined performance of it's parts. Obviously this is assuming that the load can be properly spread across the individual disks. This is where raid will always win... if I am doing a single file read or write... I cannot balance this across multiple disks... so raid will be faster. <br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Of course, throw in writes and both disks must seek to the same place - but then can seek off in different directions to satisfy reads from either end of the mirrored volume.<br>
But I suspect it's going to be rare where the advantages of a striped volume outweigh the downsides for Myth use.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>Indeed, a very well designed raid controller can accomplish amazing things to optimize the performance of the array... but typically this only applies to situations where the array is explicitly designed for the intended load. For example, I know that several manufacturers make arrays that perform very well with MS Exchange mail... but MS is now recommending Exchange be deployed using JBOD distributed across all of the servers rather than using a SAN... give better performance and fewer points of failure.<br>
<br><br>Fun stuff, raid.<br></div></div>