volser: warn if older version of volume is restored 51/13251/5
authorMarcio Barbosa <mbarbosa@sinenomine.net>
Sat, 11 Aug 2018 18:00:18 +0000 (14:00 -0400)
committerBenjamin Kaduk <kaduk@mit.edu>
Fri, 21 Sep 2018 12:07:32 +0000 (08:07 -0400)
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

Change-Id: Iac55cc8bb1406ca6af9a5e43e7d37c6bfa889e91
Reviewed-on: https://gerrit.openafs.org/13251
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>


index 63bf061..f78c6bf 100644 (file)
@@ -1247,6 +1247,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);
@@ -1334,6 +1335,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);
@@ -1341,6 +1344,20 @@ RestoreVolume(struct rx_call *call, Volume * avp, int incremental,
        Log("1 Volser: RestoreVolume: Unable to rewrite volume header; restore aborted\n");
        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));
+       }
     /* Free the malloced space above */