From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Re: furture plans for gfs2-utils: mount.gfs2 and the metafs
Date: Fri, 5 Jun 2009 11:00:38 -0500 [thread overview]
Message-ID: <20090605160038.GC28143@redhat.com> (raw)
In-Reply-To: <1244215962.29604.702.camel@localhost.localdomain>
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?
> /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?
> > 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
next prev parent reply other threads:[~2009-06-05 16:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-05 10:00 [Cluster-devel] furture plans for gfs2-utils: mount.gfs2 and the metafs Steven Whitehouse
2009-06-05 14:54 ` [Cluster-devel] " David Teigland
2009-06-05 15:32 ` Steven Whitehouse
2009-06-05 16:00 ` David Teigland [this message]
2009-06-05 16:38 ` Steven Whitehouse
2009-06-05 18:46 ` David Teigland
2009-06-08 8:27 ` Steven Whitehouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090605160038.GC28143@redhat.com \
--to=teigland@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.