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