Bug 625123 - GFS2: [RFE] Remove mount.gfs2 and update gfs_controld
GFS2: [RFE] Remove mount.gfs2 and update gfs_controld
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gfs2-utils (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Steve Whitehouse
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: 137457
  Show dependency treegraph
 
Reported: 2010-08-18 12:26 EDT by Steve Whitehouse
Modified: 2011-01-20 08:40 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-20 08:40:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
First go... (9.40 KB, patch)
2010-08-19 09:02 EDT, Steve Whitehouse
no flags Details | Diff
Second go.... (11.33 KB, patch)
2010-08-23 06:29 EDT, Steve Whitehouse
no flags Details | Diff
Updated new mount sequence patch (11.54 KB, patch)
2010-09-29 10:37 EDT, Steve Whitehouse
no flags Details | Diff
Updates patch (12.71 KB, patch)
2010-10-04 14:08 EDT, Steve Whitehouse
no flags Details | Diff

  None (edit)
Description Steve Whitehouse 2010-08-18 12:26:12 EDT
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 09:02:01 EDT
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 06:29:15 EDT
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 06:42:03 EDT
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 10:37:56 EDT
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 14:08:25 EDT
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 7 Fedora Admin XMLRPC Client 2010-12-02 12:06:21 EST
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 12:09:45 EST
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 08:40:46 EST
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.

Note You need to log in before you can comment on or make changes to this bug.