주의 할 점은 NFS 서버가 종료 될 때 (마운트가 정지됨) 소프트 마운트를 수행해도 "고정"자체를 피할 수는 있지만 홈이없는 것처럼 홈 디렉토리의 문제를 해결할 수는 없습니다. 디렉토리, 사용자가 어쨌든 망했다.
NFS 서버가 복구 될 때에도 사용자가 작업을 수행하지 않으면 정지 문제가 남아 있습니다. 마운트 시스템에서 프로세스를 종료 한 후 다시 마운트해야합니다. 그 이유는 NFS 서버가 다시 시작되면 다른 서버를 할당 fsid했기 때문에 fsidNFS 서버 에서 s를 하드 코딩하여이 문제를 해결할 수 있습니다 .
#. Home Directories
/usr/users \
192.168.16.0/22(rw,sync,no_root_squash,fsid=1) \
192.168.80.0/22(rw,sync,no_root_squash,fsid=1)
#. Scratch Space
/var/ftp/scratch \
192.168.16.0/22(rw,async,no_root_squash,fsid=3) \
192.168.80.0/22(rw,async,no_root_squash,fsid=3) \
172.28.24.151(rw,async,root_squash,fsid=3)
exports(5)매뉴얼 페이지 상태 ...
fsid=num
This option forces the filesystem identification portion of the file handle
and file attributes used on the wire to be num instead of a number derived
from the major and minor number of the block device on which the filesystem
is mounted. Any 32 bit number can be used, but it must be unique amongst
all the exported filesystems.
This can be useful for NFS failover, to ensure that both servers of the
failover pair use the same NFS file handles for the shared filesystem thus
avoiding stale file handles after failover.
... 주 / 부 숫자가 변경되지 않는 한 (SAN / 다중 경로 볼륨을 내보낼 때를 제외하고는 일반적으로 변경되지 않는 한) 변경 사항이 있음을 알았습니다. 문제를 완전히 제거했습니다. 즉, NFS 서버가 다시 연결되면 연결이 신속하게 복원됩니다 /dev/sdaX. 예를 들어 이것이 왜 장치에 차이를 냈는지 여전히 알 수 없습니다 .
나는 내 주장이 대체로 일화 적이라는 것을 지적해야한다. 실제로 그것이 문제를 고친 이유는 이해가되지 않지만 문제를 고친 것은 "보이는"것으로 보인다. 아직 발견되지 않았습니다. =)