On Mon, 2002-10-21 at 17:19, Thomas Wouters wrote:
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.
Just had a thought. Would it be feasible to _try_ to permanently assign users to one or few specific servers (via ip or maybe login proxy)? If those servers were down, it could fallback to any random one.
I was thinking Dovecot's indexes could just as well be stored in local hard disk - they're not required to exist and they're not required to be in sync when opening, so it's possible to keep multiple indexes lying around in different servers.
That would take care of most of the mmap() and locking problems and should make it perform a _lot_ better than through NFS. I don't know how NFS works internally, but I doubt it has any way for remote OS to determine what parts of file has changed, so re-mmap()ing would most likely always reread the whole file (or the parts that it accesses) which is quite inefficient.
I really like this idea, keeping indexes in local disk where they may be considered as fast non-permanent data and then reading the actual mail data via backed up NFS server. This gets me thinking of a lot more possible optimizations to reduce NFS I/O at the cost of more local.. :)