In D23050#505606, @mckusick wrote:

My confusion is what "clusters" represent. Apparently a cluster is a 32KB block. Based on your clarification, I now agree with your calculation and printing of free space, but suggest that you clarify that clusters are 32KB blocks (either by replacing the word "clusters" with "32KB blocks", or if clusters is meaningful to administrators change it to "32KB clusters").

In D23050#505431, @mckusick wrote:

The current output is number of free blocks and number of bad blocks.

Address some feedback from kevlo@ for style, avoid using unnecessary
brackets.

copyfat(): distinguish between failed read (fatal) and write (not fatal).

Use FSOK/FSFATAL/FSERROR for fat_flush_fat32_cache_entry instead of
0 and 1, suggested by kevlo@.

In D6442#502200, @pfg wrote:

Hmm ...
When arc4random was introduced in OpenBSD the idea was to have one unique random algorithm to replace them all. This patch is old and reflects that idea. I am now thinking , that that is not the real objective for us.

In D22839#500542, @cem wrote:

Moving unrelated discussion off the line comment.

@delphij wrote:

I do have some doubts with the benefit of performing reseeding upon root seed refresh. Effectively, it triggers an immediate reseed so applications that does arc4random(3) a lot would hammer the system entropy source in an hourly basis (with the existing code, they are relatively independent and only reseeds when arc4random(3) thinks necessary, either when we generated enough output, or have forked, whichever comes first). This seems to be a bad design choice for both security (the randomness caused by accumulated scheduling skews between arc4random(3) calls in the system are now gone) and performance (tends to do something computational intensive in hourly basis).

Applications that "hammer" arc4random already hammer system entropy much more frequently than hourly; arc4random will reseed every 5 minutes or 1kB today. arc4random(3) can generate 1kB buffers at 400 MB/s, reseeding 400,000 times per second already. A root version reseed only causes an additional reseed to occur that would not have occurred otherwise if the application was reading at a rate of less than 1kB / 5 minutes, or ~3.4 B/sec. That's a fairly low rate. The random device can emit 32-bit PRNG seeds to a single userspace thread at 80 MB/s (2,500,000 times per second), including syscall overhead. (All figures from an INVARIANTS test VM.) I think the performance concern in this particular hypothetical is not especially substantial.

I don't think the security concern is profound, either. We arguably lose a handful of bits of entropy from arc4random(3) syscalls within a few minutes of an hour boundary, sure. If those handful of bits are really all the entropy we're collecting, everything is broken, including Fortuna. Applications only reseed on-demand, when they actually invoke arc4random(3). In practice, this may be long after the root seed version has changed (it is possible for an application to observe the seed version jump by >1 between arc4random(3) reads). I think you are probably overweighing the entropy value of the particular scheduler skew.

(Note that the new revision also changed permission from 400 r-------- to 600 rw-------, and umask from 377 to 177, because the non-root user needs write permission to modify the inode).

Fix issues pointed out by cem@

Thanks for the review, please take another look.

(Note that the refactor is not really needed, but I don't have strong opinion here).

Thanks!

Looks reasonable to me.

I think the proposed change actually does change the code behavior slightly.

I like the direction in general.

Looks fine to me, but I no longer have the hardware to actually test the changes, iXsystems may be able to help with that.

I'm mostly in favor of the change (smaller kernel size, etc.), but since we are removing driver from GENERIC, it's better if we can provide a mechanism to load the driver on demand, or a binary update can easily brick the system...

Why are we making this change? It was somewhat intentional to not enable SASL by default (to reduce attack surface, e.g. CVE-2019-13565), is this functionality being used by a lot of consumers?