[OpenAFS] Re: reading files from problem volume

Andrew Deason adeason@sinenomine.net
Thu, 22 Aug 2013 16:10:41 -0500

On Thu, 22 Aug 2013 14:24:41 +0000
"sabah s. salih" <sabah.salih@hep.manchester.ac.uk> wrote:

>  Dear All,
>       We have the following case. Is there away where we could recover
>       files from this volume please.

Nothing you've shown so far indicates the actual data in that volume is
gone, so possibly. But the salvager is failing rather early, so it's
hard to tell if anything may be missing.

> 08/22/2013 09:04:31 CHECKING CLONED VOLUME 536872682.
> Unable to open inode (Volume information) of volume header (error = 2)

That is not supposed to happen; this looks like a bug. Before you change
anything, could you save a copy of the files in /vicepX so we can avoid
this from happening in the future? Save the files from these paths:

/vicepcc/AFSIDat/e1/eP++U (if this exists)
/vicepcc/V0536872682.vol (if this exists)

If that's too much data to save, then just saving these may also be

/vicepcc/AFSIDat/e1/eP++U/special (if this exists)
/vicepcc/V0536872682.vol (if this exists)

But please also save at least a file listing of what files are under
/vicepcc/AFSIDat/e1/eP++U and /vicepcc/AFSIDat/Z=/Zh++U. (e.g. run 'ls
-lR' or a 'find /vicepcc/[...] -ls')

So anyway, focusing on trying to make that volume accessible... it looks
like the only problems reported are with a cloned volume 536872682; the
RW volume itself has not been touched. I have a guess as to what may be
causing the above bug, but can you try looking around the mentioned
directories above for files with one of the following names:


Those files are supposed to be in a directory of the form
/vicep*/AFSIDat/*/*/special/. If you find them somewhere else (for
example, /vicepcc/AFSIDat/Z=/Zh++U/+/O/zzzz5ci=++0), you can probably
delete them; or to be safe, just move them somewhere outside of
/vicepcc, in case you do need them for something. If you do delete/move
any such file, ideally you should do while the fileserver processes are
shut down. If you don't want to do that, you could possibly copy all of
the file paths I listed above to a new, non-production fileserver, and
fiddle with the files on there.

If you do delete/move the relevant files, you should try salvaging the
volume again, and hopefully it will become available. From there you
should be able to access the volume normally, or if you moved the files
to a different fileserver, you should be able to 'vos dump' it, and
restore the files elsewhere.

> /usr/afs/bin/volinfo /vicepcc | grep kiran
> Volume header for volume 536873829 (kiran)

I could look at the output for

/usr/afs/bin/volinfo /vicepcc 536872682

to see what it says about volume 536872682. (before doing the above
file deletion stuff)

Andrew Deason