On Mon, 2003-02-24 at 03:09, Hartmut Reuter wrote: > Norman P. B. Joseph schrieb: > > I have a replicated volume (on the same server and partition as its RW > > volume) that won't attach, and won't respond to salvaging. Here's the > > SalvageLog entry when salvaging the single volume: > > > > # bos salvage sun43 s 536871053 -showlog > > [...salvaging...] > > SalvageLog: > > @(#)Base configuration afs3.6 2.5 > > 02/21/2003 10:56:29 STARTING AFS SALVAGER 2.4 (/usr/afs/bin/salvager /viceps > > 536871053) > > 02/21/2003 10:56:40 Scanning inodes on device /dev/rdsk/c2t0d2s6... > > 02/21/2003 10:57:07 No applicable vice inodes on c2t0d2s6; not salvaged > > Temporary file /viceps/salvage.inodes.c2t0d2s6.2142 is missing... > > I had a similar effect some days ago in MR-AFS and it turned out that > the reason was that the field to keep the file name > /viceps/salvage.inodes.c2t0d2s6.2142... was too short. So it had created > the file, but the name he was looking for was cut off at the end. Have a > look into vol-salvage.c! Seems to be a problem on Solaris with its long > device names.
Not that I doubt your diagnosis, Harmut, (and thanks for the response), but "c2t0d2s6" is a long name? And anyways, it seems long past the time that we should be expecting dynamically generated pathnames fit into fixed-length buffers. Regardless, all the file servers here are running Transarc AFS under Solaris 7, and I don't recall running into this problem before, having done many salvages. What might have tickled this particular bug? > > How do I recover from a volume that won't salvage? Being a clone, will > > a "vos remove; vos addsite" work on this volume? > > The real reason for my post is this: In practical terms, I have a clone volume that I can't seem to salvage, but neither can I delete it or "zap" it, or re-release the volume as long as this bad clone exists. Does anyone have any advice for recovering from this position? I can only imagine doing something like "vos remsite" for that volume and then pretending it doesn't exist anymore, but that leaves a bad taste in my mouth for obvious reasons. -- Norman Joseph, Systems Engineer [EMAIL PROTECTED] IC|XC Concurrent Technologies Corporation 814/269.2633 --+-- Global Systems Center NI|KA *** Be kind, for everyone you meet is fighting a great battle *** _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info