Recently someone mentioned they were having a problem with quotacheck.
A few days later I ran into what i suspect  is the same problem.  What
happened is that in a world writable  directory someone created a file
via NFS as root.  This was mapped to the anonymous user.  Over the NFS
protocol this appeared to  be the standard  nobody user (which is a 16
bit -2 I  believe).  However on the  file system the uid was  actually
set  to a  32 bit  -2 (NetBSD  uses   32 bit  uids).   This  number is
4294967294.  When  quotacheck scans the  file system there  is a point
where it  loops from 0  to the largest uid  found on the system.  When
this  value   is 4294967294  quotacheck  takes  a   very long time  to
complete.  So long that I've never had the patience to see how long it
actually takes...

Anyway  use find to search  your  file system for   files owned by uid
4294967294  and  chown them to  nobody (or  something).   Then I would
recommend you update your exports file  to contain the -maproot=nobody
option to prevent new files like this from being created.

Lastly,  the quotacheck algorithm needs  to be modified to better hand
such sparse uid space cases.  The other question is does it make sense
for the NFS code to default mapping root queries to uid 4294967294?


					--Greg