From owner-freebsd-current Wed Nov 29 01:01:55 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA22691 for current-outgoing; Wed, 29 Nov 1995 01:01:55 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA22351 for ; Wed, 29 Nov 1995 00:58:40 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA10569; Wed, 29 Nov 1995 09:56:01 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA02672; Wed, 29 Nov 1995 09:56:01 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA14116; Wed, 29 Nov 1995 08:44:01 +0100 From: J Wunsch Message-Id: <199511290744.IAA14116@uriah.heep.sax.de> Subject: Re: Recent changes to `dump' To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Wed, 29 Nov 1995 08:44:01 +0100 (MET) Cc: current@FreeBSD.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9511281946.AA04068@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Nov 28, 95 02:46:00 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2834 Sender: owner-current@FreeBSD.org Precedence: bulk As Garrett A. Wollman wrote: > > I noticed that my backups stopped working over Thanksgiving break. > The cause turned out to be that the format of `dump''s informational > messages has changed to add the qualifier `tape ' in front of > references to `blocks'. Given the fact that almost everyone who does > any sort of large-scale backups has written lots of wrapper scripts > which attempt to parse the output of `dump', I think this format > change is inadvisable, and I intend to reverse it unless someone > speaks up with a good reason to keep the superfluous verbiage. It has not added a qualifier. Here's the diff: Index: main.c =================================================================== RCS file: /home/cvs/src/sbin/dump/main.c,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- main.c 1995/10/24 13:46:35 1.4 +++ main.c 1995/11/18 18:00:42 1.5 @@ -440,14 +448,24 @@ (void)dumpino(dp, ino); } + (void)time((time_t *)&(tend_writing)); spcl.c_type = TS_END; for (i = 0; i < ntrec; i++) writeheader(maxino - 1); if (pipeout) - msg("DUMP: %ld tape blocks\n",spcl.c_tapea); + msg("%ld tape blocks\n", spcl.c_tapea); else - msg("DUMP: %ld tape blocks on %d volumes(s)\n", + msg("%ld tape blocks on %d volumes(s)\n", spcl.c_tapea, spcl.c_volume); + + /* report dump performance, avoid division through zero */ + if (tend_writing - tstart_writing == 0) + msg("finished in less than a second\n"); + else + msg("finished in %d seconds, throughput %d KBytes/sec\n", + tend_writing - tstart_writing, + spcl.c_tapea / (tend_writing - tstart_writing)); + putdumptime(); trewind(); broadcast("DUMP IS DONE!\7\7\n"); It has added a new message (which does neither contain the words `tape' or `blocks'), and i've removed a superfluous `DUMP:' in front of the `tape blocks' line. The output was previously looking like: ... DUMP: estimated 4835 tape blocks on 0.12 tape(s). DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: DUMP: 4827 tape blocks on 1 volumes(s) ... ...and now looks like: ... DUMP: estimated 4835 tape blocks on 0.12 tape(s). DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 4827 tape blocks on 1 volumes(s) DUMP: finished in 10 seconds, throughput 482 KBytes/sec ... If you really think that omitting the additional (and apparently accidental) ``DUMP:'' does confuse the world, so remove _just this_, instead of shooting around and removing everything from this patch. Remember, there was a general consensus to _include_ the `throughput' line. What does amanda say to the new dump? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)