Re: NFS Problem in Kernel 2.0.27: inode status not updated

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: Christoph Lameter
CC: exim-users
Old-Topics: Re: NFS Problem in Kernel 2.0.27: inode status not updated (fwd)
Subject: Re: NFS Problem in Kernel 2.0.27: inode status not updated
On Mon, 30 Dec 1996, Christoph Lameter wrote:

> Here is the official answer from the author of the NFS code in Linux.


[snip]

> There is nothing in the NFS spec that requires the client to update its
> cached link count[*]. So I would assume the author's claim means that this
> locking technique `works better over NFS on the systems I tested it on.'


"The author" in this case isn't really me - I copied this algorithm from
Pine.

> Nevertheless, I guess I'll have to support this in the upcoming NFS
> code... For the time being, I suggest exim users apply the following
> patch to fs/nfs/dir.c, function nfs_link:


I will add this note to Exim's README file.

>        noac           Disable  all  forms  of  attribute  caching
>                       entirely.  This extracts a  server  perfor
>                       mance  penalty  but it allows two different
>                       NFS clients to get reasonable good  results
>                       when  both  clients are actively writing to
>                       common filesystem on the server.

>
> This would also solve the problem but gives a performance hit.


But surely a mail spool is precisely the case of two different NFS
clients (the MTA and the MUA) "actively writing to a common filesystem
on the server"?

--
Philip Hazel                   University Computing Service,
ph10@???             New Museums Site, Cambridge CB2 3QG,
P.Hazel@???          England.  Phone: +44 1223 334714