>It was looked at, and as you can see, fsirand(8) is already in the tree.
>I believe the completion of this is currently stalled on a good /dev/random
>implementation.

Uh, but ... how are you going to get high-bandwidth randomness to do
anything useful and `strongly random' with an entire partition worth
of inodes -- 9 Gigabytes or more, for some installations?  

Conversely, if the high-quality randomness is really only used for the
first inode, can't an attacker simply wait until they snoop a mount
request, and use that (and subsequent readdir() operations) and
the source of fsirand to guess the generation number of any inode?
(Think of this as a problem where each inode/ generation-number pair
you capture gives you another plaintext/cyphertext pair.)

So then: how do you smear the relatively few high-quality bits you've
got (presumably at boot time, or at best when single-user) across the
inodes of a really large filesystem?

Historically, didn't the original SunOS implementation get by without
high-quality randomness?  How good was that?  Anyone know of good
studies in breaking SunOS 4.x filehandles?

Last, since the current fsirand is so FFS-specific, and has to be run
on clean filesystems, the FS-specific fsck back-end (fsck_ffs) might
be a better place to put the functionality -- or even newfs.