<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: NAB shorts: Omneon Video Networks</title>
	<atom:link href="http://storagemojo.com/2008/04/24/nab-shorts-omneon-video-networks/feed/" rel="self" type="application/rss+xml" />
	<link>http://storagemojo.com/2008/04/24/nab-shorts-omneon-video-networks/</link>
	<description>Data storage info &#38; analysis</description>
	<pubDate>Wed, 09 Jul 2008 12:34:24 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Bill Todd</title>
		<link>http://storagemojo.com/2008/04/24/nab-shorts-omneon-video-networks/#comment-195458</link>
		<dc:creator>Bill Todd</dc:creator>
		<pubDate>Sun, 27 Apr 2008 12:09:52 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/2008/04/24/nab-shorts-omneon-video-networks/#comment-195458</guid>
		<description>Richard -

The way it's normally done is by distributing the redundant data of each disk across a *lot* of its fellows (rather than to just one other disk as with conventional mirroring - e.g., its mirrored data would instead go a bit to each of the other disks).  Then if a disk fails, virtually *all* the other disks can participate in rebuilding the lost mirrored data, and it can be rebuilt across *all* the remaining disks (i.e., all the combined bandwidth of the remaining disks can be devoted to both reading and writing).

Thus you can rebuild the *data* from a failed 1 TB drive at almost arbitrary speed, because you're not limited by a single drive's bandwidth.

The down-side of doing this is that RAID-1-style multiple-failure probability becomes RAID-5-style multiple failure probability:  once one disk fails, the failure of *any one* of the remaining disks will (likely) result in data loss.  This is to some degree offset by the fact that the mean time to repair (i.e., restore the previous level of redundancy) may decrease drastically, potentially nearly completely offsetting the increased probability of data loss - but that does nothing to protect against multiple *simultaneous* failures (e.g., as might occur after a severe power glitch).

On balance, the additional benefits of such scattering tend to make it attractive (e.g., it allows the use of distributed free space for 'hot spring', thus allowing all drives to contribute to the system's performance rather than leaving some standing by idle to take over if needed).  But it's still a somewhat complex trade-off.

- bill</description>
		<content:encoded><![CDATA[<p>Richard -</p>
<p>The way it&#8217;s normally done is by distributing the redundant data of each disk across a *lot* of its fellows (rather than to just one other disk as with conventional mirroring - e.g., its mirrored data would instead go a bit to each of the other disks).  Then if a disk fails, virtually *all* the other disks can participate in rebuilding the lost mirrored data, and it can be rebuilt across *all* the remaining disks (i.e., all the combined bandwidth of the remaining disks can be devoted to both reading and writing).</p>
<p>Thus you can rebuild the *data* from a failed 1 TB drive at almost arbitrary speed, because you&#8217;re not limited by a single drive&#8217;s bandwidth.</p>
<p>The down-side of doing this is that RAID-1-style multiple-failure probability becomes RAID-5-style multiple failure probability:  once one disk fails, the failure of *any one* of the remaining disks will (likely) result in data loss.  This is to some degree offset by the fact that the mean time to repair (i.e., restore the previous level of redundancy) may decrease drastically, potentially nearly completely offsetting the increased probability of data loss - but that does nothing to protect against multiple *simultaneous* failures (e.g., as might occur after a severe power glitch).</p>
<p>On balance, the additional benefits of such scattering tend to make it attractive (e.g., it allows the use of distributed free space for &#8216;hot spring&#8217;, thus allowing all drives to contribute to the system&#8217;s performance rather than leaving some standing by idle to take over if needed).  But it&#8217;s still a somewhat complex trade-off.</p>
<p>- bill</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard</title>
		<link>http://storagemojo.com/2008/04/24/nab-shorts-omneon-video-networks/#comment-195372</link>
		<dc:creator>Richard</dc:creator>
		<pubDate>Sat, 26 Apr 2008 15:23:53 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/2008/04/24/nab-shorts-omneon-video-networks/#comment-195372</guid>
		<description>Robin,
Rebuild of one TB per hour requires almost 300 MB per sec of average write speed to disk surface...not possible to a single disk.</description>
		<content:encoded><![CDATA[<p>Robin,<br />
Rebuild of one TB per hour requires almost 300 MB per sec of average write speed to disk surface&#8230;not possible to a single disk.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.214 seconds -->
