FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-05-2011, 08:55 AM
Steven Whitehouse
 
Default systemd and mounting filesystems

Hi,

On Wed, 2011-10-05 at 00:01 +0200, Lennart Poettering wrote:
> 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
>
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-05-2011, 09:18 AM
"Jˇhann B. Gu­mundsson"
 
Default systemd and mounting filesystems

On 10/05/2011 08:55 AM, Steven Whitehouse wrote:
> 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,

Hum...

Could that be solved either by creating mount/path units ( for the mount
point ) and or by adding to gfs_controld.service Before=local-fs.target
if it needs network support the unit section of that service file would
look something like this..

[Unit]
Requires=network.target
After=network.target
Before=local-fs.target

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-10-2011, 12:46 PM
Steven Whitehouse
 
Default systemd and mounting filesystems

Hi,

On Wed, 2011-10-05 at 09:18 +0000, "Jˇhann B. Gu­mundsson" wrote:
> On 10/05/2011 08:55 AM, Steven Whitehouse wrote:
> > 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,
>
> Hum...
>
> Could that be solved either by creating mount/path units ( for the mount
> point ) and or by adding to gfs_controld.service Before=local-fs.target
> if it needs network support the unit section of that service file would
> look something like this..
>
> [Unit]
> Requires=network.target
> After=network.target
> Before=local-fs.target
>
> JBG

Sorry for the delay... I'll have a look into this a bit later in the
week, when I'm back in front of a suitable test box. One concern is
whether that sequence of dependencies might create a circular dependency
since I assume that normally local-fs.target would be before
network.target

While we could create a mount/path unit for the mount point, that gets
us back to the previous problem of having to special case gfs2 mounts
which is what I'd like to avoid, if possible. At least if I've
understood your proposal correctly.

In the mean time I had a further thought... I wondered if it would be
possible to trigger starting gfs_controld from udev/sysfs. That would
require the following conditions to be fulfilled:

1. A maximum of one instance of gfs_controld should be started
2. While any gfs2 filesystems are mounted, gfs_controld must be running
(and we cannot allow restarts, it must be the same instance, always)
3. We would need to buffer any sysfs messages from gfs2 and ensure that
gfs_controld saw them, in order, after it was started.

The down side of this is that it would not be at all easy to deal with
dependencies (in this case cman and friends) if they had not been
started at mount time. Not to mention, that it would probably also
require modification to gfs_controld.

So that might not be a good plan, but I thought I'd mention it for
completeness,

Steve.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-10-2011, 08:58 PM
Lennart Poettering
 
Default systemd and mounting filesystems

On Wed, 05.10.11 09:18, "Jˇhann B. Gu­mundsson" (johannbg@gmail.com) wrote:

>
> On 10/05/2011 08:55 AM, Steven Whitehouse wrote:
> > 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,
>
> Hum...
>
> Could that be solved either by creating mount/path units ( for the mount
> point ) and or by adding to gfs_controld.service Before=local-fs.target
> if it needs network support the unit section of that service file would
> look something like this..
>
> [Unit]
> Requires=network.target
> After=network.target
> Before=local-fs.target

That won't really work, as network.target is generally accepted to
something that is started after basic.target (for example, because
network.target is ordered after NM which is a normal service and hence
started after basic.target). basic.target is ordered after
local-fs.target however, which basically means by specifiying the above
you'd create a dep loop "network before gfs before local-fs before basic
before NM before network".

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-10-2011, 10:03 PM
Lennart Poettering
 
Default systemd and mounting filesystems

On Wed, 05.10.11 09:55, Steven Whitehouse (swhiteho@redhat.com) wrote:

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

Hmpf, in general I believe that software really should not make
requirements like that. We should not have to delay boot just because
somebody pulled a network cable. We should as much as possible avoid
that the local machine has to sleep on some external event to happen.

My recommendation would be to teach gfs to handle the network coming and
going (by watching netlink for example), and thus not make it necessary
to have synchronization points like that. After all networks aren't
static anymore. They are plugged in, pulled out, IP address change all
the time, the admin reconfigures the machine as he pleases. Writing
software that assumes that the same network configuration is available
unconditionally when it is started all the way until it is stopped is a
bad idea in todays world.

Maybe the gfs daemon already follows netlink and knows when things are
good to use without having to be ordered after network.target?

But anyway, I am aware that not all daemons are netlink aware and we
need to support that daemons like that and making them more dynamic is
not realistic in the short term. So what we could do is introduce a new
target "network-fs-ready.target" or so which is ordered after
network.target and before all network mounts. You could then simple
place yourself between network.target and network-fs-ready.target. As
that's a simple change we could even do that in F16 still.

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

Hmm, meaning?

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-11-2011, 01:38 AM
Lennart Poettering
 
Default systemd and mounting filesystems

On Tue, 11.10.11 00:03, Lennart Poettering (mzerqung@0pointer.de) wrote:

> But anyway, I am aware that not all daemons are netlink aware and we
> need to support that daemons like that and making them more dynamic is
> not realistic in the short term. So what we could do is introduce a new
> target "network-fs-ready.target" or so which is ordered after
> network.target and before all network mounts. You could then simple
> place yourself between network.target and network-fs-ready.target. As
> that's a simple change we could even do that in F16 still.

So I have now added "remote-fs-pre.target" to achieve this. You should
now be able to order your service after "network.target" and before
"remote-fs-pre.target" so that you are run after the network is
configured but before the remote mount points are mounted.

Note that remote-fs-pre.target is a hook you need to pull in yourself,
as we do no pull it in normally (in order to keep the transaction minimal). i.e. you need to write this in your unit:

[Unit]
After=network.target
Before=remote-fs-pre.target
Wants=remote-fs-pre.target

This should appear in F16 soon.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-11-2011, 07:39 PM
Lennart Poettering
 
Default systemd and mounting filesystems

On Tue, 11.10.11 03:38, Lennart Poettering (mzerqung@0pointer.de) wrote:

> [Unit]
> After=network.target
> Before=remote-fs-pre.target
> Wants=remote-fs-pre.target
>
> This should appear in F16 soon.

This is now waiting in bodhi.

Would be cool if you could check if this works as intended for you!

Thanks,

Lennart

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

Thread Tools




All times are GMT. The time now is 08:42 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ę2007 - 2008, www.linux-archive.org