POSIX 규정 준수

다음은 Google Cloud Managed Lustre의 POSIX 규정 준수 예외입니다.

atime 업데이트: 기본적으로 atime은 Lustre에서 사용 설정되지만 성능상의 이유로 업데이트가 지연될 수 있습니다. 즉, 파일의 액세스 시간이 모든 읽기 작업 후에 즉시 업데이트되지 않을 수 있습니다.
flock/lockf: flock(2) 및 fcntl(2)이라는 두 가지 기본 파일 잠금 API를 나타냅니다.
- flock: POSIX에 의해 정의되지 않은 BSD 스타일의 전체 파일 권고 잠금입니다. Lustre는 기본적으로 클러스터 전반에서 BSD 스타일 flock 시맨틱스를 완전히 지원합니다.
- fcntl: 바이트 범위 잠금을 지원하는 POSIX 정의 잠금 API입니다. fcntl 잠금의 Lustre 구현은 거의 POSIX를 준수하며 대부분의 애플리케이션에서 예상대로 작동합니다. 하지만 fcntl는 원래 로컬 파일 시스템용으로 설계되었기 때문에 Lustre를 비롯한 어떤 분산 파일 시스템도 POSIX의 fcntl 요구사항을 100% 충족할 수 없습니다. 예를 들어 fcntl()는 소유 프로세스가 종료될 때 잠금을 즉시 해제해야 한다고 지정하지만 클라이언트가 비정상 종료되면 Lustre 잠금 해제가 지연될 수 있습니다.

자세한 내용은 Lustre FAQ를 참고하세요.

메타데이터 이전으로 인해 inode 번호가 변경됨

Lustre 파일 시스템의 파일 inode 번호는 변경 불가능한 식별자가 아닙니다.

lfs migrate에 의해 시작된 것과 같은 메타데이터 리밸런싱 작업에는 일부 파일의 메타데이터를 한 MDT에서 다른 MDT로 이전하는 작업이 포함됩니다. 새 MDT로의 이전의 직접적인 결과로 이러한 파일에 새 inode 번호가 할당됩니다.

이 동작은 POSIX 표준을 준수하지만 파일 수명 동안 지속적인 inode 번호를 예상하도록 빌드된 많은 일반적인 Unix/Linux 애플리케이션 및 서비스의 가정을 위반할 수 있습니다. 여기에는 다음이 포함되지만 이에 국한되지는 않습니다.

NFS 및 SMB 프런트엔드: 이러한 서비스는 inode 번호에서 파일 핸들을 파생하는 경우가 많습니다. 이러한 변경으로 인해 클라이언트에서 Stale file handle 오류가 발생할 수 있습니다.
보관 및 백업 유틸리티: 기기 + 아이노드 번호로 파일을 추적하는 tar과 같은 도구는 이전된 파일을 새 파일로 취급하여 비효율적인 증분 백업을 초래할 수 있습니다.
stat()를 사용하고 st_ino를 저장하는 로그 집계기, 침입 감지 시스템, 맞춤 애플리케이션도 영향을 받을 수 있습니다.

관리자는 수동 메타데이터 리밸런싱을 시작하기 전에 이 동작과 애플리케이션에 미칠 수 있는 영향을 알고 있어야 합니다.

메타데이터 리밸런싱은 계획된 중단성 유지보수 이벤트로 취급해야 합니다.

유지보수 기간을 예약합니다. 계획된 서비스 중단을 모든 사용자 및 애플리케이션 소유자에게 알립니다. 가능하면 라이브 프로덕션 시스템에서 대규모 lfs migrate 작업을 실행하지 마세요.
필요한 경우 마이그레이션 후 파일 시스템을 마운트 해제하고 다시 마운트합니다.
일부 애플리케이션은 마이그레이션 후 플러시하거나 다시 시작해야 할 수 있습니다.