On Tue, 16 Apr 2013 10:57:13 +0000 Jakub Moscicki <jakub.mosci...@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 adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info