Date: Sun, 24 Aug 1997 17:03:54 +0200 (CEST) From: blank@fox.uni-trier.de (Sascha Blank) To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: bin/4369: dump can calculate wrong estimate times Message-ID: <199708241503.RAA00467@sliphost37.uni-trier.de> Resent-Message-ID: <199708241610.JAA06663@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708241503.RAA00467>