Bug 625123

Summary: GFS2: [RFE] Remove mount.gfs2 and update gfs_controld
Product: [Fedora] Fedora Reporter: Steve Whitehouse <swhiteho>
Component: gfs2-utilsAssignee: Steve Whitehouse <swhiteho>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: adas, agk, bmarzins, extras-orphan, fdinitto, rpeterso, swhiteho
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-20 13:40:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 137457    
Attachments:
Description Flags
First go...
none
Second go....
none
Updated new mount sequence patch
none
Updates patch none

Description Steve Whitehouse 2010-08-18 16:26:12 UTC 
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.
Comment 1 Steve Whitehouse 2010-08-19 13:02:01 UTC 
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.
Comment 2 Steve Whitehouse 2010-08-23 10:29:15 UTC 
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.
Comment 3 Steve Whitehouse 2010-08-23 10:42:03 UTC 
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.
Comment 4 Steve Whitehouse 2010-09-29 14:37:56 UTC 
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.
Comment 5 Steve Whitehouse 2010-10-04 18:08:25 UTC 
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.
Comment 6 Steve Whitehouse 2010-10-11 15:06:22 UTC 
http://git.fedorahosted.org/git/?p=gfs2-utils.git;a=commitdiff;h=b2af295cdbfe81ce611b9a9343934f3f926fc958
Comment 7 Fedora Admin XMLRPC Client 2010-12-02 17:06:21 UTC 
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Steve Whitehouse 2010-12-13 17:09:45 UTC 
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.
Comment 9 Steve Whitehouse 2011-01-20 13:40:46 UTC 
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.