Some minor nits.

LGTM. There are a few minor nits but these are optional.

Keep existing code for platforms where humanize_number(3) is not available.

Looks mostly fine to me.

Refresh diff with svn head.

Reduce the patch back to original (NetBSD sync was merged).

Sync with NetBSD which added more boundary checks.

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.