systemd and mounting filesystems

Lennart Poettering mzerqung at 0pointer.de
Mon Oct 10 22:03:15 UTC 2011


On Wed, 05.10.11 09:55, Steven Whitehouse (swhiteho at redhat.com) wrote:

> > > The more complicated conversion is the gfs2 script. This has been used
> > > historically to mount gfs2 filesystems (rather than using the system
> > > scripts for this). I assume that under the new systemd regime it should
> > > be possible to simply tell systemd that gfs2 filesystem mounting
> > > requires gfs_controld to be running in addition to the normal filesystem
> > > requirement of having the mount point accessible, and then systemd would
> > > do the mounting itself.
> > 
> > systemd will automatically order all network mounts after
> > network.target. It recognizes network mounts either by "_netdev" in the
> > options field in fstab, or by the file system type (it has a short
> > static list of known network file systems built in, and gfs2 is actually
> > listed in it).
> > 
> > systemd automatically orders mounts by their path. i.e. /foo will always
> > be mounted before /foo/bar.
> > 
> > So, probably you should simply order gfs2-cluster before network.target
> > and that's already all you need to do:
> > 
> > [Unit]
> > Before=network.target
> > 
> Unfortunately I have:
> After=network.target
> 
> because gfs_controld requires the network to be up and working in order
> to communicate with its peers on other nodes. gfs2-cluster has some
> prerequisites which require the network (i.e. dlm via the cman
> initscript and corosync) too.

Hmpf, in general I believe that software really should not make
requirements like that. We should not have to delay boot just because
somebody pulled a network cable. We should as much as possible avoid
that the local machine has to sleep on some external event to happen. 

My recommendation would be to teach gfs to handle the network coming and
going (by watching netlink for example), and thus not make it necessary
to have synchronization points like that. After all networks aren't
static anymore. They are plugged in, pulled out, IP address change all
the time, the admin reconfigures the machine as he pleases. Writing
software that assumes that the same network configuration is available
unconditionally when it is started all the way until it is stopped is a
bad idea in todays world. 

Maybe the gfs daemon already follows netlink and knows when things are
good to use without having to be ordered after network.target?

But anyway, I am aware that not all daemons are netlink aware and we
need to support that daemons like that and making them more dynamic is
not realistic in the short term. So what we could do is introduce a new
target "network-fs-ready.target" or so which is ordered after
network.target and before all network mounts. You could then simple
place yourself between network.target and network-fs-ready.target. As
that's a simple change we could even do that in F16 still.

> Historically people have used _netdev with gfs2, but it isn't really a
> good fit since although we require the network to be up and working, we
> are not a network filesystem as such.

Hmm, meaning? 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list