The vnode reclamation code contains a race whereby a blocking condition may

The vnode reclamation code contains a race whereby a blocking condition may
occur between the clearing of an inode's bitmap bit, the removal of the
inode from the hash table, and the reclamation of the related vnode.

This can cause a file create to block on the vnode undergoing reclamation
if it happens to select the same inode (a case which is more likely these
days due to dirpref).  To avoid the race, adjust UFS to *NOT* allocate
inode numbers which are still present in the inode hash table.

This race is NOT a bug, or at least it is not a known cause for existing bugs,
but both the standard vnode code and especially the softupdates code is
so complex that I am not taking any chances.  As of this commit both FreeBSD-4,
FreeBSD-5, and DragonFly are known to have rare 'dup alloc' and other
related filesystem/inode panics and this commit removes one variable from
that equation.