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

Top Page
Delete this message
Reply to this message
Author: Piete Brooks
Date:  
To: exim-users
Subject: Re: NFS Problem in Kernel 2.0.27: inode status not updated
>> 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"?


I am confused here ....

Does it need ONE of the two fixes mentioned above, or BOTH ?
I would assume that one had to request noac (or at least acregmax=0) if using
that form of locking, but looking back, I do not see that stated explicitly.
Can someone clarify ?