linux-kernel - read_ahead_kb defaults to 0 on 2.6.9-55.0.6ELsmp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 21 Sep 2007 15:01:41 -0400
From:	Chet Nichols III <chet.nichols@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: read_ahead_kb defaults to 0 on 2.6.9-55.0.6ELsmp

Hey there,

First time posting to the list, hopefully I'm following protocol.

We recently began rolling out updates to our RHEL4 hosts, which  
updated us to 2.6.9-55.0.6ELsmp.

However, upon reboot, we noticed I/O was being blocked a little more  
than usual. Looking into it, we noticed that the block device  
readahead was now being set to 0, instead of 8192 as it was with the  
previous 2.6.x kernel. (ie: the read_ahead_kb located in /sys/block/ 
cciss\!c0d1/queue/read_ahead_kb, at least for our systems)

In previous < 2.6 kernels where the readahead was managed by sysctl,  
we had a bunch of settings we'd manage ourselves. However, since it's  
an ioctl-managed setting now, I was under the impression the kernel  
would decide what it should be set at during boot.

Granted, we can always just echo in a value when the host is brought  
up, or run blockdev --setra, but we've never had to do this  
previously, so I feel like doing that now would just be a band-aid to  
the issue.

Is there something with this kernel I should be aware of, or has  
anyone noticed anything similar? Tried searching through some  
different threads looking for a similar issue, but to no avail.

Thanks in advance for all the help!

My best,

Chet

-----
Chet Nichols III
mail: chet.nichols@...il.com
aim: chet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/