public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.
> 
> 


      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox