public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Linda Walsh <xfs@tlinx.org>
To: Emmanuel Florac <eflorac@intellique.com>
Cc: Paul Anderson <pha@umich.edu>, xfs@oss.sgi.com
Subject: Re: FYI: LSI rebuilding; and XFS speed V. raw - hints on maxing out 'dd'....(if not already obvious)...
Date: Sat, 11 Jun 2011 09:48:49 -0700	[thread overview]
Message-ID: <4DF39C71.7060706@tlinx.org> (raw)
In-Reply-To: <20110611113049.2868f9c7@galadriel2.home>



Emmanuel Florac wrote:
> Le Fri, 10 Jun 2011 18:33:08 -0700 vous écriviez:
> 
>> I have a 9285-8E and have been pretty happy with it's performance,
>> but I only have 10 data disks (2x6-disk RAID5 =>RAID50) with 2TB
>> SATA's and get 1GB perf... about what I'd expect from disks that get
>> around 120MB each and doing 2 RAID5 calcs...)...
> 
> I've made some more tests since then, and I was using cheapo drives for
> testing that for some reason, behave extraordinarily poorly in
> combination with the LSI card. I've retested the card with hitachi
> Ultrastars and it worked just fine (though a bit slower than Adaptec
> 6xx5). OTOH, the Adaptec works fine with the "bad" drives too, go
> figure. 
-----
	I noticed this issue with the LSI card as well -- i.e. with
'bad' low-qual drives.

	What I noticed though -- in independent testing of the 
lower quality drives, was that even though they were all spec'ed at
7200RPM, their actual speeds varied, from top to bottom by almost 50%
(Indirectly measured by top transfer speeds copying from & to the drives
128G files... .. all freshly formatted, factory 'new', from the same
generation).   Speeds varied from top to bottom with max around 129MB/s
to bottom @ 87MB/s, with typical being 95-120.  That was quite a range 
of speeds.   Trying to 'synchronize reads/writes/ on drives with such
varying speeds would be a nightmare.  

	I tried another RAID controller and got about 60% the performance
of the LSI's -- but it was also with the cheaper drives.  The LSI controller
wouldn't "pass" the drives as "acceptable" if they were too far out of spec.

	The Ultrastars (NOT the deskstars, which are not speed controlled)
all were fine.  I've heard of people having problems with Enterprise
Class WD drives due to the issue.   So it may be a matter of the controller
'protecting itself' from drives that are out of spec -- and are therefore not
considered 'RAID class' drives...   

	Some would argue that being more 'tolerant' of poor drives is a good
thing...  But if you want the fastest speed, you need to make sure the drive
speeds are well matched.




same issue.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-06-11 16:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-02 15:47 XFS/Linux Sanity check Paul Anderson
2011-05-02 17:09 ` Andi Kleen
2011-05-02 17:13 ` Emmanuel Florac
2011-06-11  1:33   ` FYI: LSI rebuilding; and XFS speed V. raw - hints on maxing out 'dd'....(if not already obvious) Linda Walsh
2011-06-11  9:30     ` Emmanuel Florac
2011-06-11 16:48       ` Linda Walsh [this message]
2011-05-03  3:18 ` XFS/Linux Sanity check Dave Chinner
2011-05-03  8:58   ` Michael Monnerie
2011-05-03 16:05   ` Paul Anderson
2011-05-04 10:36     ` Stan Hoeppner
2011-05-04  6:18   ` Stan Hoeppner
2011-05-04  1:10 ` Stan Hoeppner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DF39C71.7060706@tlinx.org \
    --to=xfs@tlinx.org \
    --cc=eflorac@intellique.com \
    --cc=pha@umich.edu \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox