64-bit inn and bitmap weirdness

[Bill Davidsen]

Christiaan den Besten wrote:
> Hi !
>
> We have recently been starting to compile INN in 64-bit on our (newer) 
> 64-bit Linux spool servers. Since some time I have noticed we see more and 
> more of  ..
>
> Jul 28 12:26:24 spool nnrpd[753]: CNFS-sm: fudge size overflows bitmaps 
> @03147374313600000000082C271800000002@ st16:0x10f7ff3b000: 179120864
> Jul 28 12:26:24 spool nnrpd[753]: CNFS-sm: fudge size overflows bitmaps 
> @03147374313600000000082C271800000002@ st16:0x10f7ff3b000: 179120864
> Jul 28 12:26:24 spool nnrpd[753]: CNFS-sm: fudge size overflows bitmaps 
> @03147374303800000000082BA59300000002@ st08:0x10f62147000: 1031605514
> Jul 28 12:26:24 spool nnrpd[753]: CNFS-sm: fudge size overflows bitmaps 
> @03147374303800000000082BA59300000002@ st08:0x10f62147000: 1031605514
>
> .. messages in our news.notice log.
>
> It looks likes articles are being 'overwritten' after some period of time or 
> something like that. From what we have noticed it looks like postings arrive 
> 'complete', but after some weeks they get broken, which would imply 
> something is writing to the spool file at the wrong place ... which might 
> explain the overflows.
>
> Has anybody else noticed the above described scenario and found a fix for it 
> ? :) The spools are running with 16 cnfs stores of 1.2Tb each ( with INN 
> 2.4.4: 20070610-snapshot, but older versions from 2005 seem to behave the 
> same ... )
>   
Did anything ever come of this? I was running files in the 100GB range, 
so I doubt there's a problem with files > 4GB, which might be a 32/64 
bit issue. I never went to TB size, because the small CNFS files allowed 
adding space to whichever class of article was dropping retention to or 
below the retention goals.

-- 
bill davidsen <davidsen at tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979