1. 35
    1. 7

      If you follow the original bug report then its supposed fix was never applied.

      Apparently these systems with issues were running an old version compared to then currently stable version (0.6.x vs 0.7.x), where this issue had been alleviated by using PRNG.

      And a lesson here - always follow up your bug reports :)

      1. 19

        Marked closed by “stale bot”. I think I’ve could argue that the lesson is not to use stale bot. ;-)

        On a more serious but, for non trivial, non obvious (crashes, etc.), not easy to repeat or simply more edge case bugs it can be really annoying, when all the information provided, maybe over many years is “hidden away” in a closed bug report and work to analyze this over the course of a week was completely meaningless.

        Maybe, if “stale” was really necessary it should be a separate state, one that people don’t actively look at but maybe want to include in searches to see if others encountered it, maybe even already have a solution like in this case.. or at least a workaround.

        Following up without new findings, just to prevent a bot from doing something silly and usually pinging everyone for no reason doesn’t seem like the most sensible approach.

      2. 5

        It’s interesting that the cryptographically secure random number generator is so expensive. I believe the FreeBSD in-kernel Fortuna implementation is very cheap to query, all of the expensive operations happen when you add entropy to the pool. The first version acquired a lock and added things to the entropy pool every time an interrupt was received (this version was not merged - you can imagine the perf hit!) but it should be pretty cheap to query.

      3. 3

        You are right. There was actual code change suggested, but it never got merged: https://github.com/openzfs/zfs/pull/6544

      4. [Comment removed by author]

      5. 1

        Hmm, so you’re saying in current versions, ZFS still runs in the background and wastes CPU and power even when not in use, just with a faster RNG so it doesn’t waste as much CPU and power?

        Doesn’t sound very fixed to me

    2. 1

      Cryptographically-secure random.

      Do we really need that? How’s that more secure or more efficient than loop through CPUs or a non secure rng?