Red Hat Bugzilla – Bug 625123
GFS2: [RFE] Remove mount.gfs2 and update gfs_controld
Last modified: 2011-01-20 08:40:46 EST
Recent GFS2 kernels have support for receiving their journal id and "first mounter" status via sysfs and they also produce uevents suitable for triggering an external program (i.e. gfs_controld) to join the cluster. This means that mount.gfs2 is no longer needed once the support for dealing with mounting directly has made it into gfs_controld. The system is totally backward compatible in that while mount.gfs2 exists, both old and new kernels and old and new gfs_controld can coexist in any combination. When mount.gfs2 is eventually removed, new kernels and new gfs_controld will be required. I've also run across a bug in remount where it is impossible to remount a gfs2 filesystem with the spectator flag set. I'm not intending to try and fix this in mount.gfs2/gfs_controld since it will be fixed by virtue of the proposed change. I've also noticed a race condition in the remount gfs_controld code which can be fixed at the same time, although this is much less important.
Created attachment 439676 [details] First go... Not tested yet, but this is roughly what I expect the final patch to look like. It is fairly small and self-contained at least. When it is eventually possible to drop mount.gfs2 and the parts of gfs_controld which communicate with it, that will save a lot more code than this patch adds.
Created attachment 440350 [details] Second go.... This now has "normal" mounting working correctly with one or two caveats. If there is a "result" due to some failure during joining the cluster, then there is currently no way to report this. We probably need to allow a negative jid written to sysfs to mean that an error occurred or something along those lines. Also, there is an issue with spectator mounts in that the kernel doesn't need a jid so doesn't currently wait for one. In the event of a problem joining the cluster, there is no way to communicate this with the kernel. Again, we might need to make all mounts wait for a jid and just send a dummy one in the spectator case. Depending upon how the dlm cluster join works, it might be possible to simply not care about spectator mounts at the gfs_controld level since they cannot be used to recover anything. The only reason we need to know is that they would have to be stopped when recovery takes place to avoid them seeing unrecovered data. It is a pity that we have to stop the whole cluster, since if we didn't then the spectator mounts could continue without interruption.
One more issue is that mounting via sysfs does't (yet) set the dev field so that withdraw won't work. That will be fixed in a future version.
Created attachment 450493 [details] Updated new mount sequence patch Still one issue left to solve... that of finding the device name to pass to dmsetup when we withdraw. This is much better though, than the previous patch.
Created attachment 451492 [details] Updates patch This solves the withdraw issue by using the device symlink which is in the gfs2 sysfs dir to find the device sysfs dir where the device number is located. Once we have that we can send that to dmsetup instead of the device name. This might not be the final version yet, but it solves the last major issue.
http://git.fedorahosted.org/git/?p=gfs2-utils.git;a=commitdiff;h=b2af295cdbfe81ce611b9a9343934f3f926fc958
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
As of the 3.1.0 release, mount.gfs2 is optional with a sufficiently new kernel, but it is still included in the package. The plan is to remove it from the rawhide package shortly, and then wait for that to percolate through the system, and remove it from the git tree once its gone from all Fedora releases.
mount.gfs2 has been removed from gfs2-utils from the following build: http://koji.fedoraproject.org/koji/buildinfo?buildID=214974 When F14 is obsolete, it can then be removed from the upstream source.