On Tue, 21 Feb 2012 10:32:12 +0100 Åsa Andersson <[email protected]> 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 [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
