On Wed, 2010-06-16 at 15:19 +0200, Oliver Eales wrote: > Am 19.05.2010 10:51, schrieb Timo Sirainen: > > As http://wiki.dovecot.org/NFS describes, the main problem with NFS has > > always been caching problems. One NFS client changes two files, but another > > NFS client sees only one of the changes, which Dovecot then assumes is > > caused by corruption. > > > > host = vhosts[ md5(username) mod vhosts_count ] > > > > Hello Timo, > i am currently playing around with the new director service and i am > really looking forward for it in 2.0 > Wouldn't it be better to use a consistent hash function instead of the > md5 ? > So that you would only get a new assignment of users belonging to the > failed server and not a "complete remapping".
I thought about it first, but then thought it would only make it more complex without much benefits. > With this setup it might be possible to store local indexes in a NFS > Backend setting, as the users stay kind of sticky to their server. Well, this would be a benefit that I didn't think of. :) Maybe it could be done in future. > And there would also be no need for the distribution of the currently > active mappings within the ring. Maybe only for the state for the servers. I think it's still needed. Maybe not all mappings, but at least when new servers are added. For example if server2 handles users A and B, and a new server3 is added. Now server2 would handle A and server3 would handle B. But server1 would still need to know that server2 would still have to handle B until it timeouts (B user can't just be moved to server3 without killing its existing connections, which doesn't sound like a good idea).