[Dovecot] Re: 0.99.10.5 release candidate

[Timo Sirainen]

On Sun, 2004-05-30 at 11:32, Brian Candler wrote:
> For POP3 access, I'm happy for no locks to be in place at all. If someone is
> daft enough to make two concurrent POP3 accesses to the same mailbox, then
> at worst what happens when they try to retrieve a message is they'll get
> 
>   -ERR This message has been deleted by someone else!
> 
> or something like that. I can live with that.

That's what Dovecot does now.

But that isn't the worst if you have no locks at all. You still want to
lock the mailbox while it's being read or written, otherwise there would
be either mailbox corruption (two writers at the same time) or user
could be sent corrupted mails (one reading while another is writing).

> Dotlocks are a pain when you have multiple frontends on an NFS server,
> because it's impossible to tell if they're stale (they may contain the
> information that they were created by server B pid P, but if you're on
> server A, you can't tell whether process P is still running on B or not)

Dovecot does what mutt does. If dotlock exists and mailbox or the
dotlock isn't modified in 30 seconds, it's overridden. Hmm. Although
that might be a bit too aggressive, just reading a large mailbox could
take long and that wouldn't modify it..

> If it were felt that locking were important, then I'd propose a simple lock
> server process: a client opens a TCP connection to this process, sends the
> name of the mailbox it wants to lock, and gets an ACK back. If the client
> dies then the TCP connection is dropped and the lock is released. 

I think nfs.lockd does pretty much that, except the client OS must
notify if process dies without releasing lock. If the whole computer
gets lost, .. I guess the lock stays there for a long time?

> I can see
> issues with numbers of filehandles/sockets on the lock server process
> itself, so you'd have to tweak kernel parameters on a busy system. Perhaps
> you could have a pool of lockserver processes listening on different ports,
> and use a hash of the directory name to work out which one to connect to?

Might be useful, but you'd probably want to have redundancy as well as
load balancing. Might not be that easy to implement.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20040531/3d77fb81/attachment.pgp