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

[Cluster-devel] GFS2 & sysfs



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/<fsname>/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/<fsname>/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/<fsname>/lock_module/first_done - obsolete, recent versions
of the cluster utils all get this information from the uevent subsystem
/sys/fs/gfs2/<fsname>/lock_module/recover_done - as above
/sys/fs/gfs2/<fsname>/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/<fsname>
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.



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