From owner-freebsd-bugs Sun Aug 24 09:10:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA06691 for bugs-outgoing; Sun, 24 Aug 1997 09:10:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA06663; Sun, 24 Aug 1997 09:10:01 -0700 (PDT) Resent-Date: Sun, 24 Aug 1997 09:10:01 -0700 (PDT) Resent-Message-Id: <199708241610.JAA06663@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, blank@fox.uni-trier.de (Sascha Blank) Received: from sliphost37.uni-trier.de (blank@sliphost37.uni-trier.de [136.199.240.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA06389 for ; Sun, 24 Aug 1997 09:01:55 -0700 (PDT) Received: (from blank@localhost) by sliphost37.uni-trier.de (8.8.7/8.8.7) id RAA00467; Sun, 24 Aug 1997 17:03:54 +0200 (CEST) Message-Id: <199708241503.RAA00467@sliphost37.uni-trier.de> Date: Sun, 24 Aug 1997 17:03:54 +0200 (CEST) From: blank@fox.uni-trier.de (Sascha Blank) Reply-To: blank@fox.uni-trier.de (Sascha Blank) To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/4369: dump can calculate wrong estimate times Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4369 >Category: bin >Synopsis: dump can calculate wrong estimate times when using multiple volumes >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Aug 24 09:10:00 PDT 1997 >Last-Modified: >Originator: Sascha Blank >Organization: >Release: FreeBSD 2.2-STABLE i386 >Environment: A FreeBSD 2.2-STABLE system, current as of CTM src-2.2 delta #401 The file /usr/src/sbin/dump/tape.c does not have any FreeBSD specific version identifier except a SCCS version tag: static char sccsid[] = "@(#)tape.c 8.2 (Berkeley) 3/17/94"; >Description: dump tries to estimate the time it will take to write out the entire file system by measuring in constant intervals how long it has taken (since the start of the entire dump) to write out the amount of data that has been written out so far and then by making a projection for the entire tape. This projection works well as long as only the amount of time is considered during which the tape has been written to. This can become a problem when you have to use multiple values. I have taken these values from a real dump session. I am dumping a 210 MB /home partition on two QIC-120 tapes, the tape drive is a Tandberg TDC 4100. ... DUMP: 13.31% done, finished in 0:32 DUMP: 26.96% done, finished in 0:27 DUMP: 40.66% done, finished in 0:21 At this point I am prompted to insert a new volume. As I don't watch my computer while dumping, I usually do not respond immediately to the prompt. After about 15 minutes I inserted a new volume and resumed the session. Now the ETAs look like this: DUMP: 52.97% done, finished in 0:33 DUMP: 66.98% done, finished in 0:21 DUMP: 81.31% done, finished in 0:10 DUMP: 95.70% done, finished in 0:02 ... The new ETAs are wrong because dump considers the 15 minute break as operation time for its projection of the ETA for the entire tape. Therefore it looks like the averagsea writing speed has fallen drastically for the second tape and therefore the ETA for the rest of the dump must be much higher then originally calculated. >How-To-Repeat: Make a dump from a partition that will only fit on two volumes. If you are prompted for the next volume, wait for 10 or 15 minutes before you resume the operation. >Fix: The fix is simple. When the user is prompted for a new tape, stop the internal clock, and when operation resumes, start it again. This way the length of the break has no influence on the measured time that dump is really operating on the tape. NOTE: This problem is likely to be present in 3.0-CURRENT as well. With the fix applied, the ETAs for the second tape look like this (also with a break of about 15 minutes during volume change): DUMP: 52.97% done, finished in 0:16 DUMP: 66.98% done, finished in 0:11 ... *** tape.c.CURRENT Sun Aug 24 13:12:12 1997 --- tape.c Sun Aug 24 16:52:42 1997 *************** *** 366,374 **** --- 366,377 ---- void close_rewind() { + time_t tstart_changevol, tend_changevol; + trewind(); if (nexttape) return; + (void)time((time_t *)&(tstart_changevol)); if (!nogripe) { msg("Change Volumes: Mount volume #%d\n", tapeno+1); broadcast("CHANGE DUMP VOLUMES!\7\7\n"); *************** *** 378,383 **** --- 381,389 ---- dumpabort(0); /*NOTREACHED*/ } + (void)time((time_t *)&(tend_changevol)); + if ((tstart_changevol != (time_t)-1) && (tend_changevol != (time_t)-1)) + tstart_writing += (tend_changevol - tstart_changevol); } void -- Sascha Blank - mailto:blank@fox.uni-trier.de Student and System Administrator at the University of Trier, Germany Finger my account to receive my Public PGP key I don't speak for my employers, they don't pay me enough for that. >Audit-Trail: >Unformatted: