This is only hiding a problem in the estimation math, rather than fixing it.
I don't like it. Peter J. Philipp <p...@centroid.eu> wrote: > Hi, > > I have a patch for dump(8) if it is generally considered bad if percentage > done is over 100.0%. I checked the archives on marc.info for this and didn't > see any discussion whether this was a topic before. > > Here is the odd DUMP message I got on a host: > > DUMP: 102.41% done, finished in 0:00 > > And here is the patch: > > Index: optr.c > =================================================================== > RCS file: /cvs/src/sbin/dump/optr.c,v > retrieving revision 1.40 > diff -u -p -u -r1.40 optr.c > --- optr.c 22 Jan 2019 16:16:26 -0000 1.40 > +++ optr.c 29 Feb 2020 16:19:25 -0000 > @@ -202,6 +202,7 @@ void > timeest(void) > { > time_t tnow, deltat; > + float percent; > > (void) time(&tnow); > if (tnow >= tschedule) { > @@ -211,8 +212,9 @@ timeest(void) > deltat = tstart_writing - tnow + > (1.0 * (tnow - tstart_writing)) > / blockswritten * tapesize; > + percent = (blockswritten * 100.0) / tapesize; > msg("%3.2f%% done, finished in %lld:%02lld\n", > - (blockswritten * 100.0) / tapesize, > + (percent > 100.0) ? 100.0 : percent, > (long long)deltat / 3600, > ((long long)deltat % 3600) / 60); > } > > > I tested this and it seems to report like before, only when it hits 100.0 it > will not go higher, that particular codepath I didn't hit though. > > beta# dump -0uaf - /var | gzip -c > /dev/null > DUMP: Date of this level 0 dump: Sat Feb 29 17:20:26 2020 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /dev/rsd2e (/var) to standard output > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 23891439 tape blocks. > DUMP: Volume 1 started at: Sat Feb 29 17:20:37 2020 > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > DUMP: 25.98% done, finished in 0:14 > > Let me know what you think, > > Regards, > -peter >