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 09:54:15 -0500 [thread overview]
Message-ID: <20090605145415.GA28143@redhat.com> (raw)
In-Reply-To: <1244196017.29604.688.camel@localhost.localdomain>
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).
> The solution would be to use the uevent mechanism (probably the DLM's
> uevents, but it could be done via the GFS2 ones too I think) to trigger
> the loading of the DLM's config, setting of the journal id and whatever
> else needs to be done, in a similar way that we use GFS2's umount uevent
> to trigger leaving the cpg. It would have a number of advantages:
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
Dave
next prev parent reply other threads:[~2009-06-05 14:54 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 ` David Teigland [this message]
2009-06-05 15:32 ` [Cluster-devel] " Steven Whitehouse
2009-06-05 16:00 ` David Teigland
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=20090605145415.GA28143@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.