On 31.01.2020 22:16, Al wrote:
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.
But if the device is not seekable, wouldn't `lseek()` (which is used inside fseek() just before calling the read()) just return a -1? So glibc could check that, and only in case of -1 to fall back to repositioning with read().