I want to share a solution to the problem with 
repquota , which I encountered today. Hopefully help someone not to waste time on the proceedings.
Worth FreeBSD 6.2. Regularly using 
repquota collects statistics on the use of space by users.
Symptoms of the problem: when you run 
repquota or 
quotacheck process starts loading the CPU, and most importantly, it crashes the disks for disk operations. The server almost falls.
')
Symptoms are removed by killing the 
repquota or 
quotacheck .
But it turned out that the file /home/quota.user reached unimaginable sizes: 64G. I noticed by accident - according to the backups logs.
The problem was completely cured by the following:
rm /home/quota.user
rm /home/quota.group
quotaoff /usr/home
quotacheck /usr/home
quotaon /usr/home
UPDRoot of evil
The essence was in the format of the file quota.user. Quota information is stored in a file at an offset uid * 32. Accordingly, if the uid is large (or negative), the file is too large, and repquota spends a lot of time viewing the file to get to the last uid.
Read more on 
opennet and 
the freebsd mailing list .
There was no user with a huge uid, but there was a file with uid 2147483647. It was created by Exim, due to the fact that there was a user in the system with a login consisting of 11 digits. When assigning rights to the user's mail, Exim began to think that it was a uid, not a name.
In general, something like that.