Hi, On Wed, 2011-10-05 at 09:18 +0000, "Jóhann B. Guðmundsson" wrote: > On 10/05/2011 08:55 AM, Steven Whitehouse wrote: > > Ok, excellent, so there is really just one issue to try and resolve in > > that case I think, which is the ordering of mounts vs. gfs_controld > > start, > > Hum... > > Could that be solved either by creating mount/path units ( for the mount > point ) and or by adding to gfs_controld.service Before=local-fs.target > if it needs network support the unit section of that service file would > look something like this.. > > [Unit] > Requires=network.target > After=network.target > Before=local-fs.target > > JBG Sorry for the delay... I'll have a look into this a bit later in the week, when I'm back in front of a suitable test box. One concern is whether that sequence of dependencies might create a circular dependency since I assume that normally local-fs.target would be before network.target While we could create a mount/path unit for the mount point, that gets us back to the previous problem of having to special case gfs2 mounts which is what I'd like to avoid, if possible. At least if I've understood your proposal correctly. In the mean time I had a further thought... I wondered if it would be possible to trigger starting gfs_controld from udev/sysfs. That would require the following conditions to be fulfilled: 1. A maximum of one instance of gfs_controld should be started 2. While any gfs2 filesystems are mounted, gfs_controld must be running (and we cannot allow restarts, it must be the same instance, always) 3. We would need to buffer any sysfs messages from gfs2 and ensure that gfs_controld saw them, in order, after it was started. The down side of this is that it would not be at all easy to deal with dependencies (in this case cman and friends) if they had not been started at mount time. Not to mention, that it would probably also require modification to gfs_controld. So that might not be a good plan, but I thought I'd mention it for completeness, Steve. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
