NFS를 통한 flock (2) 및 fcntl (2)

Perl 5.x 문서에 따르면 flock (..) 구현은 1부터 시작하여 사용할 수없는 경우 3을 향하여 다음 기본 호출 중 하나를 사용합니다.

1. 무리 (2)
2. fcntl (2)
3. 록프 (3)

괜찮아. 그러나 flock (2)을 NFS를 통해 사용해서는 안된다는 면책 조항을 알 수 있습니다. 이 문서에서는 -Ud_flock 플래그를 사용하여 Perl이 flock (2)를 사용하도록 제안합니다. Redhat의 flock (2) 매뉴얼 페이지에는 NFS 문제에 대한 비슷한 면책 조항이 있습니다.

내 질문은 왜!?!? flock (2)이 NFS를 통해 안전하지 않은 WHY에 대한 자세한 기사 또는 설명을 찾을 수없는 것 같습니다.

Redhat (flock (2)이 사용되는 곳)과 Solaris (fcntl (2)가 사용되는 곳) 모두에서 C와 Perl로 여러 테스트 스크립트를 작성했습니다. strace / truss를 실행하여 Perl이 각각 flock (2) 및 fcntl (2)을 사용하는지 확인했습니다. 잠금이 적용되지 않은 문제를 복제 할 수 없습니다! 무엇을 제공합니까 ??

Lennart Poettering은 최근 리눅스 파일 시스템 잠금 동작을 파고 들었습니다. 이는 NFS를 통한 잠금에 대한 특히 장미 빛 그림 (특히 포스트의 맨 아래에 연결되는 후속 조치)을 그리지 않습니다.

http://0pointer.de/blog/projects/locking.html

나는 당신이 레거시 문제를보고 있다고 확신합니다. Perl5 매뉴얼은 1994 년에 발표되었고 1991 년부터 Perl4 매뉴얼을 편집 한 것임을 상기하십시오. 당시에는 종종 악명 높은 악몽 파일 시스템에 대해 말할 수있었습니다. 놀랍지 만 춤을 춘다 "

1991 년 신기원에서 NFS2는 천천히 썬에서 다른 플랫폼으로 기어 들어 갔으며 비교적 조잡했습니다. 보안 모델은 본질적으로 존재하지 않았으며 (클라이언트 머신의 루트는 NFS 마운트의 전체 내용을 읽을 수 있음) nfs.lockd를 통한 잠금은 실험의이 측면입니다. 서로 다른 상호 운용 가능한 두 구현 사이에서 무리 의미론이 제대로 작동하기를 기대하는 것은 어리 석었을 것입니다. Coax는 인트라넷 상태를보다 잘 파악할 수있게한다면 많은 네트워크 사용자들이 사용에 대한 불만을 느끼지 못했던 당시의 주요 이더넷 PHY였습니다.

래리 월 (Larry Wall)과 승무원은 당시 NFS 잠금의 정확성에 대해 비관적 인 가정을 할 모든 이유를 가졌으며, 이는 미래의 코드 자키가 결함이 없음을 증명하기가 어렵 기 때문에 제거하기를 싫어하는 일종의 방어 적 프로그래밍입니다. 이전에 들어 본 적이없는 레거시 시스템과의 상호 운용성으로 다시 도입 된 이전 코드를 제거합니다.

그 이후로 NFS는 상당히 향상되었으며 잠금 기능은 Linux 2.6 커널의 기능으로 제 시간에 마이그레이션되었습니다. 2003+ 시스템 모음의 경우 NFS 파일 잠금을 신뢰할 수 있습니다. 특히 실행중인 많은 플랫폼에서 응용 프로그램 내에서 잘 테스트 된 경우 더욱 그렇습니다.

위의 모든 내용은 메모리에서 손상되어 연구를 통해 입증 될 수 있지만 (예 : http://nfs.sourceforge.net/ ) 증거는 잠금 상태이며 테스트하지 않은 경우 증거가 있습니다. 깨진 것으로 추정됩니다.

또 다른 하나는 Linux-NFS FAQ에서 직접 : nfs.sf.net

flock () / BSD 잠금을 사용하여 여러 클라이언트에서 사용되는 파일을 잠그려고하는데 파일이 손상되었습니다. 어떻게 오세요? A. flock () / BSD 잠금은 2.6.12 이전의 Linux NFS 클라이언트에서만 로컬로 작동합니다. fcntl () / POSIX 잠금을 사용하여 파일 잠금이 다른 클라이언트에 표시되도록하십시오.

NFS 파일에 대한 액세스를 직렬화하는 몇 가지 방법이 있습니다.

fcntl () / POSIX 잠금 API를 사용하십시오. 이 유형의 잠금은 NLM 프로토콜 또는 NFSv4를 통해 여러 클라이언트에서 바이트 범위 잠금을 제공합니다. 별도의 잠금 파일을 사용하고 하드 링크를 작성하십시오. creat (2) 매뉴얼 페이지의 O_EXCL 섹션에있는 설명을 참조하십시오. 2.6 커널 초기까지 O_EXCL 생성은 Linux NFS 클라이언트에서 원자 적이 지 않았다는 점에 주목할 가치가 있습니다. 2.6.5보다 최신 커널을 실행하지 않는 한 O_EXCL을 사용하지 말고 여러 NFS 클라이언트간에 원자 동작을 예상하십시오.

Perl이 기본적으로 flock () / BSD 잠금을 사용하는 것은 알려진 문제입니다. 이로 인해 Solaris와 같은 다른 운영 체제에서 포팅 된 프로그램이 POSIX 잠금처럼 작동 할 것으로 예상되는 프로그램이 중단 될 수 있습니다.

Linux에서 하드 링크 대신 파일 잠금을 사용하면 서버와 클라이언트의 캐시를 검사 점으로 지정할 수 있다는 이점이 있습니다. 파일 잠금이 확보되면 클라이언트는 해당 파일에 대한 페이지 캐시를 플러시하므로 이후의 모든 읽기가 서버에서 새 데이터를 가져옵니다. 파일 잠금이 해제되면 잠금을 해제하기 전에 해당 클라이언트의 파일에 대한 모든 변경 사항이 서버로 다시 플러시되므로 해당 파일을 잠금을 대기중인 다른 클라이언트가 변경 사항을 볼 수 있습니다.

2.6.12의 NFS 클라이언트는 POSIX 바이트 범위 잠금 측면에서 BSD 스타일 잠금을 에뮬레이트하여 NFS 파일에서 flock () / BSD 잠금을 지원합니다. 동일한 에뮬레이션 메커니즘을 사용하거나 fcntl () / POSIX 잠금을 사용하는 다른 NFS 클라이언트는 Linux NFS 클라이언트와 동일한 잠금을 보게됩니다.

로컬 Linux 파일 시스템에서 POSIX 잠금과 BSD 잠금은 서로 보이지 않습니다. 따라서이 에뮬레이션으로 인해 Linux NFS 서버에서 실행되는 응용 프로그램은 클라이언트의 응용 프로그램이 BSD 스타일을 사용하든 POSIX- 스타일 잠금. 서버 응용 프로그램이 flock () BSD 잠금을 사용하는 경우 NFS 클라이언트가 사용하는 잠금을 볼 수 없습니다.

지금은 구식입니다. NFS4는 프로토콜 내부의 잠금을 지원합니다 (잠금 된 데몬 또는 RPC 콜백 메커니즘이 필요하지 않음). Perl의 flock()방법은 제대로 작동합니다. 프로덕션에서 사용하고 있습니다.

아주 오래된 커널 버전 flock(syscall)은 NFS에서 no-op로 구현 되었으며 바이트 범위 잠금과 같은 다른 기능은 제대로 지원되지 않았습니다. 히스테리가 나오는 곳입니다.