systemd and mounting filesystems

[Paul Howarth]

On 10/04/2011 02:39 PM, Steven Whitehouse wrote:
> Hi,
>
> 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.
>
> 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).
>
> 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?
>
> I hope to thus resolve the long standing bug that we have open (bz
> #435096) for which the original response was "Wait for upstart" but for
> which I'm hoping that systemd can resolve the problem.

I think you mean http://bugzilla.redhat.com/435906

I ran into a similar problem last month. I foolishly set up a bind mount 
for a local filesystem, with the new mountpoint living on top of an NFS 
filesystem, and set it up in fstab to mount on boot in an F-16 VM. When 
I next rebooted, the attempted bind mount happened very early in the 
boot process (long before the network was up) and failed, resulting in a 
boot failure at an even earlier point that the usual single-user mode, 
where all the volume groups hadn't even been scanned and devices added 
in /dev, which was tricky to fix until I figured out what had happened 
and removed the bind mount entry from fstab.

Paul.