Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs

From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Subject: Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
Date: Sun, 8 Aug 2010 09:46:53 +0200	[thread overview]
Message-ID: <201008080946.57635@zmi.at> (raw)
In-Reply-To: <20100807101349.GD7362@dastard>

[-- Attachment #1.1: Type: Text/Plain, Size: 1661 bytes --]

On Samstag, 7. August 2010 Dave Chinner wrote:
> > 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.

That would be a wonderful piece of documentation belonging to 
Documentation/sysctl/fs.txt or vm.txt, and /sbin/sysctl should not only 
change /proc/sys values, but also /sys entries.

Such performance knobs are very poorly documented, but would be an 
important bit for administrators to tune systems for their needs. This 
is something that's really missing in Linux.

-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31

****** Aktuelles Radiointerview! ******
http://www.it-podcast.at/aktuelle-sendung.html

// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs