[OpenAFS] Re: Security Advisory 2016-003 and 'bos salvage' questions
Garance A Drosehn
drosih@rpi.edu
Thu, 16 Feb 2017 23:52:47 -0500
On 15 Feb 2017, at 13:48, Garance A Drosehn wrote:
> I had an odd situation pop up when upgrading to OpenAFS 1.6.20.1.
> On my most-recent server, my script which does step #4 moved 26
> volumes, and then hit this error on the 27th one:
>
>> Failed to move data for the volume 53.....75
>> VOLSER: Problems encountered in doing the dump !
>> Recovery:Failed to start transaction on 53.....75
>> Volume needs to be salvaged
Here's a short follow-up on this, although no one else has commented
on it.
FWIW, I did do the 'bos salvage -salvagedirs', and it automatically
stops and starts the 'fs' process around the salvaging step. It
took 2m17.62s on a file server which has used up 40.96-gig out of
153.53-gig on the server. And it took 24m19.27s on a file server
which has used 145.46-gig of the 255.88-gig on the server.
However, there's definitely something odd going on with the step
where I 'vos move' volumes from my temp-server back to the file server
they were originally on. I'm seeing 'core' files under /usr/afs/logs
on the destination of that 'vos move'. Also, after a failed 'vos move'
a 'vos examine' of the volume will display an volume-ID for a read-only
instance of the volume, even though the volume did not have a read-only
instance before the move. It isn't that there *is* a read-only
instance, just that the RDOnly field is filled in whereas it used to
be 0.
I've had three different volumes fail when I tried to move them, and
all had a volume-id appear for the read-only instance. For the
initial 26 volumes which were successfully moved, they still show a
RDOnly volume-id of 0.
Obviously I need to do some more investigation, but I thought I'd
mention these bits. I guess I might need to learn what to do with
the afs core files!
--
Garance Alistair Drosehn = drosih@rpi.edu
Senior Systems Programmer or gad@FreeBSD.org
Rensselaer Polytechnic Institute; Troy, NY; USA