Date: Fri, 3 Feb 2012 16:48:48 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Adam Strohl <adams-freebsd@ateamsystems.com> Cc: Kirk McKusick <mckusick@mckusick.com>, FreeBSD-Stable ML <freebsd-stable@freebsd.org> Subject: Re: FreeBSD 9: Group quotas increase but don't decrease automatically Message-ID: <20120203144848.GX3283@deviant.kiev.zoral.com.ua> In-Reply-To: <4F2BD37E.70209@ateamsystems.com> References: <4F2BD37E.70209@ateamsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--4PR/+zdSfVlxyWed Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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= =20 > advantage of the quota system to enforce limits on my users. >=20 > No real issues setting it all up aside from finding that=20 > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/quotas.html=20 > needs to be updated. The new /etc/rc.conf entry is quota_enable=3D"YES"= =20 > not enable_quotas=3D"YES" as it says (assuming it used to be this in=20 > 8.x?). I'll file a PR for this shortly. >=20 > I did however run into a more serious issue (I think): >=20 > A group or user's allocation as reported by repquota(8) will increases=20 > with new/growing files, however when a file is deleted or chgrped out of= =20 > the quota's group, the amount of space reported by repquota(8) does not= =20 > decrease. I have verified that the system does not register the freed=20 > space by going over the soft limit, being denied write, then deleting=20 > files. Even if I delete files which drop me below the soft quota limit,= =20 > I will not be able to add them as I am still "over quota". So it does= =20 > not appear to be reporting issue, the system really doesn't realize the= =20 > usage has gone down. >=20 > Interestingly the inode counts do decrease automatically/"instantly" as= =20 > I would expect. >=20 > Running quotacheck(8) fixes the issue and updates the allocation counts,= =20 > but does not magically fix auto-updating, so needs to be done=20 > periodically which can be a bit intensive depending on file count. >=20 > I see this on all FreeBSD 9 machines with quotas turned on. >=20 > For now I have a cron script which tries to guess (based on changing=20 > inode counts, etc) if it should run quotacheck, and does so if needed=20 > (to avoid just blindly running it periodically). >=20 > Anyone else run into this? Am I missing something? Known issue? Let=20 > me know if anyone wants more info, etc. I can also paste the work=20 > around "smart" cron script if anyone is interested (and I'm not missing= =20 > 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$"); =20 #include "opt_ffs.h" +#include "opt_quota.h" #include "opt_ddb.h" =20 /* @@ -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 =3D -datablocks; --4PR/+zdSfVlxyWed Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk8r89AACgkQC3+MBN1Mb4hHzgCgqyqrjjVlffSzYViKoIpEeJUE +10AoJIA1OgMzlNiI9V5+FYsRBW+nDJX =caZA -----END PGP SIGNATURE----- --4PR/+zdSfVlxyWed--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120203144848.GX3283>