Hi, On Wed, 2011-10-05 at 00:01 +0200, Lennart Poettering wrote: > On Tue, 04.10.11 14:39, Steven Whitehouse (swhiteho@xxxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
