From: Timothy Miller <miller@techsource.com>
To: Daniel Blueman <daniel.blueman@gmx.net>
Cc: aradford@3WARE.com, linux-kernel@vger.kernel.org
Subject: Re: File system performance, hardware performance, ext3, 3ware RA ID1, etc.
Date: Mon, 16 Feb 2004 12:18:30 -0500 [thread overview]
Message-ID: <4030FB66.6060803@techsource.com> (raw)
In-Reply-To: <30156.1076775952@www12.gmx.net>
Daniel Blueman wrote:
> Tim,
>
> Do you get the same numbers (but slightly higher, as this is will measure
> from a smaller portion of outer zones) with:
>
> # hdparm -t /dev/sda
>
> ?
I ran this test. This is a read test. What I did below was a write test.
Additionally, I ran this test:
time dd if=/dev/sda of=/dev/null bs=1024k count=1024
From that, I got 47 megs/sec. From 'hdparm -t /dev/sda', I got a
slightly lower number.
So, for reads, I'm getting good performance. 47 megs/sec at the
outer-most tracks is a bit lower than the 50+ that reviewers report, but
it's not bad.
However, I don't get anywhere near the 40+ megs/sec the reviewers say
the drive gets for writes. That model as a single drive in my wife's
computer gets about 39 megs/sec, which is great. But behind the 3ware,
the drive gets only 13 megs/sec. (iozone reports about 15 megs/sec, but
that's influenced by caching in RAM, and iozone is writing to a file on
tracks further out, I think.)
>
>
>>Adam Radford wrote:
>>
>>>Perhaps you are issuing non purely sequential IO. The card firmware
>>
>>does
>>
>>>some
>>>reodering, but at some point it will cause performance degradation. Can
>>
>>you
>>
>>>try
>>>kernel 2.6 w/xfs?
>>
>>Not any time soon, but as I mentioned earlier, I measured 13.9 megs/sec
>>when I ran this command:
>>
>> time dd if=/dev/zero of=/dev/sda2 bs=1024k count=1024
>>
>>No file system was involved; I was simply writing zeros to the block
>>device (swap partition with swap off). It took 73.522 seconds to do the
>>above operation. Also, I was running in single-user mode while doing
>>the test.
>>
>>
>>>Also, in my experience, the 'raw io' interface doesn't issue any
>>>asynchronous IO. The
>>>card _definately_ needs asynchronous IO posted to it or you will not get
>>>good results
>>>because you won't get all the drives busy.
>>
>>With RAID1, both drives will be written with the same data. There is no
>>need to be asynchronous, since it's all completely linear and sequential
>>with large data blocks.
>
>
prev parent reply other threads:[~2004-02-16 17:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-13 23:07 File system performance, hardware performance, ext3, 3ware RA ID1, etc Adam Radford
2004-02-13 23:52 ` Timothy Miller
2004-02-14 16:25 ` Daniel Blueman
2004-02-16 17:18 ` Timothy Miller [this message]
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=4030FB66.6060803@techsource.com \
--to=miller@techsource.com \
--cc=aradford@3WARE.com \
--cc=daniel.blueman@gmx.net \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.