9.5. Glock 보유자


다음 표는 다른 glock 홀더 플래그의 의미를 보여줍니다.

표 9.5. Glock Holder 플래그
플래그이름meaning

a

async

glock 결과를 기다리지 마십시오 (나중에 결과에 대해 폴링할 수 있음)

A

Any

모든 호환 가능 잠금 모드가 허용됩니다.

c

캐시 없음

잠금 해제 시 DLM이 즉시 잠길 수 있습니다.

e

만료 없음

후속 잠금 취소 요청 무시

E

정확한

정확한 잠금 모드가 있어야 합니다.

F

첫 번째

이 잠금에 대해 부여해야 할 첫 번째 소유자 설정

H

홀더

요청된 잠금이 허용됨을 나타냅니다.

p

우선 순위

대기열 헤드에 있는 대기열 보유자

t

try

"try" 잠금

T

1CB 시도

콜백을 전송하는 "try" 잠금

W

wait

완료 요청 대기 중 설정

앞서 언급한 대로 가장 중요한 홀더 플래그는 H(소유자)와 W(wait)입니다. 이는 각각 부여된 잠금 요청 및 대기 중인 잠금 요청을 설정되었기 때문입니다. 목록에 있는 홀더의 순서가 중요합니다. 부여된 소유자가 있는 경우, 해당 소유자는 항상 큐의 헤드에 있고 그 후에는 대기 중인 소유자입니다.

지정된 홀더가 없는 경우 목록의 첫 번째 소유자는 다음 상태 변경을 트리거하는 대상이 됩니다. demote 요청은 파일 시스템의 요청보다 항상 우선 순위가 높기 때문에 항상 요청된 상태를 직접 변경할 수는 없습니다.

glock 하위 시스템은 두 가지 종류의 "try" 잠금을 지원합니다. 이는 정상적인 순서(적용 백오프 및 재시도)를 생략하는 것을 허용하고 다른 노드에서 리소스를 사용하지 않도록 하는 데 사용할 수 있기 때문에 둘 다 유용합니다. 일반적인 T (try) 잠금은 이름이 나타내는 것입니다; 특별한 작업을 수행하지 않는 "try" 잠금입니다. 반면, T (try 1CB) 잠금은 DLM이 현재 호환되지 않는 잠금 홀더에 단일 콜백을 보내는 것을 제외하고는 t 잠금과 동일합니다. T (try 1CB) 잠금의 한 가지 사용에는 iopen 잠금이 있으며, inode의 i_nlink 수가 0일 때 노드 간에 중재되는 데 사용되는 iopen 잠금이 있으며, inode를 재배치할 노드를 결정합니다. iopen glock은 일반적으로 공유 상태에 있지만 i_nlink 수가 0이 되고 →evict_inode()가 호출되면 T (try 1CB수행)가 설정된 배타적 잠금을 요청합니다. 잠금이 부여된 경우 inode 할당을 계속 해제합니다. 잠금이 부여되지 않으면 노드 (s)가 D (demote) 플래그를 사용하여 glock을 표시하는 것을 방지했습니다.이 플래그 (demote) 플래그. →drop_inode() 시간에 체크되어 거래 위치를 잊혀지지 않도록 합니다.

즉, 링크 수가 0개 있지만 열려 있는 inode는 최종 닫기()가 발생하는 노드에서 할당 해제됩니다. 또한 inode의 링크 수와 동시에 inode가 0으로 감소하고, inode는 제로 링크 수가 없는 특수 상태에 있지만 리소스 그룹 rootfs에서 여전히 사용 중인 것으로 표시됩니다. 이 함수는 ext3 파일 system3의 고립 목록과 같은 함수를 통해 비트맵의 이후 리더는 회수될 가능성이 있는 공간이 있음을 알 수 있고 회수를 시도합니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.