systemd and mounting filesystems
 

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.

So I'm wondering how to express these requirements in systemd correctly,

Steve.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd and mounting filesystems
 

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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd and mounting filesystems
 

Hi,

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 http://bugzilla.redhat.com/435906
>
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,

Steve.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd and mounting filesystems
 

On 04/10/11 14:54, Paul Howarth wrote:

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

I have a similar problem with some bind mounts over the root filesystem
where systemd mounts them while the rootfs is still ro and hence they
all wind up as ro until I remount them.

Tom

--
Tom Hughes (tom@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd and mounting filesystems
 

On Tue, 04.10.11 14:39, Steven Whitehouse (swhiteho@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

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

> 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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd and mounting filesystems
 

On Tue, 04.10.11 15:02, Tom Hughes (tom@compton.nu) wrote:

>
> On 04/10/11 14:54, Paul Howarth wrote:
>
> > 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.
>
> I have a similar problem with some bind mounts over the root filesystem
> where systemd mounts them while the rootfs is still ro and hence they
> all wind up as ro until I remount them.

Is there a bugzilla about this?

This is an interesting issue to think about. I wonder what the right fix
should be though: delay all bind mounts after the / remount?

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd and mounting filesystems
 

On Wed, 05.10.11 00:18, Lennart Poettering (mzerqung@0pointer.de) wrote:

> On Tue, 04.10.11 15:02, Tom Hughes (tom@compton.nu) wrote:
>
> >
> > On 04/10/11 14:54, Paul Howarth wrote:
> >
> > > 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.
> >
> > I have a similar problem with some bind mounts over the root filesystem
> > where systemd mounts them while the rootfs is still ro and hence they
> > all wind up as ro until I remount them.
>
> Is there a bugzilla about this?
>
> This is an interesting issue to think about. I wonder what the right fix
> should be though: delay all bind mounts after the / remount?

Hmm, if you change /etc/fstab and explicitly specify "rw" as option of
the bind mount, does that fix the issue?

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd and mounting filesystems
 

On 10/05/2011 12:18 AM, Lennart Poettering wrote:
> On Tue, 04.10.11 15:02, Tom Hughes (tom@compton.nu) wrote:
>> I have a similar problem with some bind mounts over the root filesystem
>> where systemd mounts them while the rootfs is still ro and hence they
>> all wind up as ro until I remount them.
>
> Is there a bugzilla about this?

Looks like https://bugzilla.redhat.com/show_bug.cgi?id=718464

Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd and mounting filesystems
 

On 05/10/11 08:51, Michal Schmidt wrote:
> On 10/05/2011 12:18 AM, Lennart Poettering wrote:
>> On Tue, 04.10.11 15:02, Tom Hughes (tom@compton.nu) wrote:
>>> I have a similar problem with some bind mounts over the root filesystem
>>> where systemd mounts them while the rootfs is still ro and hence they
>>> all wind up as ro until I remount them.
>>
>> Is there a bugzilla about this?
>
> Looks like https://bugzilla.redhat.com/show_bug.cgi?id=718464

Indeed - the stupidity that is NFSv4 is my reason for having the bind
mounts in question as well...

I was just in the middle of setting up in a test case in a VM and
raising a bug but now I guess I don't need to ;-)

Tom

--
Tom Hughes (tom@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

systemd and mounting filesystems
 

On 04/10/11 23:28, Lennart Poettering wrote:
> On Wed, 05.10.11 00:18, Lennart Poettering (mzerqung@0pointer.de) wrote:
>
>> On Tue, 04.10.11 15:02, Tom Hughes (tom@compton.nu) wrote:
>>
>>> I have a similar problem with some bind mounts over the root filesystem
>>> where systemd mounts them while the rootfs is still ro and hence they
>>> all wind up as ro until I remount them.
>>
>> Is there a bugzilla about this?
>>
>> This is an interesting issue to think about. I wonder what the right fix
>> should be though: delay all bind mounts after the / remount?

Well I guess the optimal solution is to work out which binds are over
the root filesystem and delay those, or indeed in general to delay bind
mounts until their source filesystem is mounted. That may be somewhat
hard to do though ;-)

> Hmm, if you change /etc/fstab and explicitly specify "rw" as option of
> the bind mount, does that fix the issue?

I have been, and no, it doesn't (until you do a mount -o remount on the
filesystem, at which point it is applied).

Tom

--
Tom Hughes (tom@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel