linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Derek Taubert <taubert@geeks.org>
To: Tejun Heo <htejun@gmail.com>
Cc: Derek Taubert <taubert@geeks.org>, linux-ide@vger.kernel.org
Subject: Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
Date: Mon, 28 Aug 2006 21:58:16 -0700	[thread overview]
Message-ID: <20060829045816.GA21746@geeks.org> (raw)
In-Reply-To: <44F3A8FD.6090108@gmail.com>

On Tue, Aug 29, 2006 at 11:39:57AM +0900, Tejun Heo wrote:
> Derek Taubert wrote:
> ># dd if=/dev/zero of=/dev/sda1 count=4M
> ><ctrl-c, then wait 30 seconds>
> >264205+0 records in
> >264204+0 records out
> >135272448 bytes (135 MB) copied, 111.373 seconds, 1.2 MB/s
> >
> >From iostat -k 10:
> >Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
> >sda            2428.64      2422.46       667.66      24273       6690
> >sda              36.84        23.72      1667.87        237      16662
> >sda            2440.60      2434.90       616.00      24349       6160
> >The read rate is curious (should be 0)...
> >
> >Top shows 1% user, 3% system, 93% wait.
> 
> It seems some kind of read IO is in progress.  Can you repeat the test 
> on an unused/idle (iostat -k 10 shows all zeros...) drive?  The above 
> result actually looks good if you consider both read and write sides. 

I think that 3MBytes/sec total for a drive that can read at 50MBytes/sec
on the same system is quite bad, especially since we're talking about
a linear write test.


> The result doesn't seem to indicate any problem in libata or any storage 
> related kernel subsystem.  I would track down the reader first.

This drive has only been partitioned; there is no filesystem on it.  So,
it certainly isn't mounted anywhere.  There honestly isn't _anything_
other than the dd going on to sda1, and that's the only partition on
sda.


> >2) hdparm -C for all 4 drives always shows "drive state is:  standby"
> >   even when I'm certain that the drives are active.
> 
> hdparm -C says the same thing for my drive.  I think it's safe to 
> ignore.  Hmmm... it needs to be tracked down.  Maybe some problem in 
> HDIO ioctl implementation in libata.

It's a "nice to have" for using smartd.  ie: don't spin the drives up to
poll the failure attributes, but they should be checked if the drive's
already active.


> >I'd really like some assistance debugging the write performance issue.
> >The "hdparm -C" issue would be gravy...
> 
> Please track down the reader.

Before running dd (fuser -v /dev/sda1 shows nothing):

avg-cpu:  %user   %nice    %sys %iowait   %idle
           0.50    0.00    0.20    0.00   99.30

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
fd0               0.00         0.00         0.00          0          0
hda               0.00         0.00         0.00          0          0
md0               0.00         0.00         0.00          0          0
md1               0.00         0.00         0.00          0          0
sda               0.00         0.00         0.00          0          0
sdb               0.00         0.00         0.00          0          0
sdc               0.00         0.00         0.00          0          0
sdd               0.00         0.00         0.00          0          0

After starting dd:

# fuser -v /dev/sda1

                     USER        PID ACCESS COMMAND
/dev/sda1            root      21753 f....  dd

avg-cpu:  %user   %nice    %sys %iowait   %idle
           0.90    0.00   11.01   88.09    0.00

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
fd0               0.00         0.00         0.00          0          0
hda               0.10         0.00         0.40          0          4
md0               0.00         0.00         0.00          0          0
md1               0.00         0.00         0.00          0          0
sda            1306.61      1295.60      1310.11      12943      13088
sdb               0.00         0.00         0.00          0          0
sdc               0.00         0.00         0.00          0          0
sdd               0.00         0.00         0.00          0          0

After stopping dd (fuser -v /dev/sda1 again shows nothing):

avg-cpu:  %user   %nice    %sys %iowait   %idle
           0.80    0.00    0.30    0.00   98.90

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
fd0               0.00         0.00         0.00          0          0
hda               1.00         0.00         5.21          0         52
md0               0.00         0.00         0.00          0          0
md1               0.00         0.00         0.00          0          0
sda               0.00         0.00         0.00          0          0
sdb               0.00         0.00         0.00          0          0
sdc               0.00         0.00         0.00          0          0
sdd               0.00         0.00         0.00          0          0

I'm honestly not sure what else to check...

Thanks for your response,
Derek

  reply	other threads:[~2006-08-29  4:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-28 23:01 Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive Derek Taubert
2006-08-29  2:39 ` Tejun Heo
2006-08-29  4:58   ` Derek Taubert [this message]
2006-08-29  7:54     ` Derek Taubert
2006-08-29 13:35       ` Tejun Heo
2006-08-29 13:27     ` Tejun Heo
2006-08-29 16:44       ` Derek Taubert
2006-08-29 21:24         ` Jeff Garzik
2006-09-01 13:32         ` Tejun Heo
2006-09-01 17:24           ` Derek Taubert
2006-09-02  5:34             ` Derek Taubert
2006-09-03  6:26               ` Derek Taubert
2006-09-03 19:03                 ` Tejun Heo
2006-09-03 20:04                   ` Derek Taubert
2006-09-28 22:07                     ` Derek Taubert
2006-08-29 14:07   ` Greg Freemyer

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=20060829045816.GA21746@geeks.org \
    --to=taubert@geeks.org \
    --cc=htejun@gmail.com \
    --cc=linux-ide@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;
as well as URLs for NNTP newsgroup(s).