Artsize still not quite right in CURRENT

bill davidsen davidsen at
Tue Apr 17 18:14:52 UTC 2001

In article <721yqsez2t.fsf at>,
Alex Kiernan  <alexk at> wrote:
| davidsen at (bill davidsen) writes:

| >   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.

Useful, but a threaded innd for incoming articles would certainly
address my problems more directly. I can handle the readers, I just
fight all the time to keep up with 300GB/day incoming.

| 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.

This is possibly a Redhat library issue, unfortunately I don't have news
on another distribution largefile enabled.

bill davidsen <davidsen at>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

More information about the inn-workers mailing list