Harald Barth wrote:
A write error might be caused by a failure in the communication
path between the client and the file server. Such a failure should not
result in the data being discarded from the cache.
So we just told the user (by returning error on the close) that the
file is bad, but subsequent reads should proceed as everything went
fine? If we can guarantee to obain consistency at a later point, the
close should not have returned failiure in the first place. You can't
have it both ways. Until someone implements disconnected AFS and fixes
the writeback later, I suggest to throw away the data which never will
make it to the server.
The problem is that you are forgetting about the memory mapped file
case. I'm not sure about on UNIX/Linux but on Windows, there are three
phases:
* open - application obtains a file descriptor
* cleanup - application closes a file descriptor
* close - operating system releases the file
Between the cleanup and the close file access will continue if the
file has been memory mapped. The cache manager cannot discard the
writes because doing so would corrupt any memory mapped regions.
You have a valid point. It raises a the question of whether or not
close() should be given an error if the reason for the error is that the
server is unreachable.
On Windows there are non-fatal errors and in response to the close an
informational error can be returned. Again, I don't know about UNIX/Linux.
Jeffrey Altman
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
