systemd and mounting filesystems

Steven Whitehouse swhiteho at redhat.com
Mon Oct 10 12:46:04 UTC 2011


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.




More information about the devel mailing list