Will wrote:
> "Bill Todd" <billtodd@metrocast.net> wrote in message
>  news:36OdneA6NJx_hp_bnZ2dnUVZ_vCknZ2d@me
trocastcablevision.com... 
>
> The performance of 2.5 MB/sec average write speed was seen while reading a
nd
> writing a single 250MB file, and the file was all contiguous on a 72 GB
> logical drive that had about 40 GB unused.   I examined the file's
> allocation units on the drive with a file defrag application to verify tha
t
> everything was contiguous.
>
> So it kind of does look like something basic is broken - possibly the arra
y
> just is not very good.   I did try copying in both directions from and to
> the same array, so it's not a single bad piece of hardware.

Hmmm.  You don't say what OS you're using.  Most recent versions of
Windows tend to write large contiguous files in 64 KB chunks - but even
if your array had its write-back cache disabled, and even if Windows
weren't queuing up requests in advance (such that they would be combined
at the disk - though that could get thwarted if the RAID stripe were
also 64 KB per stripe segment), it should still get something more like
8 MB/sec throughput under those conditions (64 KB every 8 ms. or so,
even if the write requests didn't align with the RAID stripe segments
such that each write spanned two disks).

If the array and OS were cooperating as they should be doing, you ought
to be able to write large contiguous files (which should be being
streamed out to the array without waiting for it to finish each request
before queuing the next) at something close to N-1 times 40 MB/sec
(where N is the number of disks in the RAID stripe) - or in your case
around 100 MB/sec as limited by the FC link.  So something isn't right.

- bill

[ Post a follow-up to this message ]