Why fseek causes a read()?

[Al]

It used to be that the documentation for seek/lseek and fseek suggested 
if a device was not capable of direct positioning, that the
library routines would try to chew through the intervening space via a 
(or many) read() system call(s).

I wouldn't want to disable that without understanding the consequences.  
Your experience suggests that that logic may not be functioning 
correctly, but I wouldn't discard it lightly.  It may be better to 
figure out if it is broken, and if so fix it.

I haven't gone through that code in the past, so I am sure if it has 
changed.

Block devices should generally be seekable, but not all are.


On 1/31/2020 10:33, Konstantin Kharlamov wrote:
> On 31.01.2020 19:05, Godmar Back wrote:
>>
>> This is an interesting question and leads to what semantics is 
>> required of fully buffered streams for files that are essentially 
>> subject to random access.
>>
>>  From a logical point of view, you shouldn't expect to have control 
>> over the read/lseek calls stdio issues since you are using a 
>> fully-buffered abstraction layer (I/O streams).
>>
>> Perhaps you get better control with unbuffered streams, i.e., if you 
>> call setbuf(f, NULL), does the read() go away?
>>
>
> Thank you, indeed it does. I sent a fix to hexdump¹
>
> Anyway, that makes me wonder: is there really any use in this read 
> inside fseek()? Can this be just removed in glibc? IMO it's just a 
> waste of CPU and IO for all apps that use fseek().
>
> 1: https://github.com/karelzak/util-linux/pull/946