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.