[Pvfs2-developers] Review: experimental readcaching code

[Murali Vilayannur]

Hi Pete,

> But close-to-open consistency semantics allows that, right?  On
> close, local modifications are flushed to the server.  On open, a
> client checks to see if its local cache is still valid (timestamp
> based or whatever).  If two processes open the file, make
> modifications, then one closes the file, the second process will
> not try to merge the changes from the first---it will just overwrite
> (parts of) the entire file.  I don't think "nonoverlapping offsets"
> guarantees that contents will be merged.

Oh ok.. this is what I wanted to hear :)

> Oh, for MPI, it will certainly cause problems.  ROMIO on NFS relies
> on a working fcntl, doesn't it?  They go beyond CTO to get
> correctness.

Ah I see. So that's how ROMIO works.. Cool then.
My only concern was that if we do write buffering, we should not break MPI I/O.
So perhaps, we also need to implement a very simple file lock manager,
fcntl support.
We would also require that ROMIO's ufs driver use the fcntl trick if
statfs() on the mount point returns pvfs2 sb magic number or
something..
In fact that brings me to the question, does ROMIO figure out if a
mount point is a regular ufs mount point or a nfs mount point
automatically?

>
> I'm kind of not seeing the point of doing any optional write
> buffering with CTO semantics in the first place.  If we really want
> a consistent, write-cached distributed file system we should just
> grab an existing DLM and use it and client callbacks to manage
> cached ranges.  But that's something that interests me not at all.

Hehe. Absolutely agreed. I dont want to go there also. Further, Avery
is working on some
prototypes for solving this problem differently.
thanks for the clarifications!
Murali

> (The read buffering you're doing is different.  That makes some
> sense for files that are marked as "known readonly", as you have
> implemented it.)
>
>                 -- Pete
>