Re: [nfsv4] RE: Finding hardlinks

[Peter Staubach <staubach@redhat.com>]

Bryan Henderson wrote:
>>>> "Clients MUST use filehandle comparisons only to improve
>>>> performance, not for correct behavior. All clients need to
>>>> be prepared for situations in which it cannot be determined
>>>> whether two filehandles denote the same object and in such
>>>> cases, avoid making invalid assumptions which might cause incorrect 
>>>>         
> behavior."
>   
>>> Don't you consider data corruption due to cache inconsistency an 
>>>       
> incorrect behavior?
>   
>> Exactly where do you see us violating the close-to-open cache
>> consistency guarantees?
>>     
>
> Let me add the information that Trond is implying:  His answer is yes, he 
> doesn't consider data corruption due to cache inconsistency to be 
> incorrect behavior.  And the reason is that, contrary to what one would 
> expect, NFS allows that (for reasons of implementation practicality).  It 
> says when you open a file via an NFS client and read it via that open 
> instance, you can legally see data as old as the moment you opened it. 
> Ergo, you can't use NFS in cases where that would cause unacceptable data 
> corruption.
>
> We normally think of this happening when a different client updates the 
> file, in which case there's no practical way for the reading client to 
> know his cache is stale.  When the updater and reader use the same client, 
> we can do better, but if I'm not mistaken, the NFS protocol does not 
> require us to do so.  And probably more relevant: the user wouldn't expect 
> cache consistency.

This last is especially true, the expectations for use of NFS mounted
file systems are pretty well known and have been set from years of
experience.

A workaround is provided for cooperating processes which need stronger
consistency than the normal guarantees and that is file/record locking.

    Thanx...

       ps