sas/sata topology vs performance?

Steven Alligood steve at bluehost.com
Thu Oct 25 12:16:33 MDT 2007


Without having any more information than this email (was there an 
earlier one I missed?), I would grasp at the straw that the different 
sides of the array are going through different controllers (either 
within the array or in the attached computer), and possibly even that 
the SAS drives are possibly causing some form of congestion or 
performance bottleneck on their controller for all of the SATA drives, 
or rather, the array isn't very good at mixing both types on the same 
controller and keeping up the expected speeds.

All conjecture, of course, without quite a bit more specifics (array 
brand and model, are these JBOD with software RAID or hardware RAID, etc)

-Steve


Nicholas Leippe wrote:
> Regarding the 12-drive bay we have, I'm seeing some puzzling performance.
> The drives are physically so in the bay:
>
> e h k n
> f i l o
> g j m p
>
> I configured mirrors across e+f and g+h, and both synced at the same, 
> quick/expected speed. These are my four sas drives. The rest are sata.
>
> If I configure a mirror with o+p, or m+n they both sync at between 50 and 
> 80MB/s--very quick and within expectations.
>
> However, if I configure a mirror with drives i+j, it syncs at <25MB/s.
> If I configure a mirror with either i+p or j+p, it syncs at between 50 and 
> 80MB/s--so it doesn't appear to be either drive i or drive j at fault, but 
> their combination...
>
> This doesn't make sense to me, especially where they are all point-to-point 
> devices.
>
> Is there some weird way that sas/sata addressing can affect this?
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
Url : http://plug.org/pipermail/plug/attachments/20071025/35dcc678/attachment.bin 


More information about the PLUG mailing list