volser: warn if older version of volume is restored

Volume restores work by overwriting vnodes with the data in the given
volume dump. If we restore a partial incremental dump from an older
version of the volume, this generally results in a partly-corrupted
volume, since directory vnodes may contain references that don't exist
in the current version of the volume (or are supposed to be in a
different directory).

Currently, the volserver does not prevent restoring older volume data
to a volume, and this doesn't necessarily always result in corrupted
data (for instance, if we are restoring a full volume dump over an
existing volume). But restoring old volume data seems more likely to
be a mistake, since reverting a volume back to an old version, even
without corrupting data, is a strange thing to do and may cause
problems with our methods of cache consistency.

So, log a warning when this happens, so if this is a mistake, it
doesn't happen silently. But we still do not prevent this action, since
it's possible something could be doing this intentionally. We detect
this just by checking if the updateDate in the given header is older
than the current updateDate for the volume on disk.

Note: Restoring a full dump file (-overwrite f) will not result in
corrupted data. In this scenario, the restore operation removes the
volume on disk first (if present). After that, the dump file is
restored. In this case, we do not log anything (the volume is not
corrupted).

Reviewed-on: https://gerrit.openafs.org/13251
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 8375a7f7dd0e3bcbf928a23f874d1a15a952cdef)

Change-Id: Ic119b0a7b1eac5e01fabbadc0aa679d5f2617d53
Reviewed-on: https://gerrit.openafs.org/15531
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Indira Sawant <indira.sawant@ibm.com>
Reviewed-by: Kailas Zadbuke <kailashsz@in.ibm.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
This commit is contained in:
Marcio Barbosa 2018-08-11 14:00:18 -04:00 committed by Stephan Wiesand
parent 538f450033
commit b7ac4842a1

View File

@ -1178,6 +1178,7 @@ RestoreVolume(struct rx_call *call, Volume * avp, int incremental,
int s1 = 0, s2 = 0, delo = 0, tdelo;
int tag;
VolumeDiskData saved_header;
afs_uint32 uptime, crtime;
iod_Init(iodp, call);
@ -1265,6 +1266,8 @@ RestoreVolume(struct rx_call *call, Volume * avp, int incremental,
* prevent it from getting overwritten. */
vol.needsSalvaged = V_needsSalvaged(vp);
}
crtime = V_creationDate(vp);
uptime = V_updateDate(vp);
CopyVolumeHeader(&vol, &V_disk(vp));
V_destroyMe(vp) = 0;
VUpdateVolume(&vupdate, vp);
@ -1272,6 +1275,20 @@ RestoreVolume(struct rx_call *call, Volume * avp, int incremental,
Log("1 Volser: RestoreVolume: Unable to rewrite volume header; restore aborted\n");
error = VOLSERREAD_DUMPERROR;
goto out;
} else {
/*
* If the volume was not a new empty volume and the restored dump was
* older than the volume in question, this is probably a mistake, and
* may mean the resulting volume is corrupted. Log the following message
* to give a clue as to why this volume suddenly looks strange or corrupt.
*/
if ((crtime != uptime) && (uptime > V_updateDate(vp))) {
Log("1 Volser: RestoreVolume: volume %s (%u) appears to have been partially or "
"completely restored to an earlier version (updateDate went from %u to %u). "
"This is allowed, but may indicate a mistake in whatever tool is restoring "
"this volume. If this volume appears corrupted, this is probably why.\n",
V_name(vp), V_id(vp), uptime, V_updateDate(vp));
}
}
out:
/* Free the malloced space above */