Ingo Oeser wrote:
On Saturday, 25. February 2006 06:16, Andrew Morton wrote:
runs like a dog on 2.6's reiserfs. libc is doing a (probably) 128k read
on every fseek.
Thats the bug. If I seek, I never like to have an read issued.
seek should just return whether the result is a valid offset
in the underlying object.
It is perfectly valid to have a real time device which produces data
very fast and where you are allowed to skip without reading anything.
This device coul be a pipe, which just allows forward seeking for exactly
this (implemented by me some years ago).
- fseek is a pretty dumb function anyway - you're better off with
stateless functions like pread() - half the number of syscalls, don't
have to track where the file pointer is at. I don't know if there's a
pread()-like function in stdio though?
pread and anything else not using RELATIVE descriptor offsets are not
very useful for pipe like interfaces that can seek, but just forward.
There are even cases, where you can seek forward and backward, but
only with relative offsets ever, because you have a circular buffer indexed by time.
If you like to get the last N minutes, the relative index is always stable,
but the absolute offset jumps.
So I hope glibc will fix fseek to work as advertised.
But for the simple file case all your answers are valid.
Not really. The app is not silly if it does an fseek() then a _write_.
Writing page sized and aligned chunks should not require previously
uptodate pagecache, so doing a pre-read like this is a complete waste.
Actually glibc tries to turn this pre-read off if the seek is to a page
aligned offset, presumably to handle this case. However a big write
would only have to RMW the first and last partial pages, so pre-reading
128KB in this case is wrong.
And I would also say a 4K read is wrong as well, because a big read will
be less efficient due to the extra syscall and small IO.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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]
