Bug 333961 - mount.gfs and mount.gfs2 don't not know -n option
Summary: mount.gfs and mount.gfs2 don't not know -n option
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs-utils
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Abhijith Das
QA Contact: GFS Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2007-10-16 12:01 UTC by Mark Hlawatschek
Modified: 2010-01-12 03:33 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2008-05-21 17:20:09 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0350 normal SHIPPED_LIVE gfs2-utils bug fix update 2008-05-20 12:44:56 UTC

Description Mark Hlawatschek 2007-10-16 12:01:56 UTC
Description of problem:
mount.gfs does not know -n option

Version-Release number of selected component (if applicable):
mount.gfs2 0.1.38 (built Sep 25 2007 12:41:36)

How reproducible:

Steps to Reproduce:
1. mount -n -t gfs /dev/vg_test/lv_test /mnt/test/
Actual results:
/sbin/mount.gfs: invalid option -- n

Expected results:
-n option should work. Don't write to /etc/mtab

Additional info:

Comment 1 Mark Hlawatschek 2007-10-16 12:18:44 UTC
Also, mount.gfs does not know -f option

Comment 3 Rob Kenna 2007-10-16 14:38:10 UTC
The same command is used for both gfs and gfs2.  Changes subject line to reflect

Comment 5 Abhijith Das 2007-12-06 04:46:44 UTC
Ugh. For a moment I thought this was easy to implement... not so.
Firstly, the mount(8) program only passes the -n, -v and -o options to the mount
helpers (mount.gfs2, mount.nfs, etc). This means, we can't use -f through mount.

I implemented the -n option on gfs2 but it breaks umount(8)... here's how:
The -n option comes to the mount helper through mount(8). mount.gfs2 does the
right thing by completing the mount and not updating /etc/mtab (-n option).

Next, when you umount(8) this mounted filesystem, it tries to determine the
filesystem type from /etc/mtab, which doesn't have an entry for this filesystem
because we used the -n option during mount. umount(8) can't determine the
filesystem type and hence doesn't know about our umount.gfs2 helper. It calls
umount(2) systemcall instead. This breaks our unmounting logic (not withdrawing
from mountgroup). There is no immediate sign of anything bad happening as
umount(2) unmounts the filesystem, and gets rid of the /proc/mounts entry.
But, next time we try to mount, gfs_controld will complain that the filesystem
is already mounted because umount.gfs2 didn't run and hence didn't unmount from
the mountgroup.

We can persuade the util-linux guys to fix mount(8) and umount(8) to pass down
the -f option to the helpers and also use /proc/mounts to determine filesystem
type to correctly support the -n option. Or, we can implement these two options
in mount.gfs2 and umount.gfs2 and document a caveat to say that people should
use mount.gfs2 and umount.gfs2 directly instead of through mount(8) and
umount(8). I don't know if there are other issues in using mount.gfs2 and
umount.gfs2 directly.

I don't know how many people really want these two options and if it's ok to
leave things as they are.

Comment 6 Mark Hlawatschek 2007-12-12 12:01:29 UTC
When gfs is used as the root filesystem, it will eventually be remounted 
by /etc/sc.sysinit with the -n option. Please note, that I filed a bugzilla 
(https://bugzilla.redhat.com/show_bug.cgi?id=334171) that also addresses this 
part of the boot process. Also "/" will be "remounted" with -f option 
in /etc/rc.sysinit. 

Comment 8 Karel Zak 2008-01-12 00:23:47 UTC
The fake mount (mount -f) has been fixed by util-linux-2.13-0.45 (RHEL5.1). We
use exactly same mount/umount method for NFS. There shouldn't be a problem with GFS.

You need (like the other filesystems):
   mount -n -t gfs2 /foo /bar   (mount FS) 
   mount -f -t gfs2 /foo /bar   (update /etc/mtab)

Comment 12 errata-xmlrpc 2008-05-21 17:20:09 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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