[OpenAFS] Re: 1.6.0pre2 - more vos issues, possible bug

Andrew Deason adeason@sinenomine.net
Mon, 7 Mar 2011 11:03:06 -0600


On Fri, 4 Mar 2011 19:42:04 -0500 (EST)
Andy Cobaugh <phalenor@gmail.com> wrote:

> > Tue Mar  1 00:02:12 2011 VReadVolumeDiskHeader: Couldn't open header for volume 536871061 (errno 2)
> >
> > means the volume doesn't exist. It's not that it's corrupt or
> > anything; the volume was completely deleted. (or something just
> > deleted the .vol header, but the other messages suggest it was
> > deleted normally)
> 
> What does 'deleted normally' mean in this context? Nothing touched the
> volume since the previous night, where it created the .backup volume
> just fine. Unfortunately, those logs have since rolled over, so I
> don't have anything older than from when I restarted the fileserver at
> 16:12 on Mar 1.

Deleted normally as in, a 'vos remove' or 'vos zap'. The volume header
didn't exist, and we didn't encounter any extant files when recreating
the clone, suggesting that the backup clone was cleanly deleted before
we tried making a new one.

> I still have no idea what caused the volume to spontaneously need
> salvaging Tuesday afternoon. I did notice that until I fixed the BK
> volume, if I did a 'vos exam home.gsong.backup', that triggered a
> salvage.

Yes, when the volume got caught in that state, any access could have
triggered a salvage (since it was in a half-created state). So, an
examine or someone just trying to access 'yesterday' (or whatever you
call it) could have caused that.

-- 
Andrew Deason
adeason@sinenomine.net