Sub-optimal libc's read-ahead buffering behaviour

[Andrey Chernov]

On Thu, Aug 04, 2005 at 08:42:36PM +1000, Peter Jeremy wrote:
> Consider /dev/mem (since that is a favourite in this thread).  You are
> unlikely to hit EOF but reading more than required is likely to cause
> unwanted I/O errors or unexpected device behaviour by accidently reading
> "magic" device addresses.
> 
> That said, most other devices will either reject seeks (eg tapes)
> or will correctly (if inefficiently) handle reading too much.  And
> anyone who uses stdio to read /dev/mem probably deserves the hole
> in their foot.
> 
> I can see two reasonable interpretations of stdio on devices:
> 1) The process issues a setbuf(3) family call to define the buffer size
>    that it wants to use for physical reads/writes.  The process then uses
>    stdio calls to read/write arbitrary sized data which is re-blocked by
>    stdio to suit the device.

Yes. See my other answer in this thread. Buffering or no-buffering or 
sized-buffering is well controled via setvbuf and is a part of user 
interface. If user don't use specifical setvbuf on chardev, he probably 
assume that this particular chardev is bufffer-friendly.

But there is no similar user-visible knob to turn on/off fseek's in-buffer 
seeking, so it is always off for chardev for more safety.

> 2) stdio should be transparent - fread/fwrite/fseek are expected to
>    map directly onto read/write/lseek.

It is never do that way per desing.

> The current implementation falls somewhere in between:  read and write
> are buffered but seeks are transparent.  This would seem to be the worst

Seeks are just not controlled by user, so they are transparent for that 
reason, while read/write buffering is controlled.

> In both cases above, seek really needs to be intelligent - more so
> than for regular files.  It needs to lseek() in multiples of the
> device block size and then adjust the buffer offset to handle any
> remainder.

I don't understand this statement well enough. Currently fseek always 
sense in-buffer data for regular files for both SEEK_SET and SEEK_CUR.

-- 
http://ache.pp.ru/