On Aug 23, 2012, at 1:14 PM, [email protected] 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 salvaged" > 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 decade. > (mostly in "can't remove" or "can't clean up after ab-ended move" contexts.) > 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. Steve_______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
