[dovecot] Re: Architectural questions

[Timo Sirainen]

On Mon, 2002-10-21 at 17:19, Thomas Wouters wrote:
> > Requiring msync() is fine, that's done after each change, but there
> > should be better solution than re-mmap()ing to notice the changes. I
> > think FreeBSD checked the changes after fcntl() locking changes :)
> 
> Hmm. More bad news; flock() doesn't work over NFS. That is, local processes
> see and honor the lock even on NFS filesystems, but other machines don't see
> the lock at all. fcntl() doesn't work at all (but that's probably because
> we're not running lockd.)

flock() doesn't matter, it's used only for mbox locking where .lock file
would work instead just as well. 

> That aside, this issue isn't that big an issue for us. The
> same-client-connecting-twice case we can solve by configuring the layer-4
> ethernet switch to connect the same ipaddress to the same real server, so
> that mmaps() are properly shared and all. We might want
> per-mailbox locks so that only one real server can open a specific mailbox
> (but do so multiple times) but I'll figure that one out later.

OK. I think this could be fixed internally too. Or this is mostly a
problem with index files, mbox/maildir files are currently re-mmap()ed
every time they're accessed (but I'll change mbox not to do that later).

Indexes currently have "sync_id" in their header, it's changed whenever
the file size is changed so other processes then know to re-mmap() it.
This could be optionally changed to be updated every time the file
itself has changed to force others to mmap() again. The sync_id change
itself could be checked using lseek() + read().

If fstat() or stat() doesn't show mtime changes, that could be a bit
worse problem. I think I'm relying on that with some things.. At least
new mail is checked by seeing if Maildir/cur's mtime matches
.imap.index's mtime.