[systemd-devel] remote-fs ordering, iSCSI and _netdev
Zbigniew Jędrzejewski-Szmek
zbyszek at in.waw.pl
Thu Oct 30 17:53:26 PDT 2014
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?
Zbyszek
More information about the systemd-devel
mailing list