[2133] in SIPB-AFS-requests
n.foo volumes
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Thu Sep 7 16:25:02 1995
From: Jonathon Weiss <jweiss@MIT.EDU>
To: sipb-afsreq@MIT.EDU
Cc: yoav@MIT.EDU, probe@MIT.EDU
Date: Thu, 07 Sep 1995 16:24:44 EDT
Someone (yoav?) created a volume n.project.bsdandrew. It has not been
the case that the SIPB cell supports the convention that n.foo volumes
are not backed up. (This is the convention itn the athena cell, but
the sipb cell has used foo.nb.) I updated the do-backups.pl script so
that it should support this convention now, although I have not tested
it. I have also removed the backup volume for n.project.bsdandrew so
it won't be backed up.
I discovered that despite what vos remove said, the entry for
n.project.bsdandrew.backup remained in the vldb and reported errors
about the volume not being where the vldb said it was. I did the
following:
the-other-woman:/afs/sipb/project/newdump/scripts: vos delentry -help
Usage: vos delentry [-id <volume name or ID>+] [-prefix <prefix of the volume whose VLDB entry is to be deleted>] [-server <machine name>] [-partition <partition name>] [-cell <cell name>] [-noauth ] [-localauth ] [-verbose ] [-help ]
the-other-woman:/afs/sipb/project/newdump/scripts: vos delentry n.project.bsdandrew.backup ra c -c sip -verb
vos: can't find volume 'ra'
vos: can't find volume 'c'
Deleted 1 VLDB entries
Don't ask me why the argument parsing failed. But the command
cleverly nuked the vldb entries for BOTH the volume and the backup
volume!
For lack of a better option I syncvldb'd the relevant partition; and
guess what...It put BOTH entries back, despite the fact that the
backup volume didn't exist!
At this point I gave up.
Could this be a 3.2 server vs. 3.3 client problem?
If anyone has any bright ideas, I'd like to hear them.
Jonathon
