From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Tue, 24 Aug 2010 19:53:02 +0100 Subject: [Cluster-devel] GFS2 userland - long term plans Message-ID: <1282675982.2529.87.camel@localhost> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, 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 above, Steve.