[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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


A little while back Fabio suggested that we (as the gfs2 team) should
come up with a medium/long term plan for the gfs2-utils. We already have
a number of projects that we are working on, such as
internationalisation, cleaning up libgfs2 and turning it into a proper
library, removing obsolete options from gfs2_tool, and so forth. This is
an attempt to set out a vision for the future and to maybe generate some

I would like to eventually remove gfs2_tool completely, replacing it
with a command called something like tunegfs2 which would take arguments
compatible with the ext2 tune2fs where similar functions makse sense.
Its only real function would be to manipulate the on-disk superblock.
Any "tune" parameters which currently exist and are useful would be
replaced by mount arguments. There are very few of these - maybe only
one or two and I think they are all related to quotas. Some more work
remains to be done to verify that.

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.

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:

1. Less userland code to maintain (the changes to gfs_controld would be
fairly minor)
2. A clean mount interface with no restrictions as to the ordering of
"normal" and meta mounts
3. gfs2-utils would not need to depend on libgfscontrol - in fact thats
the only dependency on that library in the utils. Maybe we wouldn't need
libgfscontrol either...
4. gfs_controld would be able to talk directly to gfs2 and deal with its
uevents without needing any support from the mount helpers. That gives a
clean and simple interface to gfs_controld
5. The whole thing could stay backwards compatible too (we'd retain the
current gfs2metafs filesystem type for the time being to ensure that all
existing userland will continue to work)

It is possible to make these changes a bit at a time, provided we are
careful about the ordering. There are of course a number of details
still to be worked out, but this gives a rough outline of my current

Also, are there any other changes we should be considering making in


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]