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?

systemd-devel mailing list

Reply via email to