SATA Raid (stress test..)

[Nikolas Britton]

On 3/2/06, Alex Zbyslaw <xfb52 at dial.pipex.com> wrote:
> Nikolas Britton wrote:
>
> >This and all the other benchmarks you've run are useless. Run a real
> >benchmark like iozone. It's in ports under benchmarks/iozone.
> >http://www.iozone.org/
> >
> >
> Please can you be careful when you attribute your comments.  You've sent
> this email "to" me, and left only my name in the attributions as if I
> were someone suggesting either dd or diskinfo as accurate benchmarks,
> when in fact my contribution was to suggest unixbench and sandra-lite.
> Maybe you hate those too, in which case you can quote what I said
> in-context and rubbish that at your pleasure.

Yes I see your point, it does look like I'm replying to something you
wrote. This was a oversight and I am sorry.

>
> The OP sent poor-throughput dd stats, and I explained why they were
> poor.  The OP then complained that diskinfo -t stats weren't up to
> snuff, so I contributed mine because they were comparable and I couldn't
> see why he(?) didn't like his(?).
>
> I would contend that the statement "all the other benchmarks you've run
> are useless" is grandiose over-generalisation.  Both dd (with a
> sensible  blocksize) and diskinfo -t will give you useful information.
> One might be an idiot to trust the data to several decimal places, but
> if the result from both was, say, a transfer rate of 5Mb/s when you
> expected 50Mb/s, you could conclude that something was up.  Of course
> neither mimics real-world behaviour; but both likely provide reasonable
> maxima.  You may find that "useless", but with no explanation for your
> reasoning, your statement isn't terribly helpful.
>

Yes, well you see it's a long story :-) By sheer happenstance over the
night had I drive fail on the array I ran the diskinfo test on, if I
would have check my email I'd have know this. So when I logged into
the system via ssh and ran the test I did not know that the array
(RAID5, 8 disks, SATAII, PCI-X) was operating in degraded mode. Having
run extensive iozone testing on this array when I first designed it I
just assumed diskinfo was lying when it said I was getting 70MB/s
transfers, I was getting sustained read transfer rates of 105MB/s on a
650GB test file back when it only had 4 drives. This is the reason I
said diskinfo was useless, however, I still feel that diskinfo is
sorta useless because it only shows you the tip of the iceberg. A tool
such as iozone is much more useful for getting accurate numbers for
the entire disk subsystem. Do you know how disk caching effects your
system? Do you know what FreeBSD, and it's tunable setting, can do to
your file system? Best stripe and block size for your needs? iozone
can tell you all of this and more.

Remember that 105MB/s number I quoted above?, that's just the
sustained read transfer rate for a big ass file, I don't need to work
with big ass files. I need to work with 15MB files (+/- 5MB). After
buying the right disks, controller, mainboard etc. and lots of tuning
with the help of iozone I get: 200 - 350MB/s overall (read, write,
etc.) for files less then or equal to 64MB*.

So anyways, that's what iozone can do for you. google it and you'll
find out more stuff about it.

*in a 4 disk setup running FreeBSD 5.4, I have 8 disks today and run
FreeBSD 6.1-PRERELEASE. so those numbers went up because I have 4 more
disks and the file system speed improvements to the FreeBSD 6.x line,
but I have not benchmarked the improvements because the server is in
production now.



--
BSD Podcasts @ http://bsdtalk.blogspot.com/