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
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.
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.
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.
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.
Adding Steve Whitehouse to the cc list to get his opinion on this.
Adding Dave Teigland to the cc list to get his opinion on this.
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.
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.
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.
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.
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 ***