<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/1.5.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: RAID - at many levels</title>
	<link>http://storageadvisors.adaptec.com/2006/06/05/raid-at-many-levels/</link>
	<description>Storage Solutions for Real World IT Professionals</description>
	<pubDate>Sat, 21 Nov 2009 05:54:20 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.2</generator>

	<item>
 		<title>Comment on RAID - at many levels by: Steve Rogers</title>
		<link>http://storageadvisors.adaptec.com/2006/06/05/raid-at-many-levels/#comment-6887</link>
		<pubDate>Tue, 25 Jul 2006 17:19:02 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2006/06/05/raid-at-many-levels/#comment-6887</guid>
					<description>Yes, SAS is a point-to-point architecture.

Having separte and distinct RAID sets for your Operating System and User Data sets is a good practice because it:

1. Allows independent disk IO to occur to each RAID set, taking advantage of available bandwidth. 

2. Isolates the OS from the data from a failure perspective

3. In general,  most disks do really well with sequential IO, and to a lesser degree, are slower with Random IO. In general, sequential IO from multiple applications accessing the same Volumes/RAID sets can cause the access patterns to the disks to become more like random IO, affecting your overall performance. Having separate RAID sets helps to match the disks performance more closely to the applications access needs.  RAID controllers compensate for this somewhat, but in the case of JBODS, this scenario becomes more pronounced.

Hope this helps..</description>
		<content:encoded><![CDATA[	<p>Yes, SAS is a point-to-point architecture.</p>
	<p>Having separte and distinct RAID sets for your Operating System and User Data sets is a good practice because it:</p>
	<p>1. Allows independent disk IO to occur to each RAID set, taking advantage of available bandwidth. </p>
	<p>2. Isolates the OS from the data from a failure perspective</p>
	<p>3. In general,  most disks do really well with sequential IO, and to a lesser degree, are slower with Random IO. In general, sequential IO from multiple applications accessing the same Volumes/RAID sets can cause the access patterns to the disks to become more like random IO, affecting your overall performance. Having separate RAID sets helps to match the disks performance more closely to the applications access needs.  RAID controllers compensate for this somewhat, but in the case of JBODS, this scenario becomes more pronounced.</p>
	<p>Hope this helps..
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on RAID - at many levels by: Bill R</title>
		<link>http://storageadvisors.adaptec.com/2006/06/05/raid-at-many-levels/#comment-6838</link>
		<pubDate>Mon, 24 Jul 2006 20:01:38 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2006/06/05/raid-at-many-levels/#comment-6838</guid>
					<description>In reading this and other postings regarding RAID utilizing SAS components, the question comes to mind: Is there any longer an advantage to separating the mirrored drives in a RAID 10 array by SCSI channel?  Is not each SAS drive effectively on it's own channel?</description>
		<content:encoded><![CDATA[	<p>In reading this and other postings regarding RAID utilizing SAS components, the question comes to mind: Is there any longer an advantage to separating the mirrored drives in a RAID 10 array by SCSI channel?  Is not each SAS drive effectively on it&#8217;s own channel?
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
