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
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
