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

[Cluster-devel] GFS2 userland - long term plans


I've been thinking about what the future GFS2 userland tools should look
like from time to time, so I thought it was about time that I outlined
my plans.....

The basic idea is that were generic tools exist, we should use those in
preference to having a GFS2 specific tool to do the job. In some cases
that might even mean working on a suitable generic kernel API in order
to allow such a tool to be created, but mostly it just means adopting
the existing tools, possibly with some minor modifications.

So this is the direction which I'd like to move in:

 - mount.gfs2 will hopefully eventually disappear entirely. We are
already using uevents for part of the mount process and all of the
umount process. Sysfs & uevents are also used in the current recovery
process. All mount.gfs2 does is communicate to gfs_controld when the fs
is first mounted, and that can easily be replaced with a combination of
sysfs and uevents.

 - gfs2_tool will be replaced by:
   - The mount command line (for all tunable parameters)
   - The new tunegfs2 tool (for setting super block options)
   - The tracing infrastructure (which is much more useful than the old
"counters" which were removed some time ago from GFS2)

 - gfs2_quota will be replaced by:
  - The generic quota tools (which can already do some of the job of
gfs2_quota, but not all of it yet)

 - The new tunegfs2 tool is designed to be "argument compatible" with
tune2fs as far as possible and also it will work on _both_ GFS and GFS2.

The other userland tools will be retained and improved. I'm keen to have
tools which can also work on GFS1 as well as GFS2 where possible, since
there is a lot of common ground between them.

The other plans include working to generate translatable strings from
the userland tools. There is already some infrastructure to allow this
in some of the tools. I think tunegfs2 is already at a state where it
would make sense to consider translating its (very few) strings.

I'd like to avoid having any strings which might need translating in
libgfs2. The plan is to keep the UI strictly confined to each tool.

Pretty much all of the above has been discussed and/or the subject of
bugzillas etc., and in some cases for a considerable period of time. I
thought it might be useful though to try and set all down in one place
to give an overview of where things are going. There are no promises on
the timing of the above.... it might take a long time before all the
items on the list are ticked off.

Please let us know if you have any comments/suggestions/questions on the


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