Hi, 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 discussion.
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 thoughts. Also, are there any other changes we should be considering making in gfs2-utils? Steve.
