I’d like to know what is the exact mechanism (implementation) used to defer mounting until after network interface is up when one uses _netdev option in /etc/fstab?
Does systemd alter this behavior?
Also, what does delay_connect option to sshfs provide what _netdev does not?
From mount man page:
_netdev
The filesystem resides on a device that requires network
access (used to prevent the system from attempting to mount
these filesystems until the network has been enabled on the
system).
From sshfs man page:
-o delay_connect
delay connection to server
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
From man systemd.mount for version 231 of systemd:
Mount units referring to local and network file systems are
distinguished by their file
system type specification. In some cases this is not sufficient (for example network block device based mounts, such as
iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount
unit a network mount.
Method 2
SysV Init
The /etc/init.d/mountall.sh init script mounts local filesystems only:
mount -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2,ceph -O no_netdev
Other filesystems are mounted by separate init scripts, like for example /etc/init.d/mountnfs.sh, which declare (via LSB headers) their dependency on $network. Thus these get scheduled later, after the network is brought up, while mountall.sh can run much earlier.
systemd
Local mount units are pulled in by local-fs.target, remote ones by remote-fs.target. systemd-fstab-generator scans /etc/fstab, generates mount units and assigns these to the above targets based on conditions similar to the above.
delay_connect
This option means that sshfs will not initiate the SSH connection to the remote server at mount time, but will only do so on the first filesystem operation actually requiring it. This delays error reporting, but might be a useful workaround in some cases, for example if your init system hasn’t got enough information to order the mount operation correctly. “The network” being “up” is a rather loose term, and even though one can add arbitrary extra dependencies to mount units that doesn’t help if the trigger event is not part of the bootup transaction (in systemd parlance).
Method 3
Upstart/Udev
For upstart and/or udev based systems this is slightly different.
It seems udev will still try to mount the NFS filesystems and netfs is a safety net for when that fails.
Please correct me if I’m wrong. either way, this answer is only relevant for some recent legacy systems (Ubuntu 14.04 LTS, RHEL6).
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0