On Tue, Feb 01, 2005 at 07:30:12PM +0100, Thomas Glanzmann wrote:
> Hello,
>
> > This simply can't be guaranteed across platforms. Which locking
> > mechanisms work (i.e. aren't broken) on NFS vary from platform to
> > platform, release to release.
>
> Some alternatives which come to my mind:
>
> - When opening the header cache, open it twice and see if the
> second call fails. - Otherwise refuse to use it.
I guess I'm missing something... What would cause the second open to
fail? How does this prevent contention?
> - Use locking mechanism which works always: Creating a file is
> atomar AFAIK.
This DOESN'T work always, which is exactly the point I was trying to
make before. There is NO method which works always.
Creating a file may be atomic, but this alone is not enough to ensure
the lock. Unless used with O_EXCL, creating a file won't fail if the
file already exists. Thus, there is no way to atomically create the
file and to alsu be sure that WE created the file, unless we also use
the O_EXCL flag. The following is from the Linux man page for
open(2):
O_EXCL When used with O_CREAT, if the file already exists it
is an error and the open will fail. In this context,
a symbolic link exists, regardless of where its points
to. O_EXCL is broken on NFS file systems, programs
which rely on it for performing lock- ing tasks will
contain a race condition. The solution for per-
forming atomic file locking using a lockfile is to
create a unique file on the same fs (e.g.,
incorporating hostname and pid), use link(2) to make
a link to the lockfile.
Thus, this method doesn't work either. Now, as it happens, the guy
who maintained nfs-utils for about 3 years from 2000-2003 (this is
rough, from memory) is a friend of mine, and he told me that using
link(2) for locking is also broken, though I don't remember why.
According to him, the only method of locking which works reliably on
NFS is to use the POSIX locking calls, but THAT only works for sure if
both server and client are Linux, and if the server is running
nfs-utils greater than some version which I don't recall...
Then, if you have a heterogeneous network where the server is NOT
Linux, very often statd or lockd (or both) are broken, preventing
locking from working properly using POSIX locking calls.
Botom line: For all intents and purposes, locking over NFS is not
reliable. Ever.
> - Add extra code which gets sure that hcache database isn't
> stored on NFS.
Is there a portable way to determine that reliably?
> - Make the cache (optional) session local. That way at least
> sucessive opens of the same mailbox are fast.
This should work, but it does mean you'd have to be careful about not
leaving old copies of the cache laying around, and reduces the benefit
of having the cache.
Personally, I think a caution in the manual in bold red lettering to
keep the cache on local storage should suffice. That, and leaving the
cache disabled by default. But I still think the risks are minimal...
What are the odds that a user will try to run two copies of mutt in
sufficiently little time as to cause a potential lock contention
problem on the same header cache database? Seems exceedingly low to
me.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgpulHH3zcmAb.pgp
Description: PGP signature