Skip site navigation (1)Skip section navigation (2)
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>