systemd and mounting filesystems

Steven Whitehouse swhiteho at
Tue Oct 4 14:00:05 UTC 2011


On Tue, 2011-10-04 at 14:54 +0100, Paul Howarth wrote:
> 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
Yes, apologies for the typo

> 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.

That is very much the kind of thing I'm pondering at the moment,


More information about the devel mailing list