True, this is best determined empirically, but my last opportunity to do such an experiment was several years ago, and I no longer have access to AFS source to assist my inquiries with source code inspection. If an AFS client has a file in a r/w volume open for writing, has been writing data for that file into its cache, and its AFS server reboots either before the close() or, perhaps, after the close() initiates, but before the file is completely stored on the server, what is the expected behavior? What return values/errnos are provided by the write() and close() system calls, and what guarantees (if any) can be given as to what actually managed to be stored on the server? Will the open file handle still be valid after a server reboot? Stuff like that... My memory is hazy from an experiment we performed a few years ago, so I don't put much trust in it, but I seem to remember that changes to the file seemed to be lost, though the test programs which ran during this experiment weren't particularly agile with write() and close() return values. I'm asking this in the context of beginning (only beginning) to investigate making AFS file servers "highly available" using a cluster of machines. A file server reboot is roughly analogous to another processor taking over a server's IP address and server functions after a processor failure. -- Steve Dyer [EMAIL PROTECTED]
