[OpenAFS] Re: Offline volumes after upgrade to 1.6.1pre2

Andrew Deason adeason@sinenomine.net
Thu, 23 Feb 2012 13:57:34 -0600


On Tue, 21 Feb 2012 10:32:12 +0100
Åsa Andersson <spigg@csc.kth.se> wrote:

> > Can you provide the SalvageLog for one of these runs? That is, for the
> > salvage that you did right after the 'inconsistent length' error.
> 
> Here is a typical example:
> 
> -------------
[...]
> 02/17/2012 13:41:07 CHECKING CLONED VOLUME 537173357.
> 02/17/2012 13:41:07 home.7.u1unk8i7.backup (537173357) updated 02/10/2012 14:43
> 02/17/2012 13:41:07 Vnode 15302: length incorrect; (is 524288 should be 262144)
> 02/17/2012 13:41:07 SALVAGING VOLUME 537173355.
[...]
> 02/17/2012 13:41:11 Salvaged home.7.u1unk8i7 (537173355): 12354 files, 298420 blocks
> 02/17/2012 13:41:11 SYNC_ask: negative response on circuit 'FSSYNC'
> 02/17/2012 13:41:11 FSYNC_askfs: FSSYNC request denied for reason=101
> 02/17/2012 13:41:11 AskOnline:  file server denied online request to volume 537173357 partition /vicepa; trying again...

Thanks. This is due to some of the more odd parts of the salvager design
(and I think has been around for a while)... an RO volume in this
environment that is "bad" because of volume data (but the volume
metadata is fine) will currently cause the volume data to go away, but
the headers and stuff will stick around. So after one salvage, the RO
volume is unusable until you salvage it again and the RO volume is
deleted because there's no data associated with the headers.

This is not quite as a noticeable with DAFS because, among other
reasons, the volume will just get salvaged automatically twice.

I think the patches I've submitted in gerrit 6783-6787 will fix this
situation. But it shouldn't be too urgent for you or anything; you
should be fine if you just salvage the relevant volumes twice as you
have been doing. So if you're fine with how your environment is now,
there's nothing further you need to do.

-- 
Andrew Deason
adeason@sinenomine.net