[3303] in Athena Bugs
AFS write-not-through
daemon@ATHENA.MIT.EDU (David Krikorian)
Tue Sep 26 17:52:39 1989
Date: Tue, 26 Sep 89 17:52:11 -0400
From: David Krikorian <dkk@ATHENA.MIT.EDU>
To: bugs@ATHENA.MIT.EDU
Reply-To: dkk@ATHENA.MIT.EDU
As far as I can tell, if a user spends days editing one file (but not
close()'ing that file) that is on an AFS filesystem, and the (client)
workstation crashes, the *entire* file may be lost unless someone
knows enough to search through cache files immediately after reboot.
For example, user joe spends 96 continuous hours in late May editing a
file called thesis.mss. He does a save-buffer every 60 seconds
because he's so worried about losing the file. He previews the file
on the workstation display, finalizes it, and prepares to print out
the final copy. The workstation crashes. After trying to read the
file on another workstation, he finds it's not all there. He panics.
He shows up at the door to e40-391 waiting for the Directors to show
up so he can plead with them. In the meantime, another user has used
the rebooted workstation, displacing the thesis from the AFS cache.
What do we have that might prevent the above scenario from happening?
I've often heard "that's why AFS is considered experimental." Then
what are we doing to prevent this from happening when AFS goes to the
public?
You may argue that the above example if far-fetched. I disagree.
This problem (open files not being written to the server) is most
acute where we can least afford it. That is, the people who lose the
most are those who are spending many hours working on one
project/report/thesis. Few people in that situation exit their editor
and restart it (or kill the buffer and re-read the file) in the middle
of their work.
Could we have a once-per-hour write-out of the cache? Failing that,
could emacs and ez be modified to close and re-open files if they are
vulnerable (however that is determined)?
