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.

- Chris
systemd-devel mailing list

Reply via email to