Does this happen with a seek call as well, or is this limited
to fseek?
if you look at "hdparm's" idea of read-ahead, what does it say
for the device?. I.e.:
hdparm /dev/hda:
There is a line entitled "readahead". What does it say?
I noticed that this seems to default to "256" sectors, or 128K
in 2.6.
This may be unrelated, but what does the kernel do with
this number? I seem to remember this being set to ~8-16 (4-8K)
in 2.4. I thought it was the number of sectors to read ahead, by
default, when a read was done, but I haven't noticed a performance
degradation like I would expect for such a large read-ahead value.
On the other hand: you do seem to be experiencing something consistent
with that setting. I'm not sure under what circumstances the kernel
uses the "readahead" value as a number of sectors to read ahead...
Have the disk read routines changed with respect to this value?
-linda
< bottom or top posting is a personal preference somewhat based
on the email tool one uses. In a GUI, bottom posting often means
you can't see what the person wrote without skipping to the end
of message. When dealing with Chronological information, it
often makes more sense to put the most recent information _first>
Bill Davidsen wrote:
Hans Reiser wrote:
Andrew Morton wrote:
runs like a dog on 2.6's reiserfs. libc is doing a (probably) 128k
read
on every fseek.
- There may be a libc stdio function which allows you to tune this
behaviour.
- libc should probably be a bit more defensive about this anyway -
plainly the filesystem is being silly.
I really thank you for isolating the problem, but I don't see how you
can do other than blame glibc for this. The recommended IO size is only
relevant to uncached data, and glibc is using it regardless of whether
or not it is cached or uncached. Do I misunderstand something
myself here?
I think the issue is not "blame" but what effect this behavior would
have on things like database loads, where seek-write would be common.
Good to get this info to users and admins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
