"Greg A. Woods" writes:
> Is quotacheck always so ploddingly slow on big filesystems?

Drat.. I *knew* there was a bug/problem I'd encountered with 
quotacheck, and forgot to do something about.. :(

> I started quotacheck on an 100GB filesystem with only a bit of space
> used by a few hundred files and it's been running now for over an hour
> and has accumulated almost that much CPU time:
> 
> # df -mil
> Filesystem  1M-blocks     Used    Avail %Cap    iUsed  iAvail %iCap Mounted o
> n
> /dev/sd0a        2908      669     2093  24%    20197   726297   2% /
> /dev/sd0e        3441        9     3259   0%      896   880382   0% /var
> mfs:121           242        0      230   0%        5    62201   0% /tmp
> /dev/raid0a     17226    11236     5129  68%   251353  1968549  11% /build
> /dev/raid1a    104305     5098    93990   5%      367  6680591   0% /mfbd
> 
> USER    PID %CPU %MEM   VSZ   RSS TT STAT STARTED     TIME COMMAND
> root  20800  6.3  0.0   408   308 p3 R     1:31PM 57:22.96 quotacheck -v /mfb
> d 

I'll bet you have a file, somewhere, owned by UserID "-1" (or "-2" or 
whatever).  This (signed) value gets happily mapped to (unsigned)
"highid[type]" and means that the loop:

	for (lastid = highid[type], id = 0; id <= lastid; id++) {

(quotacheck.c:update()) gets done some u_long number of times before 
it actually completes.  Needless to say, even moderatly fast CPU's 
still take a while to move through u_long worth of anything :(

I "fixed" the problem with a "find" to locate the offending files and 
then chowning them, but then never got around to actually looking 
into how to properly fix quotacheck.c.  (Some sort of userID array, 
perhaps?)

Later...

Greg Oster