Dumpdates

[Doug Hardie]

On 25 October 2013, at 03:11, Doug Hardie <bc979 at lafn.org> wrote:

> Is there an issue with dump updating dumpdates on 9.1 and 9.2.  Both of those systems are writing /etc/dumpdates, but are using the time of 0 so the output from dump looks like:
> 
> Fri Oct 25 00:45:00 PDT 2013
> DUMP: Date of this level 0 dump: the epoch
> DUMP: Date of last level 0 dump: the epoch
> DUMP: Dumping snapshot of /dev/ada0p2 (/) to /usr2/backups/zool-root.tdump
> DUMP: mapping (Pass I) [regular files]
> DUMP: Cache 16 MB, blocksize = 65536
> DUMP: mapping (Pass II) [directories]
> DUMP: estimated 8487220 tape blocks.
> DUMP: dumping (Pass III) [directories]
> DUMP: dumping (Pass IV) [regular files]
> DUMP: 16.36% done, finished in 0:25 at Fri Oct 25 01:16:02 2013
> DUMP: 36.55% done, finished in 0:17 at Fri Oct 25 01:12:50 2013
> DUMP: 59.63% done, finished in 0:10 at Fri Oct 25 01:10:38 2013
> DUMP: 91.21% done, finished in 0:01 at Fri Oct 25 01:07:24 2013
> DUMP: DUMP: 8492396 tape blocks on 1 volume
> DUMP: finished in 1289 seconds, throughput 6588 KBytes/sec
> DUMP: level 0 dump on the epoch
> DUMP: Closing /usr2/backups/zool-root.tdump
> DUMP: DUMP IS DONE
> 
> The first line is from the date command.  Dumpdates always show a 1969 (the epoch) date.

After much digging around I have isolated the problem.  The -R (rsync-friendly) option causes dump to force all dates in the dump file to the epoch.  Thats reasonable.  However, the dumpdates file does not need to be that.  It can hold the real time.  The following patch fixes the problem:

--- sbin/dump/itime.c.orig	2013-10-27 22:21:20.000000000 -0700
+++ sbin/dump/itime.c	2013-10-27 22:23:01.000000000 -0700
@@ -199,7 +199,7 @@
  found:
	(void) strncpy(dtwalk->dd_name, fname, sizeof (dtwalk->dd_name));
	dtwalk->dd_level = level;
-	dtwalk->dd_ddate = _time64_to_time(spcl.c_date);
+	dtwalk->dd_ddate = time(0);

	ITITERATE(i, dtwalk) {
		dumprecout(df, dtwalk);


Basically this patch sets the current time after the dump is completed just before the dumpdates file is written.  It does not change the handling of the previous and current dump dates when dump is started so they will always show the epoch.  Perhaps that could be improved also, but at least the dumpdates files now show the time the dump completed.