From: Rogier Wolff <R.E.Wolff@BitWizard.nl>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: "Rogier Wolff" <R.E.Wolff@BitWizard.nl>,
"Greg Freemyer" <greg.freemyer@gmail.com>,
"Bruno Prémont" <bonbons@linux-vserver.org>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: Slow disks.
Date: Wed, 22 Dec 2010 23:44:16 +0100 [thread overview]
Message-ID: <20101222224416.GE30941@bitwizard.nl> (raw)
In-Reply-To: <x49aajxsrh3.fsf@segfault.boston.devel.redhat.com>
On Wed, Dec 22, 2010 at 11:27:20AM -0500, Jeff Moyer wrote:
> Rogier Wolff <R.E.Wolff@BitWizard.nl> writes:
>
> > Unquoted text below is from either me or from my friend.
> >
> >
> > Someone suggested we try an older kernel as if kernel 2.6.32 would not
> > have this problem. We do NOT think it suddenly started with a certain
> > kernel version. I was just hoping to have you kernel-guys help with
> > prodding the kernel into revealing which component was screwing things
> > up....
> [...]
> > ata3.00: ATA-8: WDC WD10EARS-00Y5B1, 80.00A80, max UDMA/133
>
> This is an "Advanced format" drive, which, in this case, means it
> internally has a 4KB sector size and exports a 512byte logical sector
> size. If your partitions are misaligned, this can cause performance
> problems.
This would mean that for a misalgned write, the drive would have to
read-modify-write every super-sector.
In my performance calculations, 10ms average seek (should be around
7), 4ms average rotational latency for a total of 14ms. This would
degrade for read-modify-write to 10+4+8 = 22ms. Still 10 times better
than what we observe: service times on the order of 200-300ms.
> md1 : active raid5 sda2[0] sdd2[3](S) sdb2[1] sdc2[4]
> > 39067648 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3]
> > [UUU]
>
> A 512KB raid5 chunk with 4KB I/Os? That is a recipe for inefficiency.
> Again, blktrace data would be helpful.
Where did you get the 4kb IOs from? You mean from the iostat -x
output? The system/filesystem decided to do those small IOs. With the
throughput we're getting on the filesystem, it better not try to write
larger chuncks...
I have benchmarked my own "high bandwidth" raid arrays. I benchmarked
them with 128k, 256, 512 and 1024k blocksize. I got the best
throughput (for my benchmark: dd if=/dev/md0 of=/dev/null bs=1024k)
with 512k blocksize. (and yes that IS a valid benchmark for my
usage of the array.)
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
next prev parent reply other threads:[~2010-12-22 22:44 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-20 14:15 Slow disks Rogier Wolff
2010-12-20 18:06 ` Bruno Prémont
2010-12-20 18:32 ` Greg Freemyer
2010-12-22 10:43 ` Rogier Wolff
2010-12-22 15:59 ` Greg Freemyer
2010-12-22 16:27 ` Jeff Moyer
2010-12-22 22:44 ` Rogier Wolff [this message]
2010-12-23 14:40 ` Jeff Moyer
2010-12-23 17:01 ` Rogier Wolff
2010-12-23 17:47 ` Jeff Moyer
2010-12-23 18:51 ` Greg Freemyer
2010-12-23 19:10 ` Jaap Crezee
2010-12-23 22:09 ` Greg Freemyer
2010-12-24 11:40 ` Rogier Wolff
2010-12-24 11:40 ` Rogier Wolff
2010-12-26 23:05 ` Greg Freemyer
2010-12-27 0:27 ` Rogier Wolff
2010-12-27 7:21 ` Stan Hoeppner
2010-12-24 10:45 ` Rogier Wolff
2010-12-23 17:05 ` Jaap Crezee
2010-12-26 23:38 ` Mark Knecht
2010-12-27 0:34 ` Rogier Wolff
2010-12-27 3:12 ` Mark Knecht
2010-12-27 18:20 ` Krzysztof Halasa
2010-12-24 13:01 ` Krzysztof Halasa
2010-12-24 15:24 ` Michael Tokarev
2010-12-24 20:58 ` Krzysztof Halasa
2010-12-25 12:14 ` Rogier Wolff
2010-12-25 12:19 ` Mikael Abrahamsson
2010-12-25 18:12 ` Jaap Crezee
2010-12-25 21:28 ` Michael Tokarev
2010-12-26 21:40 ` Rogier Wolff
2010-12-26 23:17 ` Greg Freemyer
2010-12-26 23:49 ` Rogier Wolff
2010-12-26 22:07 ` Niels
2010-12-27 10:56 ` Tejun Heo
2010-12-20 19:09 ` Jeff Moyer
2010-12-22 20:52 ` David Rees
2010-12-22 22:46 ` Rogier Wolff
2010-12-22 23:13 ` David Rees
[not found] <fa.C+PyZdFdHUxRFDJDF3KlrfaJASk@ifi.uio.no>
2010-12-21 12:29 ` Arto Jantunen
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=20101222224416.GE30941@bitwizard.nl \
--to=r.e.wolff@bitwizard.nl \
--cc=bonbons@linux-vserver.org \
--cc=greg.freemyer@gmail.com \
--cc=jmoyer@redhat.com \
--cc=linux-ide@vger.kernel.org \
--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.