On Tue, 1 Mar 2011 18:57:50 -0500 (EST) Andy Cobaugh <[email protected]> wrote:
> This has happened at least once at work on Solaris 10 x86 with a > .backup volume, as seen above, and at least once on one of my home > machines on 64bit linux with an RO clone. The volume was probably deleted during the salvage (it was already gone by the time of the 'zap -force'), but the fileserver still has the volume in an 'error' state. Could you volinfo /vicepa 536871061 fssync-debug query 536871061 on the fileserver? I have an idea on why you can't get the volume usable again, but I have no clue as to what the original inconsistency was that caused the first salvage. > I would have included more snippets from FileLog as well, but I have > the debug level turned up to try to track down a possible Then you should have some logs mentioning 'FSYNC_com' around 'Tue Mar 1 00:02:25 2011' explaining why we refused to give out the volume. (You don't perhaps have that volid header also existing on another partition, do you?) Not that that should explain the rest of it. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
