Re: Data coherency trouble with multiple clients, on2.6.14-rc5

[Peter Staubach <staubach@redhat.com>]

Trond Myklebust wrote:

>on den 26.10.2005 klokka 14:45 (-0400) skreiv Peter Staubach:
>
>  
>
>>It seems to me that the policy should be to allow cache 
>>validation/invalidation
>>unless the file is mmap'd for writing or if there are active WRITEs 
>>outstanding.
>>Simply having the file open for write should not affect the consistency 
>>model.
>>    
>>
>
>That is what we did for 2.4.x, but what kind of extra guarantees does
>that really bring you? You cannot actually rely on it to provide
>stronger caching semantics than the close-to-open case.
>

This brings lots of extra guarantees, actually.  Just because the file is
open for writing does not mean that there are any dirty pages hanging
around waiting to be written.  And, even if there are, they will get
flushed when the conflict is detected.  Last there one there wins.  This
is even the policy when local processes conflict on the same file in the
same region.

This policy would address the situation that was reported here.

This policy will definitely result in _much_ stronger caching semantics
than does close-to-open.  These two policies together can usually result
in reasonable cache consistency, enough for most applications.  Applications
which need stronger cache consistency should be advisory locking in order
to synchronize access to the file.

       ps


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs