Bug 333961 - mount.gfs and mount.gfs2 don't not know -n option
mount.gfs and mount.gfs2 don't not know -n option
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs-utils (Show other bugs)
5.0
All Linux
low Severity low
: ---
: ---
Assigned To: Abhijith Das
GFS Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-16 08:01 EDT by Mark Hlawatschek
Modified: 2010-01-11 22:33 EST (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2008-0350
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 13:20:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark Hlawatschek 2007-10-16 08:01:56 EDT
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:
Always

Steps to Reproduce:
1. mount -n -t gfs /dev/vg_test/lv_test /mnt/test/
2.
3.
  
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 08:18:44 EDT
Also, mount.gfs does not know -f option
Comment 3 Rob Kenna 2007-10-16 10:38:10 EDT
The same command is used for both gfs and gfs2.  Changes subject line to reflect
this.
Comment 5 Abhijith Das 2007-12-05 23:46:44 EST
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 07:01:29 EST
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-11 19:23:47 EST
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 13:20:09 EDT
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.

http://rhn.redhat.com/errata/RHBA-2008-0350.html

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