guy@netapp.com (Guy Harris) writes:

That still doesn't describe the full scenario. If somebody merely writes to a file - in the sense of "does a 'write()' to the file" - that will *NOT* cause ESTALE to occur on other clients - there's no reason for it to occur.

If the full scenario has "writes to a file" meaning "unlinks the file, creates a new file with the same name, and writes to *that* file", that's the scenario I described in earlier mail.

Well, since the file hadn't been recently modified, I wasn't able to come up with any scenario that could apply. It looks more likely that the NetApp was sent an incorrect file handle (or didn't receive the correct one).

What level of consistency checking does NFS v2 over UDP provide?

...

It may be generally useful for NetApp to publish all of the known cases where different (legitimate to the NFS specification) errors can be returned from Network Appliance servers.

"Different" in the sense of "different from, say, a Sun server"?

"Different" as in "various" or "different types of errors".

I presume "overwritten" here means "removed and rewritten", as per the above.

Yes it does, please forgive my imprecise language.

If the client is assuming that a file with inode number XXXX (as returned by an NFS "getattr" call) is the same file as a file that had inode number XXXX on the same mount from the same client at some point in the past, the client is buggy - it cannot validly assume that, given the scenario I outlined in earlier mail.

I'll ask the local experts about that.

Linux 2.1.x (x > 42) also has a directory/file name cache that hashes names to "dentries" that include a pointer to the inode structure.

- Dan