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 = dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
