[Cluster-devel] Re: furture plans for gfs2-utils: mount.gfs2 and the metafs

[David Teigland <teigland@redhat.com>]

On Fri, Jun 05, 2009 at 05:38:02PM +0100, Steven Whitehouse wrote:
> > I don't know what kind of mount <dir1> <dir2> is, some form of bind mount?
> > 
> Yes. Identical to what was being done with the gfs2meta filesystem type
> previously. Its only using /mnt/gfs0 to grab an inode from which to find
> out what the block device is. Doing it this way eliminates any races in
> mounting the second fs root based upon the first.

Ah, I see what you're trying to do now.  You're trying to mount the meta fs by
mounting the normal fs with a new option.  That's a relatively small special
case that shouldn't be hard to deal with.  It's just "delicate" :-) Reworking
major designs on the scale you suggest is killing a flea with sledgehammer.
Spend more time studying the details, there's sure to be a small, targeted way
of handling it.

> > > /sbin/mount.gfs2: bad read: Invalid argument on line 263 of file
> > > /builddir/build/BUILD/cluster-2.99.12/gfs2/mount/util.c
> > 
> > I can't find that line number in any code (version 2.99.12 appears to be
> > from Oct 2008!?)  But, isn't it simply complaining that you've provided
> > two dirs as input args?
> > 
> Yes, the message isn't great and we are in the process of cleaning things
> like that up. It might be that it is the case, and we can simply fix that,
> in which case it makes things easy.
> 
> The question is though, if I mount the same fs multiple times, does
> mount.gfs2 realise that its the same fs each time? If so, then I think we
> are done in that area.

Mount code (both user and kernel) obviously needs to be adapted to deal with
the special meta option, the user side has never had to before (the separate
gfs2meta type means it never touches the cluster infrastructure).  Eliminating
the mount helper and entirely reworking how mounting happens is not the way to
think about this, focus on the specific problem and make minor changes to deal
with it directly.

The mount.gfs/gfs_controld method is pretty simple: the first time a given fs
is mounted, cluster stuff happens prior to mount(2).  Subsequent mounts of the
same fs don't involve any cluster activity, and go right to mount(2).

Per http://www.mail-archive.com/cluster-devel at redhat.com/msg02568.html

we don't do any tracking of multiple mounts of the same fs or reference
counting, we leave it all to the vfs, and reverse the "cluster stuff" on the
final unmount, which the vfs tells us about via uevent.

Dave