INN not keeping up with incoming news

[Alex Kiernan]

Fabien Tassin <fta at sofaraway.org> writes:

> > > I also wonder about its behaviour during and after
> > > expire/shutdown/crashes/sync etc. If the files are never committed on disks,
> > > the risk is very high to corrupt or lose everything.
> > > 
> > 
> > The crash risk is partially already there - on exactly what basis does
> > each platform flush modified mmaped pages, how each platform then
> > manages syncs from pages which are mlocked is another part of the
> > problem (AFAICT Solaris manages both problems in the same way, the
> > mlocked pages are just ignored by the page scanner when stealing
> > pages).
> > 
> > I guess we could reduce the risk by msyncing the pages every time the
> > code wakes up.
> > 
> > Also your text history file is complete, I'm not playing games with
> > that one, so you can always rebuild.
> > 
> > I'm not sure I understand what risk you see on expire/shutdown/sync?
> 
> I was trying to figure what will happen when the history files are swapped
> after a rebuild. I don't remember what were the problems I saw with
> shutdown/sync..
> 

It just works for expire; during the expire the current history stays
in core, at the point where you unlink & swap the old history is then
kept incore until the helper wakes up, notices the inode has changed &
unlocks & relocks.

If you don't munlock the segment you end up with a huge useless
segment in core associated with an inode with no on disk links (and I
have the performance graphs which show what happens when you do that :-)

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC