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

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: Piete Brooks
Data:  
Para: Christoph Lameter
CC: exim-users
Asunto: Re: NFS Problem in Kernel 2.0.27: inode status not updated
>>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.
> Please do not add this. Instead include the patch and mention the version
> number of the kernel fixing this problem as soon as it is released.


After private correspondence with PH10 I have come to a new realisation as to
the problems we are addressing here ...

As I see it, there are two:
1) locking for delivery to a FS which happens to reside on a remote NFS server
2) locking between multiple systems (e.g. MTA and MUA)

The first is a simple (IMHO) bug in the Linux NFS code (with fix in hand) such
that even if *this* system just created a new link, the link count was not
incremented.

The second is a general problem when *REAL* locking (lockd isn't available
for Linux -- if it were, we wouldn't be using hitching posts !) isn't available
so that hitching posts are used.
All systems concerned need to have accurate information, and not rely on so
called "cache"s (actually hints with TTLs).

>>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"?
> Yes. But we want speed. I think we rather change the NFS code than
> using the noac option. That is the difference to commercial OS. You
> can simply change things if necessary.


yes -- the "bug" (1) needs fixing [[ I've been told that this sometimes even
happens with commercial OSes :-) ]], so that *delivery* can occur correctly.

I suspect MUA / MTA considerations require (2) *as well*, but it may be that
there is no negative caching, or the code is smart enough, or ...
Can any hitching post users (other than Linux -- are there any ?) comment on
whether hitching post locks work between different hosts (both NFS clients) ?
[ I mean **RELIABLY** work ... ]