[1158] in SIPB-AFS-requests
Re: sipb0
daemon@ATHENA.MIT.EDU (mhpower@mit.edu)
Mon Oct 11 17:58:59 1993
From: mhpower@mit.edu
To: ckclark@mit.edu
Cc: sipb-afsreq@mit.edu, sipb-staff@mit.edu
In-Reply-To: "[1157] in SIPB-AFS-requests", "[1448] in SIPB_Staff_Archive"
Date: Mon, 11 Oct 93 17:57:42 EDT
> ... There were many, many files in the
>directory; it looked as if someone copied his/her home directory into
>sipb0 and used it.
I took a quick look at user.sipb0.backup before the volume cloning
this afternoon. It looked like a lot of the files I'd put there a few
months ago were still around. What had happened was a problem was
reported in which some of a user's dotfiles would disappear from ~
without being explicitly removed. The problem was not repeatable,
however, although there was some evidence that it was triggered by
multiple accesses to large afs directories, possibly including access
via the afs-nfs translator.
To test this out, I created a bunch of files and directories, some of
which had typical names (e.g., .article, .learnrc, Classes) although
some would strike us as a bit suspect (e.g., .lsrc, .newsrc.mine).
Most of them were small/empty, and didn't put the volume over quota.
> ... The sipb0 account, unlike the other sipbn accounts, is for
>testing, not for guests.
Right, I tried to repeat the file-loss problem by having a lot of
simultaneous access to the sipb0 volume from quiche and some other
clients, but, if I remember incorrectly, there was a raid by PETS and
we ended up with an order to suspend all afs code testing. In any
case, the problem was never repeated. I think it was later figured
out that the apparent file loss was caused by user error.
Of course, anyone can remove whatever old files they don't want in
sipb0 anytime they want; I'm just trying to explain what was going on.
Matt
