[OpenAFS-devel] possible suggestio for improvement in MoveVolume...

[Neulinger, Nathan]

Locking VLDB entry for volume 536929891 ... done
Starting transaction on source volume 536929891 ... done
Allocating new volume id for clone of volume 536929891 ... done
Cloning source volume 536929891 ... done
Ending the transaction on the source volume 536929891 ... done
Starting transaction on the cloned volume 537094189 ... done
Setting flags on cloned volume 537094189 ... done
Getting status of cloned volume 537094189 ... done
Creating the destination volume 536929891 ...vos move: operation
interrupted, cleanup in progress...
clear transaction contexts
Recovery: Releasing VLDB lock on volume 536929891 ... done
Recovery: Ending transaction on clone volume ... done
Recovery: Accessing VLDB.
move incomplete - attempt cleanup of target partition - no guarantee
Recovery: Creating transaction for destination volume 536929891 ... done
Recovery: Unable to start transaction on volume 536929891.
Recovery: Creating transaction on source volume 536929891 ... done
Recovery: Setting flags on source volume 536929891 ... done
Recovery: Ending transaction on source volume 536929891 ... done
Recovery: Creating transaction on clone volume 537094189 ... done
Recovery: Deleting clone volume 537094189 ... done
Recovery: Ending transaction on clone volume 537094189 ... done
Recovery: Releasing lock on VLDB entry for volume 536929891 ... done
cleanup complete - user verify desired result


That error in creating the destination volume was because a previous
volume move for that volume to the same destination failed. It seems
that perhaps checking to see if the destination volume exists, and
deleting it (same as in the cleanup code) would be a good improvement
over just moving it. That would allow moves to work where a previous
move failed.

Unfortunately, the failed moves are usually ones that result it 0-byte
volume headers, which none of the tools (other than rm) seem to be able
to deal with.

Removing the 0-byte headers by hand corrects the situation, but usually
results in a volserver restart unless you shut the volserver down first.
(Not entirely surprising.)

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216