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

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,

On Fri, 2009-06-05 at 11:00 -0500, David Teigland wrote:
> On Fri, Jun 05, 2009 at 04:32:42PM +0100, Steven Whitehouse wrote:
> > Hi,
> > 
> > On Fri, 2009-06-05 at 09:54 -0500, David Teigland wrote:
> > > On Fri, Jun 05, 2009 at 11:00:17AM +0100, Steven Whitehouse wrote:
> > > > Another issue is how we mount gfs2 filesystems. I would like to try and
> > > > get rid of the mount.gfs2 helper for several reasons. Currently we are
> > > > using a different fstype (gfs2meta) to allow access to the GFS2 meta
> > > > filesystem. In reality though, we don't mount a different filesystem
> > > > type, but the same filesystem type as the "normal" filesystem, but with
> > > > a different root. We have also more recently also supported the "-o
> > > > meta" mount option to mount the meta root directly, but with some
> > > > restrictions. Bearing in mind how easy it is to lift those restrictions
> > > > (something that I've been discussing with Christoph) I'd like to raise
> > > > the possibility of replacing the mount.gfs2 helper with a system which
> > > > is very similar to that which we used to replace the umount.gfs2 helper
> > > > for similar reasons.
> > > > 
> > > > So the plan would be to enhance the mount function of GFS2 so that it is
> > > > possible to mount a GFS2 filesystem by allowing multiple mounts
> > > > (effectively a bind mount) of that block device with or without the "-o
> > > > meta" argument which is used to choose the filesystem root. The problem
> > > > of course, is the mount.gfs2 will then not know whether it is the first
> > > > mount of the fs, or a further mount of an existing fs unless its keeping
> > > > count of mounts per block device internally.
> > > 
> > > I don't follow your problem description there, could you state it more
> > > explicitly?  Give an example (sequence of commands), to demonstrate the
> > > problem (e.g. which command fails or doesn't do the right thing).
> > > 
> > I have an fstab entry like this:
> > /dev/sda7             /mnt/gfs0                   gfs2    noauto,rw,data=ordered,lockproto=lock_dlm,locktable=unity:myfs,quota=on,meta       1 2
> > 
> > and then I do:
> > [root at men-an-tol gfs2-2.6-fixes.git]# mount /mnt/gfs0
> > [root at men-an-tol gfs2-2.6-fixes.git]# mount -t gfs2 /mnt/gfs0 /mnt/gfs1
> 
> 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.

> > /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.

> > > I'm familiar with using uevents to mount, that's the way it originally
> > > worked in 2005 (gfs Groundhog Day continues):
> > > 
> > > http://git.fedorahosted.org/git/cluster.git?p=cluster.git;a=commit;h=2ec0da360f4eba591ecbf5e4dc8ed35b82f4142c
> > > 
> > Then the question arises, why was it changed?
> 
> Much cleaner and works better.  Changing it back again now would require you
> to first rewrite most of gfs_controld, and then face up to all the new
> problems that doing it differently would present.  It would be rearranging the
> deck chairs on the titanic; if you're dieing to do major work on this, just
> toss out the whole thing and design a much simpler system that doesn't require
> so much complex user/kernel interaction (see ocfs2).
> 
> Dave
> 
Well we can certainly look at what they are doing. I don't think we can
easily change the recovery at this stage, but journal id allocation
might not be so tricky. Are there any docs which describe how it works?

Steve.