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



             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