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:
Also, mount.gfs does not know -f option
The same command is used for both gfs and gfs2. Changes subject line to reflect this.
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.
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.
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 http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs2/mount/mount.gfs2.c.diff?cvsroot=cluster&r1=1.27&r2=1.28 http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs2/mount/mount.gfs2.c.diff?cvsroot=cluster&only_with_tag=RHEL5&r1=1.20.2.7&r2=1.20.2.8
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