[OpenAFS] Re: volume offline due to too low uniquifier (and salvage cannot fix it)

[Andrew Deason]

On Tue, 16 Apr 2013 10:57:13 +0000
Jakub Moscicki <Jakub.Moscicki@cern.ch> wrote:

> The salvage subsequently says that it fixed it but in reality nothing
> changes. Here is the salvage output:

"nothing changes" as in, the volinfo output doesn't change at all? Or
it's just that the problem doesn't go away?

> ======
> >>>Tue Apr 16 11:34:06 2013: /usr/afs/bin/volinfo -part /vicepac -vol 1934053454 -fixheader

I wouldn't run with -fixheader unless you have a reason for it. You
don't want volinfo rewriting metadata while other procs are running (it
doesn't check out volumes with fssync or anything). Not that it did
anything here, but just saying.

[...]
> type = 0 (read/write), uniquifier = 638, needsCallback = 0, destroyMe = 0
[...]
> >>>Tue Apr 16 11:34:07 2013: /usr/afs/bin/salvager /vicepac 1934053454 -showlog -orphans remove

What is the largest uniquifier in the volume? If you run volinfo with
-vnode, it will dump the vnode indices. The uniquifier is the third
number you see, for example:

Small vnodes(files, symbolic links)
         0 Vnode 2.607.1 cloned: 0, length: 21 linkCount: 1 parent: 1

That's index file offset 0, vnode 2, uniq 607, DV 1.


And if I recall correctly, you're running with modifications to the
small vnode magic, but it looks like you're not running with
BITMAP_LATER? (Those touch code near where that fileserver error
occurs.)

-- 
Andrew Deason
adeason@sinenomine.net