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. Regards Ingo Oeser
Attachment:
pgpYH9eSdTqDR.pgp
Description: PGP signature
- Follow-Ups:
- References:
- Prev by Date: Re:Badness in vsnprintf
- Next by Date: Re: ramfs and directory modification time
- Previous by thread: Re: Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change?
- Next by thread: Re: Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change?
- Index(es):
 |