Description of problem: When using the 'repquota' tool, kernel may sometime panic. Also, the repquota output (when kernel does not panic) displays USER ID's instead of USER NAMES. edquota does show right quota information! Version-Release number of selected component (if applicable): quota package version is : quota-3.09-1.21 kernel is : 2.4.9-e.35smp How reproducible: turn quotas off (quotaoff fsname) check quota (quotacheck -v fsname) turn quota on (quotaon fsname) repquota fsname Steps to Reproduce: 1. turn quotas off (quotaoff fsname) 2. check quota (quotacheck -v fsname) 3. turn quota on (quotaon fsname) 4. repquota fsname Actual results: when repquota does work, only userid's are shown where usernames should be. kernel panics sometimes when repquota runs Expected results: usernames instead of userids no kernel panic Additional info: I am using nss-ldap for user database, ldap is running on a seperate server. this server also is an nfs server the filesystems are on a CLARIION storage array, using a Qlogic adapter for connectivity
Created attachment 96843 [details] output of kernel panic from /var/log/messages
Created attachment 96844 [details] The /etc/fstab file from the server
Created attachment 96857 [details] Latest kernel panic - output from /var/log/messages - see first line about 'remove_free_dquot' Latest kernel panic - output from /var/log/messages - see first line about 'remove_free_dquot'.
Created attachment 101676 [details] patch to fix quota locking errors For RHEL2.1. This is a backport of a fix which is in the 2.4 kernel. Since running this patch we have had no more quota related crashes. It may still have bugs though...
thanks for the info - does this mean that if I'm running 2.4.9-e.40 or later I don't need the patch?
The patch is from BK cset 1.133 which became part of the 2.4.15 kernel. If you are running 2.4.9 then you need the patch. You can view the cset here: http://linus.bkbits.net:8080/linux-2.4/cset@1.133?nav=index.html|src/|src/fs|related/fs/dquot.c There are also some fixes for ext3 & quota which should be backported to the RH kernel but that does not seem to be causing us problems ATM.
Created attachment 109599 [details] Kernel panic We also seem to have this or a related problem. We get infrequent kernel panics, but they do not seem to be related to running repquota). Excerpt from syslog is attached.
Peter, if you have quotas enabled then you can get the in memory corruption. This does not always seem to cause the segfaults (see also bugs #53591 and #98837) in the userland tools. Sometimes you get just a truncated list of quotas and other times it might work. My patch from comment #4 solved all the problems at our site. This patch is still not in the RH kernel but if you want to try my patched kernel I can make it available, or you can build your own if you know how.
We applied the patch and haven't had any panics since. We also didn't notice any other adverse effects.
Occasionally I still see quota problems if I add a lot of new users (I guess new quota records is the issue). Once added, repquota does not display a complete list of quotas but edquota on the new users shows that the quota has been set. To fix this I do a quotaoff followed by a quotaon. I assume that the new records are not being synced to disk immediatly, but I don't know for sure. It is not causing corruption or crashed so for now I can live with it. I have not seen this problem after adding only one account.