Adam Strohl
2012-Feb-03 12:31 UTC
FreeBSD 9: Group quotas increase but don't decrease automatically
I'm running FreeBSD 9 on a number of systems and finally decided to take advantage of the quota system to enforce limits on my users. No real issues setting it all up aside from finding that http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/quotas.html needs to be updated. The new /etc/rc.conf entry is quota_enable="YES" not enable_quotas="YES" as it says (assuming it used to be this in 8.x?). I'll file a PR for this shortly. I did however run into a more serious issue (I think): A group or user's allocation as reported by repquota(8) will increases with new/growing files, however when a file is deleted or chgrped out of the quota's group, the amount of space reported by repquota(8) does not decrease. I have verified that the system does not register the freed space by going over the soft limit, being denied write, then deleting files. Even if I delete files which drop me below the soft quota limit, I will not be able to add them as I am still "over quota". So it does not appear to be reporting issue, the system really doesn't realize the usage has gone down. Interestingly the inode counts do decrease automatically/"instantly" as I would expect. Running quotacheck(8) fixes the issue and updates the allocation counts, but does not magically fix auto-updating, so needs to be done periodically which can be a bit intensive depending on file count. I see this on all FreeBSD 9 machines with quotas turned on. For now I have a cron script which tries to guess (based on changing inode counts, etc) if it should run quotacheck, and does so if needed (to avoid just blindly running it periodically). Anyone else run into this? Am I missing something? Known issue? Let me know if anyone wants more info, etc. I can also paste the work around "smart" cron script if anyone is interested (and I'm not missing something silly :P). -- Adam Strohl A-Team Systems http://ateamsystems.com/
Konstantin Belousov
2012-Feb-03 14:52 UTC
FreeBSD 9: Group quotas increase but don't decrease automatically
On Fri, Feb 03, 2012 at 07:30:54PM +0700, Adam Strohl wrote:> I'm running FreeBSD 9 on a number of systems and finally decided to take > advantage of the quota system to enforce limits on my users. > > No real issues setting it all up aside from finding that > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/quotas.html > needs to be updated. The new /etc/rc.conf entry is quota_enable="YES" > not enable_quotas="YES" as it says (assuming it used to be this in > 8.x?). I'll file a PR for this shortly. > > I did however run into a more serious issue (I think): > > A group or user's allocation as reported by repquota(8) will increases > with new/growing files, however when a file is deleted or chgrped out of > the quota's group, the amount of space reported by repquota(8) does not > decrease. I have verified that the system does not register the freed > space by going over the soft limit, being denied write, then deleting > files. Even if I delete files which drop me below the soft quota limit, > I will not be able to add them as I am still "over quota". So it does > not appear to be reporting issue, the system really doesn't realize the > usage has gone down. > > Interestingly the inode counts do decrease automatically/"instantly" as > I would expect. > > Running quotacheck(8) fixes the issue and updates the allocation counts, > but does not magically fix auto-updating, so needs to be done > periodically which can be a bit intensive depending on file count. > > I see this on all FreeBSD 9 machines with quotas turned on. > > For now I have a cron script which tries to guess (based on changing > inode counts, etc) if it should run quotacheck, and does so if needed > (to avoid just blindly running it periodically). > > Anyone else run into this? Am I missing something? Known issue? Let > me know if anyone wants more info, etc. I can also paste the work > around "smart" cron script if anyone is interested (and I'm not missing > something silly :P).This is a bug in +J code (even if you do not use +J). Do you have softupdates enabled on the volume ? If yes, try the following patch. diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c index 5b4b6b9..ed2db79 100644 --- a/sys/ufs/ffs/ffs_softdep.c +++ b/sys/ufs/ffs/ffs_softdep.c @@ -43,6 +43,7 @@ __FBSDID("$FreeBSD$"); #include "opt_ffs.h" +#include "opt_quota.h" #include "opt_ddb.h" /* @@ -6428,7 +6429,7 @@ softdep_setup_freeblocks(ip, length, flags) } #ifdef QUOTA /* Reference the quotas in case the block count is wrong in the end. */ - quotaref(vp, freeblks->fb_quota); + quotaref(ITOV(ip), freeblks->fb_quota); (void) chkdq(ip, -datablocks, NOCRED, 0); #endif freeblks->fb_chkcnt = -datablocks; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120203/86ca651b/attachment.pgp