Re: Drastic Slowdown of 'fseek()' Calls From 2.4 to 2.6 -- VMM Change?

[Ingo Oeser <ioe-lkml@rameria.de>]

[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]

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 #2: Type: application/pgp-signature, Size: 191 bytes --]