[OpenAFS] Re: 'vos dump' destroys volumes?

[Andrew Deason]

On Wed, 28 Mar 2012 19:01:26 +0200
Matthias Gerstner <matthias.gerstner@esolutions.de> wrote:

> > That version is known to have issues with data corruption/loss, which
> > are fixed in pre4. I don't know if that's what you're hitting, though.
> > (You can also run a newer client with older servers just fine.)
> 
> So it seems I'm better off falling back to 1.6.0 on the server side
> then.

As Derrick said, "no".

> The tokens expired due to an error I introduced in the backup script.
> My approach is to renew authentication after each dump. Token lifetime
> is eight hours. And I haven't got any volumes that should take longer
> than that for dumping.
> 
> What would a tool look like that refreshes tokens during a long dump?
> Something like a background process in the same authentication group?

Don't make your own; run whatever process you're running under k5start
(or k5renew or similar), which handles a lot of the details for you. Or
use -localauth.

> > Hmm, did you forget to attach this?
> 
> Sorry. I'm adding it now. It's the log for the "sealed data
> inconsistent" error. As you can see in the log the backup continued
> another ten minutes before it finally failed due to "token expired"
> failure. But it surely was related to the expired token, too.

No, the volserver errored out the operation at 03:32:01, and the 'vos'
process should have gotten an error soon after that and died. The
remaining ten minutes of 'trans foo has been idle' just says that the
transaction for the volume still exists, but nothing is using it.

I'm not sure why you're getting that specific error rather than it
telling you the token has expired, but yeah, if it's plausible that the
token did expire, that seems likely to be the reason why it occurred.

-- 
Andrew Deason
adeason@sinenomine.net