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

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Piete Brooks
Fecha:  
A: exim-users
Asunto: 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 ?