This is only hiding a problem in the estimation math, rather
than fixing it.
I don't like it.
Peter J. Philipp 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.c22 Jan 2019 16:16:26 - 1.40
> +++ optr.c29 Feb 2020 16:19:25 -
> @@ -202,6 +202,7 @@ void
> timeest(void)
> {
> time_t tnow, deltat;
> + float percent;
>
> (void) time();
> 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
>
