Bug 235204 - mount.gfs2 doesn't work when _netdev is used in /etc/fstab.
mount.gfs2 doesn't work when _netdev is used in /etc/fstab.
Status: CLOSED DUPLICATE of bug 435906
Product: Fedora
Classification: Fedora
Component: gfs2-utils (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Feist
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-04 10:35 EDT by David J Craigon
Modified: 2008-03-05 12:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-05 12:11:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to fix the problem (678 bytes, patch)
2007-04-16 13:46 EDT, Robert Peterson
no flags Details | Diff

  None (edit)
Description David J Craigon 2007-04-04 10:35:53 EDT
I am using GFS2 to make a shared drive, and I'd like it to mount automatically
upon bootup. So I have set up my cluster, formatted my drive and so on.

My device file is /dev/sdb, and I want to mount it on /mnt/mailstore.

mount /dev/sdb /mnt/mailstore works fine.

So to get it to boot, I need to edit fstab. Here is my line:

/dev/sdb		/mnt/mailstore		gfs2	_netdev        0 0

I need _netdev, otherwise it will try and mount before the computer has network
access, set up the cluster etc.

Trouble is, mount.gfs2 doesn't understand this, and has a sulk. If I have this
in fstab then run:
mount /mnt/mailstore

I get:
/sbin/mount.gfs2: error 22 mounting /dev/sdb on /mnt/mailstore

Doing an strace on the "mount" program, the mount.gfs2 command being run is:
/sbin/mount.gfs2 /dev/sdb /mnt/mailstore -o rw,_netdev
Comment 1 Robert Peterson 2007-04-16 11:21:26 EDT
I haven't actually tried this yet, but I have some questions first.
In theory, the sequence of events should be something like this:

1. The gfs2 entry of the inittab should be ignored temporarily
   while the system is coming up.  
2. The cman init script should be called (assuming it's 
   chkconfiged on) which starts up the cluster.
3. The clvmd init script should be called (assuming it's
   chkconfiged on) which starts up the clustered lvm2 (clvmd).
4. The gfs2 init script should be called (assuming it's chkconfiged
   on, which should cause all the gfs2 mount points in /etc/fstab
   to be mounted at that time.

My question is: Is that sequence not working properly for you?

Also, after you get the mount error, can you please do these commands
and attach the results?

group_tool dump > /tmp/groupd.out
group_tool dump gfs > /tmp/gfs_controld.out

Also check dmesg and syslog (/var/log/messages) to see if there are
any interesting messages out there.

Additional questions:

1. Is your gfs2 storage shared between the cluster nodes or a local drive?
2. If you're using /dev/sdb, you must not be using lvm2 for your gfs2 
   partition.  Is that on purpose?  If sdb is shared, then access to
   the storage won't be controlled by clvmd, which might be problematic.
   If the storage is not shared, you might be using the lock_nolock
   lock manager, in which case, I think you should be able to mount it
   regardless of the state of the cluster.
Comment 2 David J Craigon 2007-04-16 11:43:25 EDT
Well, I hadn't noticed the gfs2 init.d script, so that solves my problem- I
should use this. So this bug is more like- GFS2 works differently from other
network filesystems.

I don't totally agree that your sequence of events is what should happen.

Here is what happens when an NFS drive starts at boot time:

1) /etc/rc.d/rc.sysinit mounts all drives, except those with _netdev in the
options field in /etc/fstab.
2) /etc/rc.d/init.d/network brings up network interfaces
3) /etc/rc.d/netfs mounts all file systems with _netdev in the options field.

The same process above also applies for Samba windows mounts, CIFS mounts, and
NCPFS mounts for Netware. We also use this feature here to mount (non-shared,
ext3 format) iSCSI volumes. I naturally assumed GFS and GFS2 were just another
type of network filesystem and would work the same way. So here's what I think
should happen.

1) The gfs2 entry of the inittab should be ignored temporarily
   while the system is coming up.  
2) The cman init script should be called (assuming it's 
   chkconfiged on) which starts up the cluster.
3) The clvmd init script should be called (assuming it's
   chkconfiged on) which starts up the clustered lvm2 (clvmd).
as you suggest, but then
4) netfs should recognize the _netdev tag, and mount the volume.

Why have a separate gfs2 script when this facility is already provided by the
netfs init script?

Using netdev in this way almost works too- apart from the fact that mount.gfs2
is (I think) broken.
Comment 3 David J Craigon 2007-04-16 11:47:26 EDT
To answer your additional questions- yes, /dev/sdb is a drive shared between two
computers- it's an iSCSI volume mounted on both. It's not a local drive. I am
using lock_dlm. 

I'm not using clvm because I see no need to- I have other ways of resizing the
/dev/sdb volume using my iSCSI target. And no it's not problematic- once the
drive is mounted it works just super. 
Comment 4 Robert Peterson 2007-04-16 13:46:38 EDT
Created attachment 152704 [details]
patch to fix the problem

I'm not 100% convinced that gfs2 should be within the realm of netfs,
since gfs and gfs2 don't export the file system through the network
and also since gfs2 can run independently (without the network).
However, given that the netfs init script has a reference to gfs and
has AJ Lewis (a former GFS guy) in the credits, I don't think it's a 
bad thing to make work.  Can't hurt I guess.

The error -22 (-EINVAL) was caused because the _netdev option was
rejected by the gfs/gfs2 mount helper, mount.gfs2.
This patch adds the _netdev mount option to mount.gfs2 so the mount is
successful.
Comment 5 Robert Peterson 2007-04-16 13:48:36 EDT
Adding Steve Whitehouse to the cc list to get his opinion on this.
Comment 6 Robert Peterson 2007-04-16 13:50:11 EDT
Adding Dave Teigland to the cc list to get his opinion on this.
Comment 7 David J Craigon 2007-04-18 10:20:42 EDT
I haven't read it all that carefully, but looking at the smbmount source in
function parse_mount_smb I think it just ignores fstab options it doesn't
understand:
http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/branches/SAMBA_4_0_RELEASE/source/client/smbmount.c?rev=21025&view=markup

Perhaps you should do the same.
-------------------------

If you have got a local GFS2 filesystem and you want it to mount pre-network,
just don't put _netdev in. Whether GFS2 is a network filesystem or not is kind
of irrelevant to the mount scripts- they just need to obey the option in fstab.
Comment 8 Robert Peterson 2007-04-19 12:13:03 EDT
I wasn't accurate the problem in comment #4.  I believe that the
gfs2 mount helper was actually passing the unknown _netdev option
up to the kernel mount code, and that's where the error was flagged.
That's similar to what smbfs seems to be doing.

Taking a cursory look at smbfs, it looks like the smbmount code you
pointed out just passes unknown mount options up the line.  However,
there's also code in the samba kernel code to complain about mount 
options it doesn't understand (like GFS2), which would seem to 
contradict what you're seeing.  I'd have to do a bunch of research 
to figure out why smb doesn't complain in the _netdev case.

AFAIK, the whole idea behind the opt_map code is to allow for some 
options to be passed to the kernel and others that aren't.  I think 
the idea came from the mount command source itself, and I think it 
was carried forward into the gfs2 mount helper.  Since _netdev isn't 
a valid mount option for the kernel code, it made sense to me to 
filter it out by the mount helper.

We could easily make the gfs2 mount helper filter out everything it 
doesn't understand and pass on the rest, but that was a design decision
made by the author of the helper, Dave Teigland, who is on the cc list 
for this bug.  I'll defer that decision to him.
Comment 9 David Teigland 2007-04-19 15:57:18 EDT
I agree entirely with comment #2.  I've always felt that having a gfs
init script was an ugly hack and that there must be a "right way" to do it.
_netdev and netfs is clearly the right solution.

And Bob is right, mount.gfs[2] needs to strip out _netdev and perhaps other
legitmate options that we don't want to pass to the kernel.
Comment 10 Robert Peterson 2007-05-14 10:19:00 EDT
This bug record was cloned as bug #239844 to be included in RHEL5.1.
The code change is now checked into CVS in the HEAD and RHEL5 branches.
I'm not sure if or how this can make its way into Fedora, but since 
Fedora is built from CVS, I now consider this to be a build issue and 
I'm reassigning it to Chris Feist.
Comment 11 Steve Whitehouse 2008-03-05 12:11:14 EST
This is basically a dup of another bug thats recently appeared, so I'll close
this as a dup of that new bug.


*** This bug has been marked as a duplicate of 435906 ***

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