NFS 서버와 여러 클라이언트(Ubuntu 18.04)가 있습니다. 때때로 (드물게) 다른 클라이언트가 파일을 변경한 후 클라이언트가 손상된 데이터를 보게 됩니다. 서버와 다른 모든 클라이언트는 파일을 올바르게 봅니다.
컨텍스트는 간단한 일상적인 개발자 작업 흐름 상황입니다. 클라이언트 컴퓨터의 IDE(PyCharm)에서 프로그램의 Python 소스 코드를 편집한 다음 터미널 창 컴퓨터에서 다른(더 성능이 뛰어난) SSH로 실행하여 프로그램. 증상: 파일 끝에서 null 바이트를 읽거나 파일이 잘립니다(Python 코드 실행 시 구문 오류 발생).
나는 이것이 캐시의 버그로 인한 것이라고 생각합니다. 특히 영향을 받는 파일 콘텐츠는 여전히 이전 버전으로 잘못 간주되지만모든 메타데이터가 올바르게 표시됩니다.새로운 버전으로.
따라서 다른 클라이언트가 파일을 더 작게 만들면 실패한 클라이언트는 해당 파일이 이전 콘텐츠를 가지고 있는 것으로 보지만 갑자기 새 크기에서 중지됩니다. 다른 클라이언트가 이를 더 크게 만들면 결함이 있는 클라이언트는 이전 콘텐츠를 볼 수 있지만 끝에 일부 가비지(대부분 0바이트)가 추가됩니다.
캐시 일관성에 대한 NFS 매뉴얼 페이지를 읽었지만 문제는 속성 캐싱에 관한 것이 아니며 매뉴얼 페이지에서는 콘텐츠 캐싱에 대해 많이 언급하지 않습니다. 아마도 NFS가 아닌 일반 파일 시스템 캐싱 계층에서 처리하기 때문일 것입니다.
이것속성(아이노드 번호, 크기, 수정 시간)은 모두 올바르게 표시되지만 내용은 표시되지 않습니다.
이는 단지 구성 가능한 속성 캐시 시간 제한에 관한 것이 아닙니다.잘못된 파일 내용은 거기에 무기한 남아 있으며 클라이언트는 잘못된 것이 있다는 것을 결코 알아차리지 못합니다. 반복합니다. 클라이언트가 잘못된 콘텐츠(예: 허위 null 바이트 포함)로 인해 막히게 됩니다.하늘(및 그 이상) 캐시를 수동으로 삭제하지 않는 한.
이유는 무엇입니까? 해결책이 있나요? 캐시를 삭제하면 일시적으로 문제가 해결될 수 있다는 것을 알고 있지만 이는 수동 개입이므로 크기가 동일하게 유지되고 다른 클라이언트에서 몇 바이트만 변경되면 결함이 조용해질 수도 있습니다.
몇 년이 지났지만 문제는 계속되고 해결책이 없는 것 같습니다.우편 엽서GitLab이 2주간의 디버깅을 통해 캐시 오류를 발견했지만 이들 중 어느 것도 내 문제를 실제로 해결하지 못했습니다. )
웹에서 가장 관련성이 높은 정보는 다음에서 제공됩니다.이 메일링 리스트 토론은 2015년부터입니다.그러나 결국 개발자는 전혀 문제가 없다고 주장하여 혼란스럽습니다. 그렇다면 HPC 클러스터 설정에서 NFS를 어떻게 사용합니까(로그인 노드의 코드를 편집하고 실행을 위해 컴퓨팅 노드에 제출)? 소스 코드의 손상된 버전이 표시되는 컴퓨팅 노드 문제가 자주 발생합니다. 더 중요한 것은 NFS 사람들이 만들 수 있는 WONTFIX/NOBUG 문 뒤에 있는 철학에 관계없이 내 시나리오에서 실행 가능한 수정 사항은 무엇입니까?