Hi, On Mon, 2009-06-08 at 11:02 +0200, Marc Grimme wrote: > Hello, > in a few bugs I read that you don't want to support the _netdev mountoption > (Dave/Steve) with gfs/gfs2. > > In order to being able to establish a relyable process to mount filesystems > depending on the network (independently from the filesystem itself) for me it > looks like a good step to at least support then _netdev mountoption with > gfs/gfs2. > > But if I specify the _netdev option with gfs it is just ignored and will not > be shown. > > Could you please shortly sum up or give me a reference where you described the > reasons for not supporting it with gfs? > > For us (using gfs/gfs2 as rootfs) it would make things much easier if the > _netdev option would be available. > > BTW: ocfs2 sets it as default. The _netdev option is only read by scripts, not by the kernel itself and its an ordering constraint. The issue is that it doesn't make the ordering correct in all cases and there are good reasons for wanting to specify other orderings too. The man page for fstab says that entries will be read in the order in which they appear. Thats not quite true of course as _netdev entries will be read later on, and they are then mounted according to fstype and the fstab ordering is only respected within a particular fstype. Ideally we want to be able to mix ordinary fs mounts, network fs mounts and bind mounts in any order. Although you can use _netdev to solve one particular case with gfs/gfs2 it certainly is not a general solution, so more thought needs to go into this. The upstart project has been suggested as a possible solution. I've not looked into it enough to be certain whether that is the case or not, nor do I know the current state of enthusiasm for it amoung the distros. I do appreciate that this has been a long standing issue and I would be very happy to see it resolved. As you are aware, we have open bugs on this issue: #435906 also related are #480002 and #207697 Steve. -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
