Bug 840396 - mount command does not show all GFS2 mount options on a mounted volume
mount command does not show all GFS2 mount options on a mounted volume
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
16
Unspecified Unspecified
medium Severity low
: ---
: ---
Assigned To: Steve Whitehouse
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 736776
  Show dependency treegraph
 
Reported: 2012-07-16 05:04 EDT by Milos Jakubicek
Modified: 2012-10-03 06:54 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-03 06:54:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch (492 bytes, patch)
2012-08-20 07:15 EDT, Steve Whitehouse
no flags Details | Diff

  None (edit)
Description Milos Jakubicek 2012-07-16 05:04:41 EDT
Description of problem:

Mounting a GFS2 volume by the following line in /etc/fstab

/dev/mapper/mpathcp1 /mnt gfs2 defaults,statfs_quantum=0,noauto,noquota,noatime 1 0

and running "mount" then shows only:

/dev/mapper/mpathcp1 on /mnt type gfs2 (rw,noatime)

Even though it seems the other options have been applied as well (stafs_quantum, noquota), there is no way how to see these on the mounted volume:(

Version-Release number of selected component (if applicable):

gfs2-utils-3.1.3-1.fc16.x86_64
Comment 1 Steve Whitehouse 2012-07-16 05:15:31 EDT
What does:

cat /proc/mounts

say? That should have all the options. Also the version of gfs2-utils that you are using should not have a mount.gfs2 helper, so if there is an issue, then it is in util-linux-ng rather than gfs2-utils
Comment 2 Milos Jakubicek 2012-07-16 08:21:49 EDT
cat /proc/mounts says pretty much the same, just with different formatting:

/dev/mapper/mpathcp1 /mnt gfs2 rw,noatime 0 0

And yes, no mount.gfs2 anymore => reassigning.
Comment 3 Steve Whitehouse 2012-07-17 04:10:27 EDT
Looking at the options, I'd have expected statfs_quantum to show up, at least, which is a bit odd. The mount command gets its info from mtab, which sometimes has different options to /proc/mounts. However, if the statfs_quantum is set to 0, then that should show up under /proc/mounts

So... when you say that you mounted gfs2 using the line in fstab, how did you do that? Via the gfs2 script, or just via a mount command on the command line. If the latter, what was the exact command line that you used?
Comment 4 Milos Jakubicek 2012-07-17 09:15:54 EDT
I was mounting by "mount /mnt" => the /etc/fstab line should be used.

Btw. also on regular basis I'm mounting by "mount /mountpoint" in /etc/rc.d/rc.local, because the initscript in F16 seems to be broken (or it is a consequence of doing a direct yum update from F15, I don't know yet and therefore have not reported yet) and tries to mount the gfs volume before cman and gfs2-cluster are running (or at least one of them), the results being a kern_stop for that volume on all nodes:(
Comment 5 Andrew Price 2012-07-17 09:53:14 EDT
(In reply to comment #4)
> I was mounting by "mount /mnt" => the /etc/fstab line should be used.
> 
> Btw. also on regular basis I'm mounting by "mount /mountpoint" in
> /etc/rc.d/rc.local, because the initscript in F16 seems to be broken (or it
> is a consequence of doing a direct yum update from F15, I don't know yet and
> therefore have not reported yet) and tries to mount the gfs volume before
> cman and gfs2-cluster are running (or at least one of them), the results
> being a kern_stop for that volume on all nodes:(

This is probably due to the sysvinit->systemd transition: while gfs2's init scripts were updated to systemd units, the cman etc initscripts weren't, possibly causing a broken startup order. This should be fixed in Fedora 17 as cman has gone away, and also gfs2's mount order is handled by systemd itself. However, it is a separate issue so it would be best to open a separate bz for it if it's still a problem.
Comment 6 Steve Whitehouse 2012-07-18 10:21:09 EDT
I've just tried this in f17. It seems to work so long as statfs_quantum is not set to 0. That is a bit odd, since the code clearly says:

      val = sdp->sd_tune.gt_statfs_quantum;
        if (val != 30)
                seq_printf(s, ",statfs_quantum=%d", val);

So it should print when set to anything except the default of 30. But... looking elsewhere I also see this:

    gt->gt_quota_quantum = args.ar_quota_quantum;
        if (args.ar_statfs_quantum) {
                gt->gt_statfs_slow = 0;
                gt->gt_statfs_quantum = args.ar_statfs_quantum;
        }
        else {
                gt->gt_statfs_slow = 1;
                gt->gt_statfs_quantum = 30;
        }

So it looks like we reset the quantum to be 30 secs when we set statfs_slow on. So we have a mismatch between our internal variables and the external representation in this case. So I don't think there is any issue relating to the mount command at all. It looks to me as if this is working mostly as expected, bar the 0 value for statfs_quantum.

Does this work if you specify a non-zero statfs_quantum too?
Comment 7 Milos Jakubicek 2012-07-18 16:38:29 EDT
Steve, indeed, different values than zero are shown in mount :)
Nevertheless I'd expect all the mount options (e.g. noquota) to be shown, otherwise its a bit confusing.
Comment 8 Steve Whitehouse 2012-07-19 07:37:20 EDT
Yes, just trying to track down where the actual issue lies first, and it sounds like it is a kernel issue, rather than userland.

There are some (backward compatibility) reasons why some of the options don't get shown, or only get shown in certain ways. GFS has the quota=[on/off/account] option so that noquota is a synonym for quota=off which is also the default and thus doesn't get shown. So we could show quota=off when noquota is requested, but not noquota itself - at least not without adding significant extra complication to the argument parsing code.

The issue with statfs_quantum=0 just looks like a bug to me, so we'll certainly fix that one.
Comment 9 Steve Whitehouse 2012-08-20 07:15:54 EDT
Created attachment 605674 [details]
Proposed patch

As posted upstream
Comment 10 Steve Whitehouse 2012-10-03 06:54:35 EDT
Now in Linus' tree, so fixed upstream.

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