Artsize still not quite right in CURRENT

[Alex Kiernan]

davidsen at tmr.com (bill davidsen) writes:

> In article <20010416162702.A7568 at opentransit.net>,
> Fabien Tassin  <fta at sofaraway.org> wrote:
> 
> | I'm using the latest kernel (2.4.3) and glibc 2.1.3.
> | According to the glibc 2.1.3 doc :
> | 
> |  - Function: ssize_t pread (int FILEDES, void *BUFFER, size_t SIZE,
> |           off_t OFFSET)
> | ...
> |      When the source file is compiled with `_FILE_OFFSET_BITS == 64' the
> |      `pread' function is in fact `pread64' and the type `off_t' has 64
> |      bits which makes it possible to handle files up to 2^63 bytes in
> |      length.
> | 
> | but it is not working. I haven't tested with glibc 2.2.* (the doc
> | reads the same anyway) but reverting to lseek()+read() fixes the problem.
> 
>   I have to go look at the code, but the 20010222-CURRENT code works. If
> that's the lseek+read code, we have an answer. But how could part of the
> library be compiled with largefile support (lseek) and part not? COuld
> it be that the library source is just wrong?
> 

Library or kernel (but given the strace output I'd guess library, but
I don't know Linux well enough).

>   In any case, if that's the problem, unless there's a huge gain in
> {something} by using pread, perhaps we can revert the code, or put in a
> conditional, or whatever.
> 

How about writing a configure test which checks for broken
implementations and falls back to the version in lib (which emulates
using lseek & read, so should work).

The problem with going back (well its not a problem today) is that
unless you put mutexes around your lseeks & reads you can't use it in
a threaded environment (without having a set of file handles per
thread). A threaded nnrpd is one of the things I've been playing with.

The other concern I have is that the new history code I have uses
pread/pwrite - that would fail in the same way if your history file
were to grow bigger than 4G.

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC