This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 9188 - repeated "DUMP: " in output
repeated "DUMP: " in output
Status: CLOSED RAWHIDE
Product: Red Hat Raw Hide
Classification: Retired
Component: dump (Show other bugs)
1.0
All Linux
medium Severity low
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-07 17:13 EST by Joe Harrington
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-03-11 11:08:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Joe Harrington 2000-02-07 17:13:31 EST
This is from dump-0.4b13-1, gotten from SourceForge and referred to as
fixing other bugs:

# ssh1 glup -l root -n "(dump 0af - /)" > gluproot
  DUMP: Date of this level 0 dump: Mon Feb  7 14:32:06 2000
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/hda5 (/) to standard output
  DUMP: Label: none
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 1303874 tape blocks.
  DUMP: Volume 1 started at: Mon Feb  7 14:32:10 2000
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: 6.54% done, finished in 1:11
  DUMP: 10.86% done, finished in 1:22
  DUMP: 14.82% done, finished in 1:26
  DUMP: 18.97% done, finished in 1:25
  DUMP: 23.00% done, finished in 1:23
  DUMP: 26.97% done, finished in 1:21
  DUMP: 31.54% done, finished in 1:15
  DUMP: 35.94% done, finished in 1:11
  DUMP: 40.87% done, finished in 1:05
  DUMP: 45.87% done, finished in 0:59
  DUMP: 50.83% done, finished in 0:53
  DUMP: 54.58% done, finished in 0:49
  DUMP: 57.61% done, finished in 0:47
  DUMP: 59.62% done, finished in 0:47
  DUMP: 63.07% done, finished in 0:43
  DUMP: 68.10% done, finished in 0:37
  DUMP: 72.82% done, finished in 0:31
  DUMP: 76.76% done, finished in 0:27
  DUMP: 80.77% done, finished in 0:22
  DUMP: 84.85% done, finished in 0:17
  DUMP: 88.91% done, finished in 0:13
  DUMP: 94.00% done, finished in 0:07
  DUMP: 99.21% done, finished in 0:00
  DUMP: 105.11% done, finished in 0:-5
  DUMP: 109.85% done, finished in 0:-11
  DUMP: DUMP: 1439583 tape blocks
  DUMP: finished in 7531 seconds, throughput 191 KBytes/sec
  DUMP: Volume 1 completed at: Mon Feb  7 16:37:41 2000
  DUMP: Volume 1 took 2:05:31
  DUMP: Volume 1 transfer rate: 191 KB/s
  DUMP: DUMP: Date of this level 0 dump: Mon Feb  7 14:32:06 2000
  DUMP: DUMP: Date this dump completed:  Mon Feb  7 16:37:41 2000
  DUMP: DUMP: Average transfer rate: 191 KB/s
  DUMP: DUMP IS DONE

The repeated "DUMP: " in the 9th last and 4th last through 2nd last lines
shouldn't be there.

I am also curious about the time estimates.  It was a dump over the net and
to a disk file.  The partition size didn't change by more than a kbyte
during the dump.  Is the percentage calculation done on the basis of size
or of time elapsed?  I can see the time estimates being off due to varying
network throughput, but they should never be negative.  Clamp them at zero
or print question marks if no good estimate can be made (or heck, give a
standard deviation for the uncertainty of the estimate ;-).  The percentage
is downright strange, as df reports the same number of used blocks before
and after the dump.  Is something wrong, or is it just a byproduct of
varying net speeds?  If I were to do this calculation, I would be using
bytes transferred/total bytes, and the numerator would never get 10% larger
than the denominator on a 1GB+ filesystem whose size didn't change.  The
dump file is 5% larger than the filesystem's df size.  I don't see similar
estimation problems on larger partitions of the local machine.

--jh--
Comment 1 Stelian Pop 2000-03-11 11:08:59 EST
The repeated DUMP: DUMP were fixed in 0.4b16.

The negative time estimations were fixed in 0.4b15.

The calculation method is indeed using bytes transferred/total bytes. Except
that the total bytes are based on an estimation made at the beginning of dump,
and this can be wrong, even if the filesystem is quiet. (since the estimation
must be quick, so the estimation algorithm doesn't take into account all data -
see the changelog for 0.4b16 for details).

But the estimation algorithm was improved a bit in 0.4b16, so the results should
be more accurate now.

Stelian.
Comment 2 Preston Brown 2000-06-27 12:11:55 EDT
fixed in rawhide.

Note You need to log in before you can comment on or make changes to this bug.