여러 개의 어펜더가 NFS 공유의 동일한 파일에 쓰기

즉, 예, 여러 NFS 클라이언트의 동시 쓰기가 손상됩니다.

로컬 동시 추가는 파일이 추가 모드에서 열린다는 것을 운영 체제가 알고 있으며 동시에 파일을 확장할 수 있는 다른 프로세스에 관계없이 각 쓰기 호출 전에 자동으로 파일의 현재 끝을 찾기 때문에 인터리빙이 훌륭합니다.

하지만 NFS에서는 그런 행운이 없습니다. 이것리눅스 NFS FAQ구체적으로 정의됨:

A9. 여러 클라이언트에서 O_APPEND를 사용하여 파일을 열면 파일이 손상되는 이유는 무엇입니까?
답변: NFS 프로토콜은 원자성 추가 쓰기를 지원하지 않으므로 어떤 플랫폼의 NFS에서도 추가 쓰기가 원자성이 아닙니다.
대부분의 NFS 클라이언트(2.4.20보다 높은 커널의 Linux NFS 클라이언트 포함)는 "off-to-on" 캐시 일관성을 지원합니다.

A8. 오픈 캐시 일관성에 가까운 것은 무엇입니까?
A: 서로 다른 NFS 클라이언트 간에 완벽한 캐시 일관성을 달성하는 데 드는 비용은 매우 높으므로 NFS는 대부분의 일상적인 파일 공유 유형 요구 사항을 충족하는 데 약한 접근 방식을 사용합니다. [...]

애플리케이션이 파일을 닫으면 NFS 클라이언트는 다음 여는 사람이 변경 사항을 볼 수 있도록 보류 중인 변경 사항을 파일에 다시 기록합니다. 이는 또한 NFS 클라이언트에게 close()의 반환 코드를 통해 응용 프로그램에 서버 쓰기 오류를 보고할 수 있는 기회를 제공합니다. 이 동작을 거의 열린 캐시 일관성이라고 합니다.

국유림청쓰기 작업기록할 위치와 기록할 데이터만 포함됩니다. 클라이언트가 서로 덮어쓰지 않도록 하기 위해 필요한 파일 끝 위치를 중앙에서 조정하기 위한 규정은 없습니다.

(3.x에 대한 언급 없이 주로 Linux 커널 버전 2.6에 대해 논의하기 때문에 이 페이지는 약간 오래된 것처럼 보입니다. 그러나 커널 지원과 관련하여 NFS 버전 4가 언급되어 있으므로 답변이 v4에도 적용된다고 가정할 수 있습니다. .)

---

최근 Linux 및 NFS v3 공유에 대해 몇 가지 테스트를 수행했습니다.

for ((i=0 ; i<9999 ; i++)) ; do printf "$id %06d\n" $i >> testfile ; done동시에 두 클라이언트의 쉘 루프( )에 숫자를 쓰면 출력이 심각하게 손상됩니다. 부분:

barbar 001031
foo 000010
32
foo 000011
33
foo 000012

여기서 한 시스템의 첫 번째 루프는 을 사용하여 행을 쓰고 barbar, 다른 시스템의 다른 루프는 foo행을 씁니다. 줄은 barbar 001032줄과 같은 위치부터 쓰여지며 foo 000010, 긴 줄의 마지막 번호만 보인다고 해야 할까요 . (이 경우 리디렉션이 루프 내부에 있으므로 실제로 각 파일이 열리고 닫힙니다 printf. 그러나 파일이 열릴 때 끝을 찾는 데만 도움이 됩니다.)

파일이 항상 열린 상태로 유지되면 클라이언트 시스템은 파일이 닫힐 때만 서버에 변경 사항을 쓰겠다고 약속하기 때문에 더 큰 블록을 덮어쓸 수 있습니다. 파일을 여는 동안 파일을 자르더라도 파일이 지워질 뿐이고 파일이 닫힐 때 다른 클라이언트가 더 이상 쓰는 것을 막지 못하기 때문에 크게 바뀌지 않습니다.