[systemd-devel] remote-fs ordering, iSCSI and _netdev

[Andrei Borzenkov]

В Thu, 30 Oct 2014 15:15:03 -0700
Chris Leech <cleech at redhat.com> пишет:

> On Tue, Oct 28, 2014 at 06:41:32AM +0300, Andrei Borzenkov wrote:
> > В Mon, 27 Oct 2014 14:10:47 -0700
> > Chris Leech <cleech at redhat.com> пишет:
> > > 
> > > But there are two cases that are problematic, adding entries to fstab at
> > > runtime and manually mounting without adding to fstab (while still using
> > > the _netdev option, some hint is needed).  The first case actually ends
> > > up being the second, with the possible work-around of always remembering
> > > to run a daemon-reload after editing fstab to run fstab-generator again.
> > >
> > 
> > Even known network filesystems still have a problem. If network
> > filesystem is mounted on boot, it pulls in network-online.target which
> > (hopefully) serves as synchronization point on shutdown. If there is no
> > network filesystem to mount at boot, network-online.target is not
> > started. If you mount NFS manually later there is nothing to wait for
> > on shutdown so network could be teared down before filesystem is
> > unmounted.
> 
> Hmm, I hadn't noticed that with iSCSI because a service gets started to
> connect to the target so the dependencies can be taken care of there.
> 
> Should the remote mount unit be generating a Wants dependency along with
> the Before/After to ensure the synchronization point targets are active?
> Or would that not work for some reason?
> 

Wants works only when unit is started but it does not happen here - you
manually do "mount server:/path /mnt" and while unit gets created
afterwards, there is no "unit startup" phase in systemd sense so Wants
does not kick in.

May be it could be extended similar to what happens with device -
device cannot be "started" as well, but systemd fakes startup when
device appears. We could do the same for mount units newly appeared.