_netdev
옵션을 사용할 때 네트워크 인터페이스가 작동 할 때까지 마운트를 연기하는 데 사용되는 정확한 메커니즘 (구현)이 무엇인지 알고 싶습니다 /etc/fstab
. 이 동작이 변경
됩니까 systemd
?
또한 delay_connect
sshfs에 대한 옵션은 무엇을 제공 _netdev
하지 않습니까?
에서 mount
man 페이지 :
_netdev
파일 시스템은 네트워크 액세스가 필요한 장치에 상주합니다 (시스템에서 네트워크가 활성화 될 때까지 시스템이 이러한 파일 시스템을 마운트하지 못하도록하는 데 사용됨).
에서 sshfs
man 페이지 :
-o delay_connect
서버 연결 지연
답변
SysV Init
/etc/init.d/mountall.sh
init 스크립트는 로컬 파일 시스템 만 마운트 :
mount -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2,ceph -O no_netdev
다른 파일 시스템은 예를 들어 /etc/init.d/mountnfs.sh
LSB 헤더를 통해 의존성을 선언 하는 별도의 init 스크립트로 마운트됩니다 $network
. 따라서 네트워크가 시작된 후 나중에 예약 mountall.sh
될 수 있지만 훨씬 더 일찍 실행될 수 있습니다.
체계적
로컬 마운트 장치는 local-fs.target
, 원격 마운트 장치를 통해 끌어옵니다 remote-fs.target
. systemd-fstab-generator
scan /etc/fstab
은 마운트 장치를 생성하고 위와 유사한 조건에 따라 위의 대상에 할당합니다.
delay_connect
이 옵션은 마운트시 sshfs가 원격 서버에 대한 SSH 연결을 시작하지 않고 실제로 필요한 첫 번째 파일 시스템 조작에서만 수행함을 의미합니다. 이로 인해 오류보고가 지연되지만 init 시스템에 마운트 작업을 올바르게 주문하기에 충분한 정보가없는 경우와 같은 경우에 유용한 해결 방법이 될 수 있습니다. “네트워크”가 “업”인 것은 다소 느슨한 용어 이지만 트리거 이벤트가 부트 업 트랜잭션의 일부가 아닌 경우 (시스템화 된 관점 에서) 도움이되지 않는 유닛을 마운트하기 위해 임의의 추가 종속성 을 추가 할 수는 있습니다 .
답변
man systemd.mount
systemd 버전 231 부터 :
로컬 및 네트워크 파일 시스템을 참조하는 마운트 장치는 파일 시스템 유형 스펙으로 구별됩니다. 경우에 따라 이것은 충분하지 않습니다 (예 : iSCSI와 같은 네트워크 블록 장치 기반 마운트).이 경우 _netdev 가 장치의 마운트 옵션 문자열에 추가되어 시스템이 마운트 장치를 네트워크 마운트로 간주하도록 할 수 있습니다.
답변
Upstart/Udev
들어 upstart
및 / 또는 udev
기반 시스템이 약간 다릅니다.
보인다 udev
여전히 NFS 파일 시스템을 마운트 시도하고 netfs
이것이 실패 할 때를위한 안전망이다.
내가 틀렸다면 정정 해주세요. 어느 쪽이든,이 답변은 일부 최신 레거시 시스템 (Ubuntu 14.04 LTS, RHEL6)에만 해당됩니다.