Bug 333961

Summary: mount.gfs and mount.gfs2 don't not know -n option
Product: Red Hat Enterprise Linux 5 Reporter: Mark Hlawatschek <hlawatschek>
Component: gfs-utilsAssignee: Abhijith Das <adas>
Status: CLOSED ERRATA QA Contact: GFS Bugs <gfs-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 5.0CC: grimme, kanderso, kzak, rkenna, swhiteho
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2008-0350 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-21 17:20:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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:
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 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
this.

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.

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