9.3. glocks

GFS2를 이해하기 위한 가장 중요한 개념과 다른 파일 시스템과 별도로 설정하는 개념은 glocks 개념입니다. 소스 코드 측면에서 glock은 DLM을 결합하고 단일 상태 시스템으로 캐싱하는 데이터 구조입니다. 각 glock은 단일 DLM 잠금과 1:1 관계가 있으며 해당 잠금 상태에 대한 캐싱을 제공하므로 파일 시스템의 단일 노드에서 수행되는 반복적인 작업이 DLM을 반복적으로 호출할 필요가 없으므로 불필요한 네트워크 트래픽을 방지할 수 있습니다. 두 가지 광범위한 범주의 glock이 있습니다. 캐시 메타데이터와 그렇지 않은 항목은 무엇입니까. inode glocks 및 리소스 그룹 모두 캐시 메타데이터, 기타 유형의 glocks는 캐시 메타데이터를 캐시하지 않습니다. inode glock은 메타데이터 외에 데이터 캐싱에도 포함되어 있으며 모든 glocks의 가장 복잡한 논리가 있습니다.

glock은 잠금 해제될 때까지(다른 노드의 요청 또는 VM 요청 시) 로컬 사용자가 없을 때까지 메모리에 유지됩니다. 그 시점에서 그들은 glock 해시 테이블에서 제거되고 해제됩니다. glock이 생성되면 DLM 잠금과 즉시 glock과 연결되지 않습니다. DLM 잠금은 DLM에 대한 첫 번째 요청 시 glock과 연결되며 이 요청이 성공하면 glock에 'I'(initial) 플래그가 설정됩니다. glock debugfs 인터페이스의 "Glock flags" 테이블은 다른 glock 플래그의 의미를 보여줍니다. DLM이 glock과 연결되면 glock을 해제할 때까지 DLM 잠금은 항상 NL (ECDHE) 잠금 모드를 유지합니다. 잠금 해제로 DLM 잠금을 해제하는 것은 항상 glock의 수명 중 마지막 작업입니다.

각 glock은 그에 연결된 여러 "보유자"를 가질 수 있으며, 각각은 상위 계층에서 하나의 잠금 요청을 나타냅니다. 코드의 중요한 섹션을 보호하기 위해 GFS2 큐와 관련된 시스템 호출 및 glock 소유자와 관련된 시스템 호출.

glock 상태 시스템은 작업 큐를 기반으로 합니다. 성능상의 이유로 tasklet이 더 바람직할 수 있지만, 현재 구현에서는 I/O를 해당 컨텍스트에서 제출하여 사용을 금지해야 합니다.

다음 표는 각 glock 모드에서 캐시될 수 있는 상태와 해당 캐시된 상태가 더러워질 수 있는지 여부를 보여줍니다. 이는 리소스 그룹 잠금에 대한 데이터 구성 요소가 없지만 메타데이터만 있지만 inode 및 리소스 그룹 잠금 모두에 적용됩니다.