Page MenuHomeFreeBSD

dd: Correct padding in status=progress
ClosedPublic

Authored by tom_hur.st on Aug 30 2018, 9:45 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Jul 13, 9:46 AM
Unknown Object (File)
Wed, Jul 10, 8:41 AM
Unknown Object (File)
Sat, Jul 6, 6:41 PM
Unknown Object (File)
Sat, Jul 6, 8:31 AM
Unknown Object (File)
Sat, Jun 29, 3:35 PM
Unknown Object (File)
Jun 17 2024, 6:03 AM
Unknown Object (File)
Jun 15 2024, 11:46 AM
Unknown Object (File)
Jun 15 2024, 11:12 AM
Subscribers
None

Details

Summary

Output padding is specified via outlen, which is set using the return value of fprintf. Because it's printing that padding plus a trailing byte, it grows by one each iteration.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

Hi @imp - I've also received some other questions about status=progress:

1.) What's the rationale for a mix of SI/IEC here? You deal professionally with larger storage and personally with smaller storage, so I assume there's a good reason for it. =)

2.) Any objection to making the final line of SIGINFO consistent with this?

Not just mixing SI/IEC, but they have different effective widths, so they scale differently - one will be counting up thousands of MBs while the other's totting up GiBs, (9294 MB, 8.7 GiB):

char si[4 + 1 + 2 + 1];         /* 123 <space> <suffix> NUL */
char iec[4 + 1 + 2 + 1];        /* 123 <space> <suffix> NUL */

If that's intended, shouldn't this be iec[3 + 1 + 3 + 1]? If it's not intended, char iec[4 + 1 + 3 + 1] is the obvious tweak for a more consistent (8407 MB, 8018 MiB), except then I also get (25 GB, ) if I dd with a larger block size(?!).

Oh, this is why:

humanize_number(persec, sizeof(iec), (int64_t)(st.bytes / secs), "B",

Formatting into persec but using the size of iec. I guess at high speeds it's filling the buffer and the trailing NULL is overflowing into iec.

I listed both because different applications require different numbers.
Sometimes you need SI stuff since you are more familiar with that stuff due to there aspects of your pipeline (eg disks or networks)
Other times you want the IEC ones because you (eg memory images)
It's also not burdensome to do both, just tricky to get the code right...

looks good, as does the good humanize_number catch.

This revision is now accepted and ready to land.Aug 31 2018, 3:39 PM

Fix persec humanize_number call. Size IEC buffer to make room for the longer suffix.

This revision now requires review to proceed.Aug 31 2018, 3:49 PM
This revision is now accepted and ready to land.Aug 31 2018, 3:57 PM
In D16960#362030, @imp wrote:

looks good, as does the good humanize_number catch.

Do you want to take this through re@, or shall I?

This revision was automatically updated to reflect the committed changes.