Re: bug#51345:

[Glenn Golden]

On Thu, Oct 28, 2021, at 15:59, Sworddragon wrote:
>
> Despite I'm not using Linux as main system anymore and wanted to avoid
> getting into too much work I found some time to do some tests as this issue
> bugs me just too much.
>

Suggestion as a possible workaround: Have a look at random(4) and random(7),
and ask yourself whether your use of /dev/random, rather than /dev/urandom,
is really necessary for your application. If not, you might try /dev/urandom
instead and report what you observe.

As documented in those man pages, there are good reasons to avoid using 
/dev/random, not the least of which is that it blocks frequently (every time
the entropy pool is exhausted), whereas /dev/urandom does not. That alone may
explain the execution time inconsistencies you're reporting.

Another possibly relevant reason to avoid /dev/random is hinted at in random(7):

    "The disadvantage of GRND_RANDOM and reads from /dev/random is that  the
    operation  can  block  for  an indefinite period of time.  Furthermore,
    dealing with the partially fulfilled requests that can occur when using
    GRND_RANDOM or when reading from /dev/random increases code complexity."

It's possible that frequently "dealing with the partially fulfilled requests"
is exposingsome sort of oddity in the way that dd is handling your use case.
Just guesing, I have no idea really.

IMO, the dd man page sentence describing fdatasync (and by implication,fsync) 
i.e. that it will "physically write output file data before finishing", could
use some clarification as to specifically what is meant by "physically write",
and to state what guarantees (if any) exist regarding data integrity "out to
the platters" [so to speak] when it is used. Or perhaps better/easier to
simply state that use of the fdatasync option provides whatever it is that
fsyncdata(3P) provides for the given device, and let the user try to figure
that out for himself. 

Glenn