Mail locking and NFS caches.
As far as I know, the current Debian mail locking mechanism is
dotlock-based.
The message included below (which has been taken from a discussion
on #39030) indicates that this mechanism should be augmented to
include POSIX locking (fcntl) in order to invalidate any caches.
Note that the use of POSIX file locking should be made MANDATORY for
any mail delivery and user agents. Otherwise, you risk loss of data
with NFS-mounted spools.
Kind regards, Thomas Roessler
(upstream maintainer of Mutt)
----- Forwarded message from Olaf Kirch <okir@monad.swb.de> -----
Date: Thu, 19 Aug 1999 20:41:21 +0200
From: Olaf Kirch <okir@monad.swb.de>
To: mutt-dev@mutt.org, 39030@bugs.debian.org,
"Marco d'Itri" <md@linux.it>,
Roland Rosenfeld <roland@spinnaker.rhein.de>,
Alan Cox <alan@LXORGUK.UKUU.ORG.UK>, "H. J. Lu" <hjl@lucon.org>,
Herbert Xu <herbert@debian.org>, Anders Hammarquist <iko@iko.pp.se>,
nfs-devel@kernel.org
Subject: Re: mutt / NFS / Linux 2.2 / debian bug #39030
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6us
On Thu, Aug 19, 1999 at 07:09:22PM +0200, Thomas Roessler wrote:
> The behaviour we are observing is that even _read_ (2) calls don't
> give current file content, but seem to read from some kind of cache
> with 2.2's default NFS client configuration.
Indeed, that's the point. For 99% of all uses of NFS you do want to
have a local cache that keeps the file's content, possibly indefinitely.
The standard NFS strategy is to validate the file's attributes from time
to time, and if some tell-tale attributes have changed, such as file size
or mtime, to discard the cached data. This means that you usually have
to wait between acregmin and acregmax 10ths of a second before the client
notices the file has changed on the server.
Except if you, as a side effect of some other operation, force the
cached attributes to be invalidated.
> This means that we have _absolutely_ _no_ _way_ to confirm that a
> file accessed via NFS is empty, or unmodified, unless we can
> guarantee we have been the last process to modify said file, or have
> switched off attribute caching.
Yes, unless you use NFS file locking (see below).
> Personally, I'd expect the client configuration to permit the user
> to disable data caching independently of attribute caching.
There is currently no established mechanism to turn off caching of either
attributes or data on a per-file basis. If Linux was to implement
an ioctl for this, you would still run into trouble on other systems.
> I'd also hope that the default client configuration goes without data
> caching, as this may imply quite a few ugly surprises for users.
No, this is the default. Admittedly it does surprise users from time
to time, but turning off data caching by default would make NFS kind
of unusable (do you remember NFS in the 1.0 kernels?).
However you can make the kernel discard the cached attributes/data.
If you have NFS file locking, then establishing or releasing a lock
will invalidate the cache for that file.
Caveat: This won't do anything if you _dont_ have NFS file locking turned
on. If you don't intend to use NFS file locking, you may want to patch
nfs_lock() to do this and see if it helps:
------------------------------------------------------------------
linux/fs/nfs/file.c
@line 215
/* Fake OK code if mounted without NLM support */
if (NFS_SERVER(inode)->flags & NFS_MOUNT_NONLM)
- return 0;
+ goto out_okay;
@line 240
/*
* Make sure we re-validate anything we've got cached.
* This makes locking act as a cache coherency point.
*/
+out_okay:
NFS_CACHEINV(inode);
return 0;
------------------------------------------------------------------
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir@caldera.de +-------------------- Why Not?! -----------------------
UNIX, n.: Spanish manufacturer of fire extinguishers.
----- End forwarded message -----
Reply to: