> compatible to linux page cache will always to be a better practice > way, because there is a lot local applications that has already rely > on its semantics. I don't think users even *know* how the page cache behaves. I don't think even its developers do, in the sense of being able to define it in sufficient detail for formal verification. Instead certain cases are intentionally left undefined - the "odd behavior" Ric mentioned - and can change any time the implementation does. What users have are expectations of things that are guaranteed and things that are not, and the wiser ones know to stay away from things in the second set even if they appear to work most of the time. As Raghavendra Talur points out, we already seem to provide normal linearizability across file descriptors on a single client. There doesn't seem to be much reason to change that. However, I still maintain that there's little value to the user in trying to satisfy stricter POSIX guarantees or closer approximations of whatever the page cache is doing that day. That's especially true since we run on multiple operating systems which almost certainly have different behavior in some of the edge cases. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
