From: Dave Chinner <david@fromorbit.com>
To: Stan Hoeppner <stan@hardwarefreak.com>
Cc: xfs@oss.sgi.com
Subject: Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
Date: Sat, 7 Aug 2010 20:13:49 +1000 [thread overview]
Message-ID: <20100807101349.GD7362@dastard> (raw)
In-Reply-To: <4C5A774D.6000400@hardwarefreak.com>
On Thu, Aug 05, 2010 at 03:33:17AM -0500, Stan Hoeppner wrote:
> Neil Brown put forth on 8/4/2010 5:24 PM:
>
> > Both page-cache and read-ahead work at the filesystem level
>
> Are you referring to /sys/block/sdx/queue/read_ahead_kb? I'm pretty sure this
> works below the FS level and below the partition level. This read_ahead works
> at the block device level. At least for individual or JBOD.
That number is used to initialise the default readahead value for
any file descriptor opened on the filesystem. readahead is tracked
per-fd at the page cache level, so is effectively at the filesystem
level, not the block device.
> Are you saying this setting gets ignored by the kernel if/when mdadm, LVM,
> and/or crypto are used?
Only the value from the block device the filesystem sits on is used.
i.e. if you are using /dev/md0, then the filesystem uses the value
from /sys/block/md0/queue/read_ahead_kb and ignores all the ones set
on the /dev/sdX devices that make up /dev/md0.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-08-07 10:13 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-04 7:35 How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs Dominik Brodowski
2010-08-04 8:50 ` Christoph Hellwig
2010-08-04 9:13 ` Dominik Brodowski
2010-08-04 9:21 ` Christoph Hellwig
2010-08-04 9:16 ` Michael Monnerie
2010-08-04 10:25 ` Dominik Brodowski
2010-08-04 11:18 ` Christoph Hellwig
2010-08-04 11:24 ` Dominik Brodowski
2010-08-04 11:53 ` Mikael Abrahamsson
2010-08-04 12:56 ` Mike Snitzer
2010-08-04 22:24 ` Neil Brown
2010-08-05 8:33 ` Stan Hoeppner
2010-08-07 10:13 ` Dave Chinner [this message]
2010-08-07 23:43 ` Stan Hoeppner
2010-08-08 7:46 ` Michael Monnerie
2010-08-04 20:33 ` Valdis.Kletnieks
2010-08-05 9:31 ` direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs] Dominik Brodowski
2010-08-05 11:32 ` Chris Mason
2010-08-05 12:36 ` Josef Bacik
2010-08-05 15:35 ` Dominik Brodowski
2010-08-05 15:39 ` Chris Mason
2010-08-05 15:53 ` Dominik Brodowski
2010-08-05 16:35 ` Dominik Brodowski
2010-08-05 20:47 ` Performance impact of CONFIG_DEBUG? direct-io test case Dominik Brodowski
2010-08-05 20:54 ` Performance impact of CONFIG_SCHED_MC? " Dominik Brodowski
2010-08-05 18:58 ` direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs] Jeff Moyer
2010-08-05 19:01 ` Chris Mason
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=20100807101349.GD7362@dastard \
--to=david@fromorbit.com \
--cc=stan@hardwarefreak.com \
--cc=xfs@oss.sgi.com \
/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