CNFS corruption

Julien ÉLIE julien at trigofacile.com
Mon Oct 26 21:19:20 UTC 2009


Hi,

>> -rw-rw-r-- 1 news news 2342486016 Oct 26 12:37 three
>> -rw-rw-r-- 1 news news 3071975424 Oct 26 12:45 threea
>> -rw-rw-r-- 1 news news 3071922176 Oct 26 12:44 threeb
>> -rw-rw-r-- 1 news news   63131648 Oct 26 12:15 threec
>>
>> Why don't these CNFS buffers their right size of 3GB?
>> (For instance "three" or "threec".)
>>
>> Did you remove and recreate them?
>
> Yes I did 6 days ago.

You should then have removed all tokens related to these buffers
in the history file, or used another class number.

Well, I assume you will just have to wait for all these articles
to expire.  INN cannot retrieve them, neither can it cancel them.
And it can mix up old history entries with new ones...


>> batcher: CNFS: CNFSUsedBlock: invalid offset 12c361000, min = 18000, max = +b71b0000
>
> 0x12c361000 = 5 036 707 840 bytes
> 0x12c361000 / 8 = 629 588 480 bytes is maybe the right value.

629 588 480 / 512 = 1 229 665 = 0x12C361 is the block number.

Basically, a token says:  look in the "three" file, at block X, cycle N.
In your previous buffer, the article was found at offset 512 × X.
In your new buffer, the article is expected to be at offset 4096 × X
which can exceed the length of the buffer => the error message you wrote.

It is not the same thing...  That's why old history entries should have
been removed before recreating the buffer (even though the block size had
not changed, because there could also have been a mix of offsets).

expire will normally take care of everything but it can take time
(a cycle loop).


I hope my explanation was clear enough.

-- 
Julien ÉLIE

« Inter pradendum sit saepe parumque bibendum. » 




More information about the inn-workers mailing list