오래된 NFS 파일 핸들 fsid가 이를 해결할 수 있는 이유는 무엇입니까?

오래된 NFS 파일 핸들 fsid가 이를 해결할 수 있는 이유는 무엇입니까?

문제 설명(이 문제는 이미 해결되었지만 이 솔루션이 작동하는 이유에 대한 질문이 있습니다.)

NFS 서버는 Ubuntu 16.04.4 LTS입니다. 클라이언트는 Ubuntu 16.04.4 LTS와 CentOS 6.10 및 7이 혼합되어 있습니다.

NFS 서버는 몇 달 동안 정상적으로 실행되었으며 특정 내보내기 중 하나가 여러 클라이언트에 백업을 제공하고 있습니다. NFS 서버 디렉토리는 다음과 같습니다:

/mnt/backups/client1
/mnt/backups/client2
/mnt/backups/client3
/mnt/backups/client4

/etc/exports에는 다음이 포함됩니다.

/mnt/backups 1.2.3.0/24(rw,sync,no_subtree_check)

클라이언트는 백업 중에만 nfs 서버를 마운트하고 백업이 완료되면 백업을 마운트 해제합니다.

이것은 잘 작동하지만 클라이언트가 /mnt/backups 디렉토리에서 서로를 볼 수 없어야 합니다. 모든 클라이언트는 동일한 백업 uid/gid를 사용합니다. 따라서 /etc/exports 파일을 사용하여 디렉토리를 분리하기로 결정했습니다.

이렇게 하려면 NFS 서버를 중지하고 다음을 포함하도록 /etc/exports를 수정합니다.

/mnt/backups/client1 1.2.3.21(rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(rw,sync,no_subtree_check)

클라이언트는 백업이 진행 중일 때만(오전 4시) NFS 서버를 마운트한다는 점을 기억하세요. 서버에서 NFS 서비스를 다시 시작하고 importfs를 사용하여 내보내기를 확인하면 괜찮아 보입니다.

좋습니다. client1을 테스트해 보세요.

mount nfserver:/mnt/backups/client1 /mnt/client1

잘 작동하지만 /mnt/client1에 대한 작업의 결과는 다음과 같습니다.

cannot open directory /mnt/client1/: Stale file handle

취해진 솔루션(이렇게 했어요아니요일하다): 서버에서 NFS를 다시 시작합니다. 클라이언트를 다시 시작하십시오. 클라이언트와 서버 모두에서 lsof |grep /mnt를 실행하여 파일을 열어 두는 프로그램이 있는지 확인하십시오. 서버/클라이언트에 대한 권한을 확인합니다. 다시 말하지만, NFS /etc/exports를 이전 파일로 다시 전환하고 클라이언트에서 nfs 서버를 마운트하면 됩니다. "새" 방법으로 다시 전환하면 작동하지 않습니다.

"NFS 다시 시작"과 같은 답을 찾기 위해 이를 갈고 매뉴얼 페이지와 STFW를 많이 갈아야 했습니다. 저는 몇 년 전에 이 문제가 있었고 어떤 이유로 fsid가 솔루션에 관여했는지 기억했습니다. 매뉴얼 페이지를 읽은 후 NFS 서버 /etc/exports 파일에 다음을 추가합니다.

/mnt/backups/client1 1.2.3.21(fsid=101,rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(fsid=102,rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(fsid=103,rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(fsid=104,rw,sync,no_subtree_check)

다시 한 번 말하지만, 이 후에 수행되는 유일한 작업은 서버에서 내보내기fs -ra를 실행하는 것입니다.

이제 모든 클라이언트는 nfs 서버 내보내기를 마운트할 수 있으며 모두 작동합니다.

이것이 왜 해결책입니까?

fsid를 사용해야 해요모든출구?

맨페이지를 읽어보세요.이것fsid가 솔루션인 이유에 대한 명확한 설명이 없는 것 같습니다. 오래된 마운트가 클라이언트 측(또는 서버 측)의 일종의 NFS 파일 핸들러일 수도 있다는 생각이 들었지만 재부팅 후에도 지속되는 것이 이상해 보입니다.

답변1

간단히 말해서, fsid는 클라이언트와 서버가 내보내기를 설치한 후 이를 식별하는 방법입니다.

매뉴얼 페이지에 명시되어 있듯이 지정하지 않으면 fsid는 기본 파일 시스템에서 파생됩니다.

4개의 내보내기에는 동일한 fsid가 있으므로 client1이 마운트된 파일을 요청하면 서버는 client4의 내보내기에 액세스하려고 한다고 생각할 수 있습니다(동일한 fsid의 최신 항목만 유지한다고 가정).

내 생각에는 이 가설을 검증하는 방법에는 여러 가지가 있습니다. 예를 들어 클라이언트 4개 중 하나만 유효한지 확인하는 것입니다. 또한 다른 3개의 내보내기가 아닌 client1 내보내기만 유지하고 client1이 제대로 작동하는지 확인하십시오.

당신은 또한 볼 수 있습니다이 답변클라이언트에서 fsid를 쿼리하는 방법의 경우 mountpoint -d4개의 클라이언트에서 사용할 수 있는 다음 명령을 사용하여 4개의 설치에 동일한 fsid가 있는지 확인할 수 있습니다.

이것이 왜 해결책입니까?

다른 fsid가 사용되기 때문에 NFS 서버에 대한 내보내기가 다르므로 클라이언트 액세스를 해당 설치에 올바르게 일치시킵니다.

모든 내보내기에 fsid를 사용해야 합니까?

예, 이는 기본 저장 장치에 대한 제어 및 변경 사항을 유지하고 내보내기가 고객에게 영향을 미치지 않도록 하는 좋은 방법이라고 생각합니다.

(저의 경우 일부 디스크가 SAN에 있고 NFS 서버가 때때로 다른 순서로 디스크를 스캔하기 때문에 이를 채택한 것으로 기억합니다. 따라서 재부팅 후 /dev/sdh가 갑자기 /dev/sdj가 됩니다. 태그 사용 마운트하면 올바른 위치에 마운트되지만 fsid가 변경되고 클라이언트가 손실됩니다. 이는 UUID가 어디에나 존재하기 전이었고 UUID는 현재 지원되는 것으로 보이며 디스크에 문제가 있을 때 확실히 더 나은 솔루션입니다. 중단하지 마십시오. 그러나 fsid를 명시적으로 지정하는 것은 나쁜 생각이 아니며 모든 권한을 유지할 수 있습니다.

답변2

Ventura 13.2를 실행하는 Mac에서 NFS를 통해 QNAP에 액세스할 때 이 문제가 발생했습니다. 결과적으로 두 장치를 다시 시작해도 사라지지 않는 오래된 NFS 핸들이 생성됩니다.

확인하려면 서버에 로그인 ssh하고 다음을 수행하세요.

exportfs -ra

다른 어떤 것도(구성 변경 없음, 재생 없음 fsid, 다른 작업 없음) 문제가 해결되지 않았습니다.

관련 정보