`ln`은 NFS에서 원자적이고 신뢰할 수 있습니까? 이 사용 사례에서 NFS가 GFS를 대체할 수 있습니까?

모든 노드가 동시에 액세스하는 GFS 전역 파일 시스템이 포함된 공유 디스크를 포함하는 여러 서버로 구성된 클러스터가 있습니다.

클러스터의 모든 노드는 동일한 프로그램을 실행합니다(셸 스크립트가 주요 핵심임). 시스템은 여러 입력 디렉터리에 나타나는 파일을 처리하며 다음과 같이 작동합니다.

• 프로그램은 입력 디렉터리를 반복합니다.
• 발견된 각 파일에 대해 "잠금 파일"이 있는지 확인하고, 잠금 파일이 있으면 다음 파일로 점프합니다.
• 잠금 파일을 찾을 수 없으면 잠금 파일이 생성됩니다. 잠금 파일 생성에 실패하면(레이스 실패) 다음 파일로 점프합니다.
• "우리"가 잠금을 소유한 경우 파일을 처리하고 완료되면 파일을 다른 곳으로 옮기십시오.

이 모든 것이 훌륭하게 작동하지만, 작동할 수 있는 더 저렴하고 덜 복잡한 솔루션이 있는지 궁금합니다. NFS나 SMB를 생각하고 있습니다.

저는 두 가지 이유로 GFS를 사용합니다:

1. 각 파일은 한 위치(물론 중복 기본 하드웨어)에만 저장됩니다.
2. 파일 잠금이 안정적으로 작동합니다.

다음과 같이 잠금 파일을 만듭니다.

date '+%s:'${unid} > ${currlock}.${unid}
ln ${currlock}.${unid} ${currlock}
lockrc=$?
rm -f ${currlock}.${unid}

$unid고유 세션 식별자는 어디에 $currlock있고/gfs/tmp/lock.${file_to_process}

그 아름다움은 ln바로 그것이다.원자, 동시에 같은 일을 시도하는 사람을 제외한 모든 사람은 실패할 것입니다.

그래서 내가 묻는 것은 NFS가 내 요구 사항을 충족할 것인가 하는 것입니다. lnNFS에서 작업하는 것이 GFS에서 작업하는 것만큼 안정적입니까?