[OpenAFS] re doing rm in /vice*

Steve Simmons scs@umich.edu
Thu, 23 Aug 2012 14:55:46 -0400

On Aug 23, 2012, at 1:14 PM, rader@hep.wisc.edu wrote:

> We have an AFS filserver running openafs-server-1.4.14-80.1.sl5.
> We had to salvage one of it's RW volumes after a reboot.
> But then it's backup volume that wouldn't attach, "needs to be =
> Yet salvage said "read-only volume; not salvaged"
> I couldn't vos remove nor vos zap.
> So I removed the .vol file and did "bos restart"
> Then I was able to revive the volume with "vos backup".
> I've been using this shootgun approach for horked volumes for over a =
> (mostly in "can't remove" or "can't clean up after ab-ended move" =
> So, I'm wondering: should I be a little more gentle?  How??

Gentleness is always good. As others have mentioned, you need to salvage =
the RW vol, not the RO.

Since you were destroying and recreating the .backup volume as part of =
the process, did you try doing a 'vos backup' on the volume?

Why you couldn't vos zap a .backup volume seems odd to me. It works on =
our systems (1.4.16). Doing 'vos remove <volname>.backup' also worked.

Removing the .vol file does have some downsides. In particular, it =
eventually convinces the server that it doesn't have a copy of the =
volume, but you never get back whatever space was actually consumed by =
files which older versions lying around. If that's a small amount, you =
can ignore it. If it's a significant amount, you may want that back. The =
only way I know of to get it is to vos move everything to another =
server, then salvage the entire partition. Vague memory tells me that =
doesn't always help; in such cases I had to take the partition offline =
and do a mkfs on it. I suppose one could simply go in and manually =
delete everything in /vicepX/AFSIDat/* that isn't a directory, but that =
idea always gives me hives.