Re: power loss while receiving news

On Sun, 21 Apr 2024 13:58:42 +0200
Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> wrote:

Hi Nigel,
 

I'm in a situation where I've been receiving an innxmit feed to
populate a new news server.
>
Unfortunately, after 992GB, we had a power outage and my UPS died
without a clean shutdown.
>
Now, I'm paranoid my index is corrupt and not sure what to do about
it.
>
I'm using cfs on this new system.
 

 
To add more detail. I am definitely missing some articles.
 
$ grephistory '<q34v5519vru4fco5d14eradn3iksal3ihr@4ax.com>'|sm
sm: could not retrieve @03024359434E475331000F8053BA00000001@
 
 
I have to got back 675 lines in the logfile before I am able to
retrieve an article. 

 
I would then just suggest to run again innxmit on the sending server
for these 675 articles.
Yet, the number of missing articles seems high.  The CNFS headers are
updated every 25 articles by default.  Did you change the
cycbuffupdate setting in cycbuff.conf?  (Or do you have lots of
cyclic buffers, as the refresh is related to each buffer, separately?)
 
grephistory gets information from the history file which is flushed
every 10 articles by default (icdsynccount setting in inn.conf).
 
Overview data is usually written less frequently on disk; it depends
on the overview storage method you are using (after each article
arrival for tradindexed, according to the transrowlimit and
transtimelimit settings in ovsqlite.conf for ovsqlite, the txn_nosync
setting in ovdb.conf for ovdb, and the ovflushcount setting in
inn.conf for buffindexed).
 

No, no changes to the cycbuff.conf file and I only have two buffers,
one for test messages that I don't want to keep around and one for
everything else.

My expire.ctl already has /remember/:0 so we're good there.

I can delete the last 675 entries from the history file, will that just
cause the overview record to be recreated? What about the history.hash
and history.index files? I can't believe it's as easy as removing a few
lines from history and starting the transfer at the point of the last
missing message.


--
End Of The Line BBS - Plano, TX
telnet endofthelinebbs.com 23