В Fri, 31 Oct 2014 01:53:26 +0100
Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> пишет:

> On Thu, Oct 30, 2014 at 03:09:25PM -0700, Chris Leech wrote:
> > On Tue, Oct 28, 2014 at 01:57:06AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Mon, Oct 27, 2014 at 02:10:47PM -0700, Chris Leech wrote:
> > > > ...
> > > > If there's no matching mount unit from fstab-generator, one gets created
> > > > dynamically when the fs is mounted by monitoring /proc/self/mountinfo.
> > > Actually, it is more correct to say that a unit *always* get created based
> > > on /proc/self/mountinfo. If there was a unit previously, it is replaced
> > > by the new one, but inherits the dependencies. In effect it leads to
> > > the behaviour you described.
> > 
> > Thanks for making that clear.
> > 
> > > > So for any mounts to remote block devices (unlike remote file system
> > > > protocols which are detected by the fs name), unless there is an fstab
> > > > entry at the time fstab-generator is run they get treated like local fs
> > > > mounts and connectivity to the storage target may be disrupted before
> > > > unmounting (possibly resulting in file system errors).
> > > Yes, that seems right. It seems reasonable to change the code which
> > > generates units based on /p/s/mounintinfo to behave as if _netdev option
> > > was specified, for the known network filesystem types.
> > 
> > That's in place and (I'm haven't been testing it but I think) working.
> > The problem is with network block devices where the fstype is the
> > on-disk filesystem.
> Sorry, I don't know too much about iscsi. Is it easy to tell that the
> device requires network to function? Some udev tag or property that could
> be easily queried?

It does not help in case of layered configuration (LVM on MD on iSCSI).
one would need to go all the way to find out if some of devices
involved may depend on network.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to