From owner-freebsd-questions@FreeBSD.ORG Mon Oct 28 05:29:47 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7F06E5C5 for ; Mon, 28 Oct 2013 05:29:47 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.org [108.92.93.123]) by mx1.freebsd.org (Postfix) with ESMTP id 3D52E22B6 for ; Mon, 28 Oct 2013 05:29:46 +0000 (UTC) Received: from [10.0.1.4] (static-71-177-216-148.lsanca.fios.verizon.net [71.177.216.148]) (authenticated bits=0) by zoom.lafn.org (8.14.3/8.14.2) with ESMTP id r9S5TdLp039576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 27 Oct 2013 22:29:39 -0700 (PDT) (envelope-from bc979@lafn.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Dumpdates From: Doug Hardie In-Reply-To: <2CD12742-C62F-464F-AB4D-3B2949A490F9@lafn.org> Date: Sun, 27 Oct 2013 22:29:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CD12742-C62F-464F-AB4D-3B2949A490F9@lafn.org> To: "freebsd-questions@freebsd.org Questions" X-Mailer: Apple Mail (2.1510) X-Virus-Scanned: clamav-milter 0.97 at zoom.lafn.org X-Virus-Status: Clean X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 05:29:47 -0000 On 25 October 2013, at 03:11, Doug Hardie 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: >=20 > 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 =3D 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 >=20 > 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 =3D level; - dtwalk->dd_ddate =3D _time64_to_time(spcl.c_date); + dtwalk->dd_ddate =3D 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.