2.7. 블록 할당
데이터만 작성하는 애플리케이션에서는 일반적으로 블록 할당 방법이나 위치를 상관하지 않지만 블록 할당이 작동하는 방식에 대한 일부 지식이 성능을 최적화하는 데 도움이 될 수 있습니다.
2.7.1. 파일 시스템에 여유 공간 확보
GFS2 파일 시스템이 거의 가득 차면 블록 할당자가 새 블록을 할당할 공간을 찾기 어려울 수 있습니다. 결과적으로 allocator에 의해 제공되는 블록은 리소스 그룹 끝 또는 파일 조각화 가능성이 훨씬 더 많은 작은 조각으로 소커되는 경향이 있습니다. 이 파일 조각화로 인해 성능 문제가 발생할 수 있습니다. 또한 GFS2 파일 시스템이 거의 가득 차면, 모든 할당기가 여러 리소스 그룹을 통해 검색하는 데 더 많은 시간을 소비하고, 사용 가능한 공간이 충분한 파일 시스템에서 반드시 존재하지 않는 잠금 경합을 추가하는 것을 차단합니다. 이로 인해 성능 문제가 발생할 수 있습니다.
이러한 이유로 워크로드에 따라 다를 수 있지만 85 % 이상의 파일 시스템을 실행하지 않는 것이 좋습니다.
2.7.2. 가능한 경우 각 노드가 자신의 파일을 할당하도록 합니다.
GFS2 파일 시스템과 함께 사용할 애플리케이션을 개발하는 경우 가능한 경우 각 노드가 고유 파일을 할당하는 것이 좋습니다. 분산 잠금 관리자(DLM)가 작동하는 방식 때문에 모든 파일을 한 노드에 의해 할당되고 다른 노드에서 해당 파일에 블록을 추가해야 하는 경우 더 많은 잠금 경합이 발생합니다.
"lock master"라는 용어는 현재 클러스터의 원격 노드에서 시작되는 잠금 요청의 코디네이터인 노드를 나타내는 데 사용되었습니다. 잠금 요청 코디네이터에 대한 이 용어는 잠금 요청이 대기 중, 부여 또는 감소하는 리소스와 관련하여 실제로 리소스( DLM 용어)이기 때문에 약간 잘못 표시됩니다. DLM에서 용어가 사용되는 것은 DLM이 피어 투 피어 시스템이므로 "동일한 것"을 참조해야 합니다.
Linux 커널 DLM 구현에서 잠금이 처음 사용되는 노드는 잠금 요청의 코디네이터가 되고 그 뒤에는 변경되지 않습니다. 이는 Linux 커널 DLM의 구현 세부 정보이며 일반적으로 DLM의 속성이 아닙니다. 향후 업데이트로 특정 잠금에 대한 잠금 요청이 노드 간에 이동하도록 허용할 수 있습니다.
잠금 요청이 조정되는 위치는 요청 대기 시간에 미치는 영향을 제외하고 잠금 요청의 이니시에이터에 투명합니다. 현재 구현의 결과 중 하나는 초기 워크로드의 불균형이 있는 경우(예: 다른 노드에서 I/O 명령을 수행하기 전에 전체 파일 시스템을 스캔)가 있으면 파일 시스템의 초기 검사를 수행한 노드와 비교하여 클러스터의 다른 노드의 잠금 대기 시간이 더 높을 수 있습니다.
대부분의 파일 시스템에서와 마찬가지로, GFS2 할당자는 동일한 파일에 블록을 서로 가깝게 유지하여 디스크 헤드의 이동을 줄이고 성능을 향상시키려고 합니다. 파일에 블록을 할당하는 노드는 새 블록에 대해 동일한 리소스 그룹을 사용하고 잠길 필요가 있습니다(해당 리소스 그룹의 모든 블록이 사용 중이 아닌 경우). 파일이 포함된 리소스 그룹의 잠금 요청 코디네이터가 데이터 블록을 할당하면 파일 시스템이 더 빨리 실행됩니다. 파일이 처음 열린 노드가 새 블록을 모두 작성하는 것이 더 빠릅니다).
2.7.3. 가능한 경우 사전 할당
파일이 미리 할당되면 블록 할당을 완전히 방지할 수 있으며 파일 시스템을 보다 효율적으로 실행할 수 있습니다. GFS2에는 데이터 블록을 사전 할당하는 데 사용할 수 있는 fallocate(1)
시스템 호출이 포함되어 있습니다.