kern/114766: [quotas] Disk quota does not work as expected

[Helmut Schneider]

The following reply was made to PR kern/114766; it has been noted by GNATS.

From: "Helmut Schneider" <***@gmx.de>
To: <bug-***@FreeBSD.org>
Cc:
Subject: Re: kern/114766: [quotas] Disk quota does not work as expected
Date: Thu, 6 Mar 2008 19:42:58 +0100

I am unable to duplicate this problem.
I think this is an error on the submitters part.
quotacheck /home
quotaon /home
chown ....
repquota ...
du ...
The key step is running quotacheck before actually turning
That would explain all the fix ups quotacheck did later as
seen in the submitters follow up message.
Enabling quotas for /home in /etc/fstab makes sure that
quotacheck is run before enabling quotas for the file system at
boot time.

Quota is enabled in fstab and rc.conf:

/dev/ad0s2a /home ufs rw,userquota,groupquota 2 2
quota_enable="YES"
check_quotas="YES"

I might do something fundamentally wrong but I can reproduce this on 2
machines (both 6.3-RELEASE). On both dovecot is active (Maildir is
/home/$USER/Maildir). Not sure if this is related.

[***@abc ~]# quotacheck -vvv -a
*** Checking user and group quotas for /dev/ad0s2a (/home)
[***@abc ~]# quotacheck -vvv -a
*** Checking user and group quotas for /dev/ad0s2a (/home)
/home: web6 fixed (user): inodes 2005 -> 2006 blocks 49416 -> 49432
/home: web6 fixed (group): inodes 2005 -> 2006 blocks 49416 -> 49432
[***@abc ~]# quotacheck -vvv -a
*** Checking user and group quotas for /dev/ad0s2a (/home)
/home: web24 fixed (user): inodes 2587 -> 2588 blocks 49864 -> 49876
/home: web24 fixed (group): inodes 2587 -> 2588 blocks 49864 -> 49876
[***@abc ~]#

[Mike Pritchard]

Post by Helmut Schneider
The following reply was made to PR kern/114766; it has been noted by GNATS.
Subject: Re: kern/114766: [quotas] Disk quota does not work as expected
Date: Thu, 6 Mar 2008 19:42:58 +0100

I am unable to duplicate this problem.
I think this is an error on the submitters part.
quotacheck /home
quotaon /home
chown ....
repquota ...
du ...
The key step is running quotacheck before actually turning
That would explain all the fix ups quotacheck did later as
seen in the submitters follow up message.
Enabling quotas for /home in /etc/fstab makes sure that
quotacheck is run before enabling quotas for the file system at
boot time.

/dev/ad0s2a /home ufs rw,userquota,groupquota 2 2
quota_enable="YES"
check_quotas="YES"
I might do something fundamentally wrong but I can reproduce this on 2
machines (both 6.3-RELEASE). On both dovecot is active (Maildir is
/home/$USER/Maildir). Not sure if this is related.
*** Checking user and group quotas for /dev/ad0s2a (/home)
*** Checking user and group quotas for /dev/ad0s2a (/home)
/home: web6 fixed (user): inodes 2005 -> 2006 blocks 49416 -> 49432
/home: web6 fixed (group): inodes 2005 -> 2006 blocks 49416 -> 49432
*** Checking user and group quotas for /dev/ad0s2a (/home)
/home: web24 fixed (user): inodes 2587 -> 2588 blocks 49864 -> 49876
/home: web24 fixed (group): inodes 2587 -> 2588 blocks 49864 -> 49876

Are you running quotacheck while there are users active, or the
machine is accepting mail deliveries? Running quotacheck on
an active file system will generate those type of fixups, due
to buffered data in the kernel not being in sync with
the disk data at that point.

Quotacheck is similar to fsck, in that the file system should not be in use
at the time of the check and the intended use is to rebuild / update the
quota data files in the event of a system crash or to build an initial
quota usage data base.

[Helmut Schneider]

Post by Mike Pritchard
Are you running quotacheck while there are users active, or the
machine is accepting mail deliveries? Running quotacheck on
an active file system will generate those type of fixups, due
to buffered data in the kernel not being in sync with
the disk data at that point.

Yes, but I ran "quotacheck -va" a few minutes ago and it reported many
fixups. I checked the logfiles and the last access for a specific user, it
was yesterday morning. I even rebooted the machine yesterday evening.
Shouldn't at least a reboot fix/flush all those entries?

Again:

[***@mvt ~]# cat /etc/rc.conf | grep quota
quota_enable="YES"
check_quotas="YES"
[***@mvt ~]# cat /etc/fstab | grep quota
/dev/ar0s2g /home ufs rw,userquota,groupquota
2 2
[***@mvt ~]#

[Mike Pritchard]

Post by Mike Pritchard
Are you running quotacheck while there are users active, or the
machine is accepting mail deliveries? Running quotacheck on
an active file system will generate those type of fixups, due
to buffered data in the kernel not being in sync with
the disk data at that point.

Yes, but I ran "quotacheck -va" a few minutes ago and it reported many fixups. I checked the logfiles and the last access
for a specific user, it was yesterday morning. I even rebooted the machine yesterday evening. Shouldn't at least a reboot
fix/flush all those entries?
quota_enable="YES"
check_quotas="YES"
/dev/ar0s2g /home ufs rw,userquota,groupquota 2 2

Which version of FreeBSD are you running? There are a number of
fixes that made it into 6.3 that may solve this problem.

[Mike Pritchard]

Post by Mike Pritchard
Are you running quotacheck while there are users active, or the
machine is accepting mail deliveries? Running quotacheck on
an active file system will generate those type of fixups, due
to buffered data in the kernel not being in sync with
the disk data at that point.

Yes, but I ran "quotacheck -va" a few minutes ago and it reported many fixups. I checked the logfiles and the last access
for a specific user, it was yesterday morning. I even rebooted the machine yesterday evening. Shouldn't at least a reboot
fix/flush all those entries?

Ignore my previous message asking what version you are running. I see
that you are running 6.3.

You stated that the users mail files are stored in /home, which probably
means the file system is active, even if no users were actually logged
in and using it. Quotacheck is not designed to be run on an active
file system.

Edit /etc/rc.d/quota and add the -v option to the quotacheck command
there. If quotacheck updates the usage information during boot up after
a clean shutdown, then there is a problem somewhere, unless it was something
updated on the file system during the boot process.

[Helmut Schneider]

Post by Mike Pritchard

Post by Helmut Schneider

Post by Mike Pritchard
Are you running quotacheck while there are users active, or the
machine is accepting mail deliveries? Running quotacheck on
an active file system will generate those type of fixups, due
to buffered data in the kernel not being in sync with
the disk data at that point.

Yes, but I ran "quotacheck -va" a few minutes ago and it reported many
fixups. I checked the logfiles and the last access for a specific
user, it was yesterday morning. I even rebooted the machine yesterday
evening. Shouldn't at least a reboot fix/flush all those entries?

Ignore my previous message asking what version you are running. I see
that you are running 6.3.
You stated that the users mail files are stored in /home, which probably
means the file system is active, even if no users were actually logged
in and using it. Quotacheck is not designed to be run on an active
file system.

OK.

Post by Mike Pritchard
Edit /etc/rc.d/quota and add the -v option to the quotacheck command
there. If quotacheck updates the usage information during boot up after
a clean shutdown, then there is a problem somewhere, unless it was
something updated on the file system during the boot process.

Hm, there is no "quota" at all at boot time:

[***@teg ~]# dmesg -a | grep -ir quota
***@BSDHelmut:/usr/obj/usr/src/sys/SMP-WITH-QUOTA
[***@teg ~]#

According to "/etc/rc.d/quota", shouldn't there be at least a "Checking
quotas:" or a "Enabling quotas:" in dmesg?!

[Helmut Schneider]

Post by Helmut Schneider

Post by Helmut Schneider

Post by Mike Pritchard

Post by Helmut Schneider

Post by Mike Pritchard
Are you running quotacheck while there are users active, or the
machine is accepting mail deliveries? Running quotacheck on
an active file system will generate those type of fixups, due
to buffered data in the kernel not being in sync with
the disk data at that point.

Yes, but I ran "quotacheck -va" a few minutes ago and it reported many
fixups. I checked the logfiles and the last access for a specific
user, it was yesterday morning. I even rebooted the machine yesterday
evening. Shouldn't at least a reboot fix/flush all those entries?

Ignore my previous message asking what version you are running. I see
that you are running 6.3.
You stated that the users mail files are stored in /home, which probably
means the file system is active, even if no users were actually logged
in and using it. Quotacheck is not designed to be run on an active
file system.

OK.

Post by Mike Pritchard
Edit /etc/rc.d/quota and add the -v option to the quotacheck command
there. If quotacheck updates the usage information during boot up after
a clean shutdown, then there is a problem somewhere, unless it was
something updated on the file system during the boot process.

According to "/etc/rc.d/quota", shouldn't there be at least a "Checking
quotas:" or a "Enabling quotas:" in dmesg?!

quota_enable="YES"
check_quotas="YES"
enable_quotas="YES"
check_quotas="YES"
It is, actually, the reverse of the usual <servicename>_enable entry!
Have a look at /etc/defaults/rc.conf and you will see this.

&$$% §%&$ §%%§&!!

Did that change? http://www.freebsddiary.org/quotas.php
<SIC>

Thanks. Close the PR, please.

[Mike Pritchard]

Post by Helmut Schneider

According to "/etc/rc.d/quota", shouldn't there be at least a "Checking quotas:" or a "Enabling quotas:" in dmesg?!

quota_enable="YES"
check_quotas="YES"
enable_quotas="YES"
check_quotas="YES"
It is, actually, the reverse of the usual <servicename>_enable entry! Have a look at /etc/defaults/rc.conf and you will
see this.

&$$% ?%&$ ?%%?&!!
Did that change? http://www.freebsddiary.org/quotas.php
<SIC>

Ah, that would explain everything...Looks like enable_quotas appeared in 1999.
It is correctly documented in the FreeBSD handbook (whew!):

http://www.freebsd.org.doc/en_US.ISO8859-1/books/handbook/quotas.html

Looks like the FreeBSD diary is out of date.

Thanks Manolis for catching that...I just about to go hack quotacheck and supply
a patch to Helmut to try and figure out what was really going on here :)
Sorry I didn't catch that earlier myself.

Looks like the information in the handbook needs a little attention also, but
it is basically correct.

Thanks for your patience Helmut!

[Manolis Kiagias]

Post by Helmut Schneider

Post by Mike Pritchard

Post by Helmut Schneider

Post by Mike Pritchard
Are you running quotacheck while there are users active, or the
machine is accepting mail deliveries? Running quotacheck on
an active file system will generate those type of fixups, due
to buffered data in the kernel not being in sync with
the disk data at that point.

Yes, but I ran "quotacheck -va" a few minutes ago and it reported many
fixups. I checked the logfiles and the last access for a specific
user, it was yesterday morning. I even rebooted the machine yesterday
evening. Shouldn't at least a reboot fix/flush all those entries?

Ignore my previous message asking what version you are running. I see
that you are running 6.3.
You stated that the users mail files are stored in /home, which probably
means the file system is active, even if no users were actually logged
in and using it. Quotacheck is not designed to be run on an active
file system.

OK.

Post by Mike Pritchard
Edit /etc/rc.d/quota and add the -v option to the quotacheck command
there. If quotacheck updates the usage information during boot up after
a clean shutdown, then there is a problem somewhere, unless it was
something updated on the file system during the boot process.

According to "/etc/rc.d/quota", shouldn't there be at least a
"Checking quotas:" or a "Enabling quotas:" in dmesg?!

It should:

***@joshua:/usr/home/sonic$ dmesg -a |grep -ir quota
Checking quotas:
Enabling quotas:

Please check your rc.conf. You have these lines:

[***@mvt ~]# cat /etc/rc.conf | grep quota
quota_enable="YES"
check_quotas="YES"

While you should have:

enable_quotas="YES"
check_quotas="YES"

It is, actually, the reverse of the usual <servicename>_enable entry!
Have a look at /etc/defaults/rc.conf and you will see this.

[l***@FreeBSD.org]

Synopsis: [quotas] Disk quota does not work as expected

State-Changed-From-To: feedback->open
State-Changed-By: linimon
State-Changed-When: Sat Mar 8 05:35:04 UTC 2008
State-Changed-Why:
Feedback received; problem persists.

http://www.freebsd.org/cgi/query-pr.cgi?pr=114766

[r***@FreeBSD.org]

Synopsis: [quotas] Disk quota does not work as expected

State-Changed-From-To: open->closed
State-Changed-By: remko
State-Changed-When: Mon Mar 10 13:42:24 UTC 2008
State-Changed-Why:
Helmut reports this can be closed, the logic was reverted for the quota
support

http://www.freebsd.org/cgi/query-pr.cgi?pr=114766