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
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
