[Linux-cluster] Mountoption _netdev status with gfs/gfs2

[Steven Whitehouse]

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.