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

[Steven Whitehouse]

Hi,

On Fri, 2009-06-05 at 13:46 -0500, David Teigland wrote:
> 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.
> 
Yes, in fact we've supported that for some time, but just haven't been
very good at telling people about it. At the original merge we used to
have two fstypes, but only because it was at that time impossible to use
the "two roots" solution without extra exports/changes to core code
which were rather frowned upon. Since other fs have started using
multiple roots, its now easy and it was changed some time back so even
if you request a mount of type gfs2meta, you actually get a mount of
type gfs2, but with a different root.

Eventually we should be able to drop the second fstype and just use the
"-o meta" option instead.

> > > > /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@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
> 
Ok, then it sounds like we don't need to make any changes here at the
moment then,

Steve.