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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
