Red Hat Bugzilla – Bug 9188
repeated "DUMP: " in output
Last modified: 2008-05-01 11:37:54 EDT
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--
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.
fixed in rawhide.