CNFS buffers wrap much too soon
Miquel van Smoorenburg
list-inn-workers at news.cistron.nl
Wed Feb 12 23:03:44 UTC 2003
In article <yl8ywlxnkm.fsf at windlord.stanford.edu>,
Russ Allbery <rra at stanford.edu> wrote:
>Miquel van Smoorenburg <list-inn-workers at news.cistron.nl> writes:
>
>> However those buffers unexpectedly rollover at 1-5 GB instead of at 140
>> GB. I've logged the output of cnfsstat every 5 minutes so that you can
>> see what's happening (the line "for groups matching" doesn't make much
>> sense, it's probably just taking the first line of a matching
>> storage.conf entry while there are multiple):
>
>One thing to check is to make sure that the problem isn't actually with
>cnfsstat and not with the CNFS code itself. With buffers over 2GB, I
>don't really trust the cnfsstat output a whole lot.
I'm not quite sure if this is the only one (I'll have to let it run for
a while longer) but there's definitely a size_t/off_t problem. The
difference between 2 64 bit ints certainly doesn't fit in a 32 bit uint...
Patch I'm using right now:
--- inn-2.4-20030212.orig/storage/cnfs/cnfs.c Wed Jan 22 15:49:31 2003
+++ inn-2.4-20030212/storage/cnfs/cnfs.c Wed Feb 12 15:09:31 2003
@@ -1042,7 +1042,7 @@
static int iovcnt;
int tonextblock;
CNFSEXPIRERULES *metaexprule;
- size_t left;
+ off_t left;
for (metaexprule = metaexprulestab; metaexprule != (CNFSEXPIRERULES *)NULL; metaexprule = metaexprule->next) {
if (metaexprule->class == class)
Things look a lot saner with this applied. For now. If it keeps
running I'll send it to inn-patches.
Mike.
--
Anyone who is capable of getting themselves made President should
on no account be allowed to do the job -- Douglas Adams.
--
The From: and Reply-To: addresses are internal news2mail gateway addresses.
Reply to the list or to miquels at cistron-office.nl (Miquel van Smoorenburg)
More information about the inn-workers
mailing list