From owner-freebsd-stable@FreeBSD.ORG Fri Feb 3 12:30:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEBC4106566B for ; Fri, 3 Feb 2012 12:30:53 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from tali.ateamservers.com (tali.ateamservers.com [69.55.231.82]) by mx1.freebsd.org (Postfix) with ESMTP id B4A6C8FC0C for ; Fri, 3 Feb 2012 12:30:53 +0000 (UTC) Received: from [192.168.15.220] (unknown [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tali.ateamservers.com (Postfix) with ESMTPSA id 2336512E9BE6 for ; Fri, 3 Feb 2012 07:30:51 -0500 (EST) Message-ID: <4F2BD37E.70209@ateamsystems.com> Date: Fri, 03 Feb 2012 19:30:54 +0700 From: Adam Strohl Organization: A-Team Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: FreeBSD-Stable ML Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD 9: Group quotas increase but don't decrease automatically X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 12:30:53 -0000 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/