[OpenAFS] Re: WARNING: may leave AFS storage and metadata in indeterminate state

[Andrew Deason]

On Mon, 09 Apr 2012 09:40:50 -0400
Jeff Blaine <jblaine@kickflop.net> wrote:

> Hi all,
> 
> Can anyone explain why it is possible for the interruption of
> a 'vos move' to leave "AFS storage and metadata in indeterminate
> state"?

'vos' cannot guarantee that it will be able to clean up everything
properly. After you try to stop a move, it will need to issue new RPCs
to remove some of the volumes it has created for the move and end
transactions and such (and maybe some other stuff; I don't remember
exactly at the moment). When we try to do that, we may fail to contact
the server, our tokens may have expired, etc etc. Or vos may crash
during the cleanup process; for some combination of platform and 'vos'
version, we even unconditionally crash (there were, and probably still
are, some issues with our 'vos' signal handling since we longjmp out of
a signal handler).

When you're at the stage of the move where you're transmitting the bulk
of the data, the RW exists at both the source and destination. If
everything just dies at that point, it can be hard to tell later on
which one is the 'real' one (the vldb can tell you, but if you lose the
vldb entry or someone runs 'vos sync*' this can easily get confused). It
may also be hard to tell that the leftover cruft on the destination
and/or source even exists, if you're not paying attention at the time of
the 'vos move'.

> Dumping from clone 2023894170 on source to volume 2023891400 on 
> destination ...^C
> SIGINT handler: vos move operation in progress
> WARNING: may leave AFS storage and metadata in indeterminate state
> enter second control-c to exit

If you hit ctrl-c again after this message, 'vos' gives you a message
saying that you should manually check the result of the cleanup. Since
we don't really have any place to signify what happened if we fail to
cleanup, it is rather important that the user does so right about when
it happens. That's what all of these warnings are trying to get you to
do.

-- 
Andrew Deason
adeason@sinenomine.net