Problems with cnfs-spool after system-crash

Russ Allbery rra at stanford.edu
Wed Dec 11 05:36:12 UTC 2002


Felix Schueller <inn.workers-post at fschueller.cologne.de> writes:

> [I have posted this to news.software.nntp and got no answer. Maybe
> someone on this list can help me]

The answer is yes, but only after quite a bit of time....  This message
had been sitting in my queue of messages to deal with, but it takes me a
long time to work through it.

> on my old system iI had an Inn 2.3.[01] on a linux 2.2.18 kernel with
> glibc 2.0.7. But after every systemcrash (if someone had switched the
> power of or so) I had problems with the CNFS-buffers. All postings witch
> came in between the last shutdown of inn and the crash were absent.

> So I looked into cnfs.c to find a solution for my problem. And in cnfs.c
> I found the variable "MMAP_NEEDS_MSYNC". 'man 2 msync' says:

> |msync flushes changes made to the in-core copy of a file that was
> |mapped into memory using mmap(2) back to disk. Without use of this call
> |there is no guarantee that changes are written back before munmap(2) is
> |called.

> But the configure script of inn says that msync is not needed and sets
> '#undef MMAP_NEEDS_MSYNC' in config.h. I think that can be the failure.
> So I put '#define MMAP_NEEDS_MSYNC 1' manually in config.h to test it.

INN was really misusing this information in a lot of places.  I'm working
on slowly fixing that.  If MMAP_NEEDS_MSYNC is set, read cannot see
changes to memory mapped memory without an msync, and therefore in many
cases one must msync after *every* change.  But even if the operating
system doesn't have that problem, one still has to msync periodically to
get the data committed to disk.

CNFS already had code to do that for the CNFS header (the part that, when
not updated, causes the symptoms you saw), doing it by default after every
25 article writes.  But it was only doing that when MMAP_NEEDS_MSYNC was
true, which is wrong.

I've just now modified CURRENT and STABLE to do this properly and msync
unconditionally after that interval.  This should result in a lot more
stability for everyone with CNFS after crashes.

For low-volume servers, or for people who really want to be sure and can
take the I/O hit, put "cycbuffupdate:1" into cycbuff.conf and the header
will be flushed after every article write.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>


More information about the inn-workers mailing list