Bug 846296 - quotacheck on gfs2 with verbose flag gives misleading info
quotacheck on gfs2 with verbose flag gives misleading info
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: quota (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Pisar
Fedora Extras Quality Assurance
https://sourceforge.net/tracker/?func...
: Patch, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-07 07:26 EDT by Petr Pisar
Modified: 2013-07-04 07:44 EDT (History)
4 users (show)

See Also:
Fixed In Version: quota-4.01-4.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 846120
Environment:
Last Closed: 2013-07-04 07:44:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
[PATCH] Do not fiddle with quota files on XFS and GFS (1.48 KB, patch)
2013-01-31 07:34 EST, Petr Pisar
no flags Details | Diff
Upstream patch (1.48 KB, patch)
2013-02-05 02:45 EST, Petr Pisar
no flags Details | Diff

  None (edit)
Description Petr Pisar 2012-08-07 07:26:34 EDT
+++ This bug was initially created as a clone of Bug #846120 +++

quotacheck does not fail as described in the description below, but using the verbose flag with gfs2 gives these two lines of information that don't pertain to gfs2 quotas and are misleading:

quotacheck: Cannot stat old user quota file: No such file or directory
quotacheck: Old group file not found. Usage will not be substracted.

quotacheck actually succeeds and does the required math to update quota usage.

These verbose messages need to be turned off in gfs2's case.

[...]
--- Additional comment from adas@redhat.com on 2012-07-25 16:38:37 EDT ---

Upon further testing, it looks like these messages are debug messages that show up with -v. While they don't apply to gfs2 and should probably be cleaned up so as to not confuse the user, quotacheck actually works properly. When used w/o the -v option, it silently updates the quota file with any changes.

-----

This is output of development quotacheck on F17 kernel (3.5.0-2.fc17.x86_64):

# LANG=en_US.UTF-8 ~petr/quota/linuxquota-git/quotacheck -v /mnt/gfs/
quotacheck: Scanning /dev/mapper/vg_dhcp0122-gfs [/mnt/gfs] done
quotacheck: Cannot stat old user quota file on: No such file or directory. Usage will not be subtracted.
quotacheck: Old group file name could not been determined. Usage will not be subtracted.
quotacheck: Checked 1 directories and 1 files
quotacheck: Cannot turn user quotas off on /dev/mapper/vg_dhcp0122-gfs: Function not implemented
Kernel won't know about changes quotacheck did.

The file system is mounted with rw,seclabel,relatime,localflocks,quota=on,quota_quantum=1.

This is highly confusing output full of errors. I have a few questions to GFS developers:

(1) GFS2 maintains quotas in the file system without any auxiliary quota files (like extended file system does). Am I right?

(2) When is the quota accounting enabled? At mount time with quota=on option? After specific quotactl? How is quota accounting initialized if the file system is mounted with quota=on for the first time after the system has been used with disabled accounting? Who should calculate initial disk usage? User space, or kernel?

(3) Is it possible to enable/disable quotas on already mounted file systems? With quotactl instead of mount? Current gfs2(5) is a little bit fuzzy about switching quotas.
Comment 1 Abhijith Das 2012-08-07 09:42:06 EDT
(In reply to comment #0)
> +++ This bug was initially created as a clone of Bug #846120 +++
> 
> quotacheck does not fail as described in the description below, but using
> the verbose flag with gfs2 gives these two lines of information that don't
> pertain to gfs2 quotas and are misleading:
> 
> quotacheck: Cannot stat old user quota file: No such file or directory
> quotacheck: Old group file not found. Usage will not be substracted.
> 
> quotacheck actually succeeds and does the required math to update quota
> usage.
> 
> These verbose messages need to be turned off in gfs2's case.
> 
> [...]
> --- Additional comment from adas@redhat.com on 2012-07-25 16:38:37 EDT ---
> 
> Upon further testing, it looks like these messages are debug messages that
> show up with -v. While they don't apply to gfs2 and should probably be
> cleaned up so as to not confuse the user, quotacheck actually works
> properly. When used w/o the -v option, it silently updates the quota file
> with any changes.
> 
> -----
> 
> This is output of development quotacheck on F17 kernel (3.5.0-2.fc17.x86_64):
> 
> # LANG=en_US.UTF-8 ~petr/quota/linuxquota-git/quotacheck -v /mnt/gfs/
> quotacheck: Scanning /dev/mapper/vg_dhcp0122-gfs [/mnt/gfs] done
> quotacheck: Cannot stat old user quota file on: No such file or directory.
> Usage will not be subtracted.
> quotacheck: Old group file name could not been determined. Usage will not be
> subtracted.
> quotacheck: Checked 1 directories and 1 files
> quotacheck: Cannot turn user quotas off on /dev/mapper/vg_dhcp0122-gfs:
> Function not implemented
> Kernel won't know about changes quotacheck did.
> 
> The file system is mounted with
> rw,seclabel,relatime,localflocks,quota=on,quota_quantum=1.
> 
> This is highly confusing output full of errors. I have a few questions to
> GFS developers:
> 
> (1) GFS2 maintains quotas in the file system without any auxiliary quota
> files (like extended file system does). Am I right?

Yes. GFS2 has an internal quota file that's part of the filesystem and is hidden from the user. (It could however be seen when the gfs2meta fs is mounted by the gfs2 userland tools... the user should almost never have to mount the gfs2meta fs)

> 
> (2) When is the quota accounting enabled? At mount time with quota=on
> option? After specific quotactl? How is quota accounting initialized if the
> file system is mounted with quota=on for the first time after the system has
> been used with disabled accounting? Who should calculate initial disk usage?
> User space, or kernel?

quota=on or quota=account enables quota accounting. If the fs has been in use w/o accounting, it's the user/admin's responsibility to run quotacheck on the fs to bring quotas up to speed.

> 
> (3) Is it possible to enable/disable quotas on already mounted file systems?
> With quotactl instead of mount? Current gfs2(5) is a little bit fuzzy about
> switching quotas.

There isn't a way to do this using quotactl. Only remount w/ quota=on or quota=off can accomplish this.
Comment 2 Petr Pisar 2012-08-07 11:02:47 EDT
(In reply to comment #1)
> > (1) GFS2 maintains quotas in the file system without any auxiliary quota
> > files (like extended file system does). Am I right?
> 
> Yes. GFS2 has an internal quota file that's part of the filesystem and is
> hidden from the user. (It could however be seen when the gfs2meta fs is
> mounted by the gfs2 userland tools... the user should almost never have to
> mount the gfs2meta fs)
>
Is the hidden quota file accounted by GFS2 too (e.g. added to UID=0 user's usage), or is the hidden file excluded from accounting?

> > (2) When is the quota accounting enabled? At mount time with quota=on
> > option? After specific quotactl? How is quota accounting initialized if the
> > file system is mounted with quota=on for the first time after the system has
> > been used with disabled accounting? Who should calculate initial disk usage?
> > User space, or kernel?
> 
> quota=on or quota=account enables quota accounting. If the fs has been in
> use w/o accounting, it's the user/admin's responsibility to run quotacheck
> on the fs to bring quotas up to speed.
>
Does GFS2 accept these new values from user space while the accounting is off? Does the file system accept the new values while the file system is mounted read-only (and postpone flushing the settings to the hidden file until remounted read-only)?
Comment 3 Abhijith Das 2012-08-07 12:12:44 EDT
(In reply to comment #2)
> > Yes. GFS2 has an internal quota file that's part of the filesystem and is
> > hidden from the user. (It could however be seen when the gfs2meta fs is
> > mounted by the gfs2 userland tools... the user should almost never have to
> > mount the gfs2meta fs)
> >
> Is the hidden quota file accounted by GFS2 too (e.g. added to UID=0 user's
> usage), or is the hidden file excluded from accounting?
> 

Yes it is excluded from accounting. There are also a bunch of other hidden metadata files such as journals, resource index etc that are excluded from accounting.

> > 
> > quota=on or quota=account enables quota accounting. If the fs has been in
> > use w/o accounting, it's the user/admin's responsibility to run quotacheck
> > on the fs to bring quotas up to speed.
> >
> Does GFS2 accept these new values from user space while the accounting is
> off? Does the file system accept the new values while the file system is
> mounted read-only (and postpone flushing the settings to the hidden file
> until remounted read-only)?

By values, I assume you mean the warn/limit values? 

1. If so, yes, they are accepted while accounting is off (although setquota doesn't seem to allow it:
setquota: Cannot find mountpoint for device /dev/loop5
setquota: No correct mountpoint specified.
setquota: Cannot initialize mountpoint scan.

2. No, they are not accepted when the fs is mounted RO (although, there seems to be a bug in this test case I just discovered and am investigating).
Comment 4 Abhijith Das 2012-08-07 12:14:51 EDT
> 
> By values, I assume you mean the warn/limit values? 
> 
> 1. If so, yes, they are accepted while accounting is off (although setquota
> doesn't seem to allow it:
> setquota: Cannot find mountpoint for device /dev/loop5
> setquota: No correct mountpoint specified.
> setquota: Cannot initialize mountpoint scan.

Just to add here: I think we're ok with one way or another. If most fs don't allow setting limit/warn values when quotas are off, gfs2 can do the same thing.
Comment 5 Petr Pisar 2012-08-08 03:36:47 EDT
(In reply to comment #3)
> > > quota=on or quota=account enables quota accounting. If the fs has been in
> > > use w/o accounting, it's the user/admin's responsibility to run quotacheck
> > > on the fs to bring quotas up to speed.
> > >
> > Does GFS2 accept these new values from user space while the accounting is
> > off? Does the file system accept the new values while the file system is
> > mounted read-only (and postpone flushing the settings to the hidden file
> > until remounted read-only)?
> 
> By values, I assume you mean the warn/limit values? 
> 
No. I was thinking about setting usage. You said user space has to initialize the usage values if the accounting is requested for the first time.

This is traditional role of quotacheck. It counts the usage for each user and it sends the values to the kernel.

To prevent from races, quotacheck tries to switch off accounting and remount the file system read-only for the time of updating the usage values. Also it tries to check values stored in quota files (what it irrelevant on GFS2). Thus you get a lot of warnings in verbose mode because some of these operations fail.

I'd like to augment description of GFS2 quota capabilities in quotacheck to skip these unnecessary operation when handling with GFS2.
Comment 6 Abhijith Das 2012-08-08 12:19:59 EDT
> No. I was thinking about setting usage. You said user space has to
> initialize the usage values if the accounting is requested for the first
> time.
> 
> This is traditional role of quotacheck. It counts the usage for each user
> and it sends the values to the kernel.
> 
> To prevent from races, quotacheck tries to switch off accounting and remount
> the file system read-only for the time of updating the usage values. Also it
> tries to check values stored in quota files (what it irrelevant on GFS2).
> Thus you get a lot of warnings in verbose mode because some of these
> operations fail.
> 
> I'd like to augment description of GFS2 quota capabilities in quotacheck to
> skip these unnecessary operation when handling with GFS2.

For gfs2 turning off accounting or remounting don't have an effect because there can be other nodes mounting gfs2 rw,quota=on. For this reason, quota values are always fuzzy on gfs2 and that's ok. I believe the patch I sent to quota-tools to support quotacheck on gfs2 addresses this by skipping RO mount for gfs2: http://linuxquota.git.sourceforge.net/git/gitweb.cgi?p=linuxquota/linuxquota;a=commit;h=fa920711b4bbb9e61358a7f488f0a645ef221321. 
These warnings might be from a portion of code that I missed.
Comment 7 Petr Pisar 2013-01-31 07:34:12 EST
Created attachment 690870 [details]
[PATCH] Do not fiddle with quota files on XFS and GFS


XFS and GFS have no quota files. Skip unnecessary examination and
rename of these files when running quotacheck.

Signed-off-by: Petr Písař <ppisar@redhat.com>
---
 quotacheck.c | 9 +++++++++
 1 file changed, 9 insertions(+)
Comment 8 Petr Pisar 2013-02-05 02:45:35 EST
Created attachment 693189 [details]
Upstream patch
Comment 9 Petr Pisar 2013-02-05 03:37:18 EST
Fixed as quota-4.01-4.fc19 in F19.
Comment 10 Fedora Update System 2013-02-05 03:52:09 EST
quota-4.00-7.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/quota-4.00-7.fc18
Comment 11 Fedora Update System 2013-02-05 03:56:48 EST
quota-4.00-6.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/quota-4.00-6.fc17
Comment 12 Fedora Update System 2013-02-15 19:54:19 EST
quota-4.00-6.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 13 Fedora Update System 2013-02-15 20:00:46 EST
quota-4.00-7.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 14 Fedora End Of Life 2013-07-04 03:04:50 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Note You need to log in before you can comment on or make changes to this bug.