Artsize still not quite right in CURRENT
bill davidsen
davidsen at tmr.com
Tue Apr 17 18:14:52 UTC 2001
In article <721yqsez2t.fsf at nd1.eng.demon.net>,
Alex Kiernan <alexk at demon.net> wrote:
|
| davidsen at tmr.com (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 tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
More information about the inn-workers
mailing list