[OpenAFS-devel] Incremental restore and creation timestamp

[Kris Van Hees]

Hi,

	I am working on a patch to deal with how incremental restores affect
the creation timestamp of the target volume, and I'd like to solicit some
feedback on two aspects:

	- Should the behaviour I am implementing be the default or should it
	  be under the control of a 'vos restore' switch?
	- Any idea why it is not currently implemented like this in OpenAFS?

	The issue: when you restore an incremental dump to an existing volume,
the creation timestamp of the target volume gets reset to the current timestamp
(literally the timestamp of when the 'vos restore' command is being executed).
That messes things up for any subsequent 'vos release' operation, because such
operation then needs to do a full release rather than an incremental one.  For
large volumes that can be quite an issue.

	The reason for this *seems* to be the fact that the volserver actually
does not differentiate between a full restore and an incremental restore.  The
flag (RV_FULLRST) is passed from the vos command to the volserver as part of
the RPC, but the volserver never does anything with it.  It really looks as if
someone was going to do server-side specific tasks depending on whether the
restore was full or incremental, but that those things were never implemented.
(Or likewise, it is possible that once it did do something different and that
when the implementation was changed, the flag passing never was cleaned up).
Either way, the volserver now restores the dump (full or incremental) and it
replaces the volume header of the target volume with the one from the dump
(after resetting some values).  That writes the creation timestamp of the dumped
volume into the target volume.  When processing returns, the vos command then
resets the timestamp of the target volume with the current timestamp, probably
to correct the timestamp that was set on the volume due to the restore.

	There are two ways to fix this:

	- Make sure that the flags are properly passed from the vos command,
	  through the RPC, into the volserver.  Use it in dumpstuff.c
	  RestoreVolume() in such way that if the RV_FULLRST flag is *not* set,
	  the create timestamp from the volume being restored to is saved, do 
	  the restore, and then write back the saved timestamp.  That of course
	  requires volserver changes.
	- If RV_FULLRST is not set, retrieve the creation timestamp of the
	  target volume in the vos command (using the ListOneVolume RPC), and
	  save it.  Then perform the restore volume operation, and finally 
	  write back the saved timestamp rather than now().  That will also
	  work with older volservers, but it takes an additional RPC.

	Currently, I am implementing both, with one difference; I am using a
'-nosettime' flag to 'vos restore' (only valid in incremental mode) to state
that the creation timestamp ought to be retained.  But perhaps this should not
even need a switch, and it could be the default behaviour?

	What do you think?  Anyone who can shed light on why it is implemented
in a way where the creation timestamp always gets reset?

	Kris
-- 
Never underestimate a Mage with:
 - the Intelligence to cast Magic Missile,
 - the Constitution to survive the first hit, and
 - the Dexterity to run fast enough to avoid being hit a second time.