systemd and mounting filesystems

[Steven Whitehouse]

Hi,

On Wed, 2011-10-05 at 00:01 +0200, Lennart Poettering wrote:
> On Tue, 04.10.11 14:39, Steven Whitehouse (swhiteho at redhat.com) wrote:
> 
> > Hi,
> 
> Heya,
> > 
> > I'm looking for some info on systemd and how filesystems are mounted in
> > Fedora. I've started looking into converting the gfs2-utils package to
> > the new init system and run into things which are not documented (so far
> > as I can tell).
> > 
> > Currently there are two init scripts in gfs2-utils, one is called gfs2
> > and the other gfs2-cluster.
> > 
> > Converting gfs2-cluster is trivial. It simply runs the gfs_controld
> > daemon on boot.
> > 
> > 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.

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.

> > Things are slightly more complicated in that gfs_controld is only a
> > requirement for gfs2 when lock_dlm is in use. For lock_nolock
> > filesystems, mounting is just like any other local filesystem. The
> > locking type can be specified either in fstab, or in the superblock
> > (with fstab taking priority).
> 
> Well, I'd probably recommend to just ask people to enable gfs_controld
> manually with "systemctl enable" if they want to make use of it. But if
> you want an automatic pulling in depending on the mount option you could
> write a generator. That's a tiny binary (or script) you place in
> /lib/systemd/system-generators/. It will be executed very very early at
> boot and could generate the necessary deps by parsing fstab and creating
> .wants symlinks in the directory the generator gets passes as
> argv[1]. This is fairly simple to do, but I am tempted to say that
> manually enabling this service is nicer in this case. Automatisms in
> some areas are good but manually enabling the service is sometimes an
> option too. There's little documentation available on generators right
> now, simply because we don't want to advertise them too widely yet, and
> prefer if people ping us if they plan to make use of it in some package.
> 
Ok, thats not a problem. The manual system you suggest is very similar
to the current system, so the doc change will not be very great.

> > Another issue which I suspect is already resolved, but I'm not quite
> > sure how it can be specified in fstab, etc, is that of mount order of
> > filesystems. In particular how to set up bind mounts such that they
> > occur either before or after a specified filesystem?
> 
> systemd should be smart enought to handle that automatically. For bind
> mounts we wait until all mount points that are prefixes of either the
> mount source or the mount destination are mounted before we apply the
> bind mounts.
> 
> Lennart
> 
> -- 
> Lennart Poettering - Red Hat, Inc.

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,

Steve.