From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Wed, 12 Aug 2009 16:17:25 +0100 Subject: [Cluster-devel] GFS2 & sysfs Message-ID: <1250090245.3393.53.camel@localhost.localdomain> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Here are some thoughts on GFS2 and sysfs... firstly I'd like to gradually get rid of a number of entries in the GFS2 sysfs files and then possibly add some new ones. Here is a list of what I'd like to remove and why: /sys/fs/gfs2//freeze - obsolete, replaced by FSFREEZE ioctl (gfs2tool was the only user, but it has been recently updated not to use this interface and to use the ioctl instead) /sys/fs/gfs2//lock_module/id - obsolete, nothing uses this at all in recent releases of the cluster utils. Probably can be removed sooner rather than later /sys/fs/gfs2//lock_module/first_done - obsolete, recent versions of the cluster utils all get this information from the uevent subsystem /sys/fs/gfs2//lock_module/recover_done - as above /sys/fs/gfs2//lock_module/recover_status - as above We also have a number of sysfs files which are currently used to set certain filesystem parameters. I'm hoping to gradually review these and where it makes sense, introduce mount parameters to set them. This includes the quota and statfs options at a minimum. Once those have mount parameters, then I'd like to consider the sysfs interface deprecated and in due course remove them. Obviously thats a pretty long term plan at the moment, so this is just a warning that this is what I have in mind. Where at all possible, I hope to make the new parameters compatible with those of other filesystems (in name and function) although I know thats not possible in all cases. The recently added "commit=" parameter is one example of that. I've also been wondering what else would be useful to have - one idea I had is to introduce a link called "device" in the /sys/fs/gfs2/ directory which will point to the sysfs directory of the device upon which the fs is mounted. It would probably be an easier way for userland to find the device than the current "id" file (not to be confused with the lock_module/id file which I mentioned above). So I guess that the question is are there any other useful bits of information, not otherwise available, which we should expose via sysfs? Also, how long should we keep the sysfs files I mentioned above around now that the current version of the gfs2-tools doesn't use them. I think the "lock_module/id" file can probably go right away, but the others might have to wait a little longer. I'm also hoping to get around to writing a document explaining the various uevents which gfs2 generates at some stage, to help clarify how this part of the filesystem works, Steve.