Red Hat Bugzilla – Bug 333961
mount.gfs and mount.gfs2 don't not know -n option
Last modified: 2010-01-11 22:33:21 EST
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)
Steps to Reproduce:
1. mount -n -t gfs /dev/vg_test/lv_test /mnt/test/
/sbin/mount.gfs: invalid option -- n
-n option should work. Don't write to /etc/mtab
Also, mount.gfs does not know -f option
The same command is used for both gfs and gfs2. Changes subject line to reflect
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
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
I don't know how many people really want these two options and if it's ok to
leave things as they are.
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
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)
checked in fix to cvs HEAD and RHEL5
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.