From: "Frantisek Rysanek" <Frantisek.Rysanek@post.cz>
To: linux-kernel@vger.kernel.org
Subject: [noob q. on block layer] block IO read-ahead during sequential *write*?
Date: Mon, 07 Jan 2008 13:25:09 +0100 [thread overview]
Message-ID: <47822835.4182.1ADF8AE7@localhost> (raw)
Dear Everyone,
let me start with a simple example. The following commands:
cp /dev/zero /dev/hda
dd if=/dev/zero of=/dev/hda [bs=512]
both have one common side-effect: apart from the disk being properly
overwritten with zeroes, the kernel seems to keep reading sectors
ahead of the current seek position of the sequential write.
This is kernel 2.6.22.6 and around that - previously 2.6.16.* and
2.6.18.* . I believe Linux 2.4 kernels didn't do that.
I observe that behavior using `iostat 1` (from the Sysstat package).
After I spotted the behavior, I first upgraded to Sysstat 8.0.3
(latest at the time) to avoid any possible misinterpretation of
/proc/diskstats or what the relevant /proc node is. The upgrade
brought no difference.
I'm using commands along those lines to erase hard drives, to check
their sequential write speed, and as an additional test when checking
for bad sectors / flawed behavior that goes unreported by SMART.
The read-ahead skews my view of sequential write performance :-)
Note that if I specify count=<some fixed number> to 'dd',
the read-ahead doesn't kick in.
Makes me wonder if perhaps "cp" and "dd without count=" perform their
writes un-aligned to sector boundaries, so that the Linux block layer
feels obliged to prefetch the trailing sector that gets only
partially written within a given transaction. It's weird though.
At least bs=512 should be aligned to sector boundaries, even if
uncounted. And, it doesn't seem like every N'th sector - the read and
write rates are about equal.
I've already discovered "hdparm -a", and some follow-ups called
ioctl(BLKRASET) and 'bdi->ra_pages' in $KERNEL_SRC/block/* .
That's where I got stuck - trying to understand the whole read-ahead
logic from the source code would take me too long to be worth it.
That's when I resorted to posting this to the LKML...
Is "hdparm -a" my only chance? Is there any kernel command line
argument or /proc entry or ioctl() to modify this behavior
selectively for writes? Should I write my own test prog,
that will take care to strictly walk the sector boundaries?
Any ideas are welcome :-)
Frank Rysanek
next reply other threads:[~2008-01-07 12:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-07 12:25 Frantisek Rysanek [this message]
2008-01-07 12:49 ` [noob q. on block layer] block IO read-ahead during sequential *write*? Jörn Engel
2008-01-07 15:51 ` Frantisek Rysanek
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=47822835.4182.1ADF8AE7@localhost \
--to=frantisek.rysanek@post.cz \
--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