KR100292643B1 - 바이트 범위 api 로킹(byte rangeati locking)을 갖춘병렬 파일 시스템 및 방법 - Google Patents

Abstract

각각이 자체의 운영 체계 인스턴스(Instance)예를 갖추고 네트워크에 부착된 공유 디스크에 상주하는 파일에 병렬 데이터 공유 억세스(parallel data sharing access)하도록 연결된 다수의 컴퓨터에서 실행되는 공유 디스크 파일 시스템(shared disk file system)을 갖는 컴퓨터 시스템에서, 안정된 커서(cursor)를 갖는 시스템에 대해 측정가능한(scalable) 디렉토리(directory) 서비스, 즉 분할된 할당 맵(segmented allocation map)을 사용함으로써 공유 디스크 환경에서의 병렬 파일 시스템으로서 사용하기 위한 방법이 제공된다. 다수의 억세스에 대한 동적 프리페치(dynamic prefetch)와 캐시된 균형 풀(cached balance pool)은 시스템을 개선시킨다. 확장 파일 속성을 이용하여 병렬 파일 시스템에서의 억세스 제어 리스트(Access Control List)를 구현한다. 캐싱(caching)의 개선과 캐시(cache) 성능 개발은 다중 억세스를 위한 풀(pool)의 균형을 맞춘다. 메타데이터 노드(metadata node)는 병렬 판독 및 기록 작용을 위해 파일 메타데이터를 관리한다. 본 발명의 시스템에서, 토큰(token)은 메타데이터 노드 선택 및 식별하고 본 발명은 파일 크기를 제어할뿐만 아니라, 파일 억세스 패턴및 바이트 범위 토큰 인터페이스를 사용한 바이트 범위 로크(lock) 알고리즘을 사용하여 바이트 범위 토큰을 스마트 캐싱(smart caching)하기 위해 토큰 모드를 개선하였다. 로킹(locking) 기술은 공유 디스크의 관리에 참여하는 컴퓨터가 이용가능하지 않거나 고장날때 파일 시스템 회복에서 또한 사용되는 토큰 관리자의 오버헤드(overhead)를 줄인다. 메타데이터 노드의 동기화 및 비동기화 전환은 수정되었던 메타데이터의 정정과 그 파일에 대한 메타데이타 노드가될 새로운 노드를 위해 발생한다. 로크(lock)는 사용자 대신에 새로운 블록을 할당하기 위해 항상 요구되지는 않는다. 본 발명은 할당량 관리(quota management)를 위해 회복가능한 국부적인 몫을 제공한다. 각 파일 시스템에는 할당량 서버(quota server)와 할당량 클라이언트(quota client)이 제공되고, 할당량 점검 유틸리티(quotacheck utility)는 할당량의 사용을 요구하는 다른 애플리케이션(application)에 최소의 간섭을 갖는 병렬 환경을 허용한다.

Description

바이트 범위 ＡＰＩ 로킹(ｂｙｔｅ ｒａｎｇｅ ＡＴＩ ｌｏｃｋｉｎｇ)을 갖춘 병렬 파일 시스템 및 방법

본 발명은 컴퓨터 및 컴퓨터 시스템에 관한 것으로, 특히 각각이 자체의 운영 체계예를 갖추고 네트워크에 부착된 공유 디스크와 데이터를 공유하도록 연결된 다수의 컴퓨터에서 실행되는 파일 시스템, 즉 공유 디스크 파일 시스템(shared disk file system)에 관한 것이다.

〈용어 해설〉

여기서 사용되는 특정한 용어는 사전의 의미도 포함하지만, 다음에 주어지는 본 발명에 관련된 일부 용어의 해설은 유용한 것으로 입증된다:

- 데이터/파일 시스템 데이터 : 특정한 애플리케이션(application)과의 관계에서만 의미를 갖는 임의의 비트열.

- 파일 : 컴퓨터 애플리케이션에 의해 억세스(access)될 수 있는 지명된 비트열. 파일은 길이, 수정 시간, 및 최종 억세스 시간과 같은 특정한 표준 특성을 갖는다.

- 메타데이터(metadata) : 파일의 구조와 파일 시스템을 포함하는 디스크의 사용을 설명하도록 파일 시스템 소프트웨어에 의해 생성된 제어 구조. 이 종류의 파일 시스템에 적용되는 메타데이터의 종류로는 다음과 같은 것이 있다:

- 디렉토리(directory) : 이노드(inode)로 나타내지는 데이터 세트와 하나의 명칭을 연관시키는 제어 구조.

- 이노드는 파일의 특성 및 이 파일을 구성하는 데이터를 포함한 디스크 영역에 대한 일련의 포인터(pointer)를 포함한다. 이노드는 파일이 큰 경우 부가적인 포인터로 이노드를 보충하는 간접 블록에 의해 보충될 수 있다.

- 할당 맵(allocation map) : 디스크의 특정 영역(또는 이노드와 같은 다른 제어 구조)이 사용중인가 또는 이용가능한가 여부를 나타내는 제어 구조. 이는 소프트웨어가 새로운 파일에 이용가능한 블록 및 이노드를 효과적으로 지정하는 것을 허용한다.

- 로그(log) : 실패한 경우, 다른 종류의 메타데이터를 동기화 상태로 유지시키는데 사용되는 기록 세트. 이는 다중 구조에 관련된 갱신(update)를 설명하는 단일 레코드을 포함한다.

- 파일 시스템 : 파일 데이터에 관련된 Xopen 및 POSIX 표준 세트에 의해 규정된 방법으로 데이터에 억세스를 제공하는 소정의 디스크 세트를 관리하는 소프트웨어 구성요소. 이 용어는 또한 특정한 디스크 세트내에 포함되는 메타데이터 및 데이터의 세트를 설명하는데 사용된다.

- 공유 디스크 파일 시스템(shared disk file system) : 단일 엔티티(entity)에 전체 관리를 지정하지 않고 파일 시스템의 관리에서 다수의 컴퓨터가 공유하는 파일 시스템. 모든 컴퓨터는 데이터를 관리하는데 요구되는 역할을 실행할 수 있다는 점에서 동료(peer)로 인식된다. 필요한 경우에는 특정한 역할이 특정한 컴퓨터에 지정될 수 있다.

- 공유 디스크 부착 : 이는 디스크가 각 파일 시스템에 국부적으로 부착되도록 나타나게 하는 프로토콜(protocol)로 다수의 컴퓨터에 디스크를 부착시키는 방법이다. 이 작업에서는 각 컴퓨터에 대한 정확한 부착 프로토콜이 중요하지 않지만, 다양한 형태의 네트워크 부착 디스크, 교환식 디스크 부착, 또는 저장 후 진행(store and forword) 부착을 포함한다. 주요 항목은 파일 시스템에 국부적인 것으로 나타나고 파일 시스템의 모든 인스턴스에 똑같게 나타난다는 점이다.

- 할당량(quota) : 이는 파일 시스템내에서 파일 시스템이 특정한 사용자 또는 지명된 사용자 그룹의 사용을 제한시키는 기능이다. 예를 들면, 관리자가 파일 시스템내에서 사용자 "존(john)"을 100 메가바이트(megabyte)의 데이터로 제한시킬 수 있다. 할당량은 Unix(S.C.O.의 TM) 환경에서 사용되는 함수명이다.

- 억세스 제어 리스트(access control list) : 이는 한 사용자가 특정한 리스트에 이름이 기록된 사용자에 대해 데이터로의 억세스를 제한시킬 수 있는 파일 시스템 기술이다.

MPP 기계 및 일반적인 계산 자원으로서의 역할을 하는 부착 컴퓨터의 네트워크 중 일부를 형성하는 그밖에 컴퓨터 클러스터(cluster)와 같은 컴퓨터에는 파일 서비스를 공급할 필요가 있다.

작업을 실행하는 컴퓨터에 데이터가 국부적인 것과 같이 다양한 컴퓨터에서 실행되는 계산 작업이 같은 파일 데이터에 억세스를 요구하는 경우에는 이제 공유 디스크 파일 시스템에 대해 파일 데이터에 관련된 특정한 "오픈(open)(예를 들면, Xopen 및 POSIX) 표준이 갖추어진다 (다른 시스템에서 IBM에 의해 개발된 시스템을 실행시키기 위해, 예를 들면, 미국 특허 제4,274,139호, 제5,202,971호, 및 제5,226,159호를 참고). 다수의 컴퓨터가 네트워크의 일부이고, 다수의 디스크가 네트워크의 일부일 때는 표준과 호환가능하고 MMP나 클러스터이든간에 컴퓨터에서 실행되는 운영 체계예에서 변화가 요구되지 않는 공유 디스크 파일 시스템을 생성할 필요가 있다.

공유 파일 시스템(SFS)(미국 특허 제5,043,876호)은 가상 기계(virtual machine)간에 데이터를 공유하기 위해 IBM의 VM 하에서 작동되는 IBM의 S/390 시스템에 적용되는 용어이다. 공유 파일 시스템은 또한 단일-시스템 환경에서 개발된, IBM의 IMS 및 GRS와 같이, 데이터 공유 운송기(data sharing vehicle)라고도 알려져 있으며, MVS하에서는 GRS가 디스크 저장를 공유하는 일군의 시스템에서 사용되고, 이러한 시스템에서의 GRS는 데이터 세트로의 억세스를 일렬화시키기 위해 공유 디스크상에 작은 로크 파일(lock files)을 할당시킬 수 있다. MVS는 디스크상의 내용 테이블이나 카탈로그에 대한 억세스를 일렬화시켜야 하므로, 실행되는 운영 시스템에 대해서는 어떠한 역동작이라도 필요하다. 이는 상당한 양의 시스템 오버헤드(overhead)를 발생시킨다.

IBM의 DB2는 미국 특허 제5,463,736호에서 개요가 설명된 바와 같이 결합 장비가 메시지 경로 메커니즘(message path mechanism)을 이용해 프로세서간의 연결을 관리하여 매우 효율적이고 측정가능한 데이터 공유 기능을 전하기 위해 필요하기 때문에, 시스템/390 병렬 시스플렉스(parallel sysplex) 환경을 요구하는 다중시스템 데이터 공유를 생성하도록 IBM의 결합 장비를 사용함으로써 MVS(multiple virtual Storage)/ESA(enterprise Systems Architectures) 환경에서 데이터 공유에 적용되어, 기본적으로 공유된 데이터에 대해 초단일 서버(server)가 된다.

오디오/비디오 파일 시스템(AIX를 위한 IBM의 영상충전기 서버(VideoCharger Server))에 대한 최상의 종류인 것으로 나타낼 때, 표준 컴플라이언스(compliance)를 허용하는 컴퓨터 시스템을 처리하는 이전 해결법은 데이터를 얻어 이를 복귀시키는 단일 서버에 대한 적하(shipping) 파일 시스템 레벨 요구 또는 클라이언트로부터 원래 컴퓨터가 직접 데이터를 인출하도록 허용하는 단일 서버에 대한 클라이언트로부터의 적하 메타데이터 요구에 의존한다. IBM은 또한 가상 공유 디스크(virtual shared disk, VSD)를 제공하여 SP2 사용자가 1차 및 2차 IBM VSD 서버 노드로서 노드를 구성하도록 허용한다. VSD 소프트웨어는 운영 체계의 독립적인 이미지를 실행하는 다수의 노드가 노드 중 하나에만 물리적으로 부착된 디스크 장치를 모든 노드에 부착된 것처럼 억세스하도록 허용하므로, IBM은 AIX 운영 체계에서 가상 공유 디스크 집합을 위한 1차 서버 노드가 잘못될 때 2차 서버 노드로 투명성있게 전환되도록 실행한다. 미국 특허 제5,454,108호의 로크 관리자(lock manager), 미국 특허 제5,490,270호 및 제5,566,297호의 클러스터 구조에 의해 설명된 바와 같이, IBM의 비디오충전기와 같은 단일 서버 시스템으로 상당한 진전이 이루어졌더라도, 두 경우 모두에서 단일 서버가 존재하는 곳은 병목 및 잠재적인 부족 지점이 된다. 또한, IBM (International Business Machine) 시스템에서와 같이, 소정의 컴퓨터가 공유 디스크 중 특정 영역을 관리 및 억세스하고 다른 컴퓨터에 지정된 영역을 사용하지 않도록 네트워크를 통해 억세스되는 디스크를 분할하는 기능이 존재한다.

그러나, 과거에 이들 시스템은, 본 발명에서 개발하여 본 발명의 공유 디스크 파일 시스템의 내용에서 설명될 바와 같이, 임의의 컴퓨터, 특히 표준이나 운영 체계에서 변화를 요구하지 않는 컴퓨터가 임의의 시간에 임의의 데이터를 억세스하는 것을 허용하도록 다수의 디스크에 네크워크 억세스를 갖는 다수의 컴퓨터를 허용하는 만족스러운 해결법을 제공하지 않았다. 그럼에도 불구하고, 본 발명은 수정된 로크 관리자를 본 발명의 공유 디스크 파일 시스템에서 진보된 토큰(token) 관리자로 사용할 수 있으므로, 미국 특허 5,454,108의 발명자에 의해 행해진 작업을 인식하여야 한다.

도 1은 컴퓨터 시스템의 노드에 대한 토큰 관리자(token manager)를 포함하는 본 발명에 따른 공유 파일(shared file) 디스크 시스템을 설명하는 도면.

〈도면의 주요 부분에 대한 부호의 설명〉

1, 2, 3 : 노드

11 : 토큰 관리자

본 발명은 각 기계상의 파일 시스템예가 파일 시스템에서 일부를 형성하며 그에 연결된 모든 디스크에 동일한 억세스를 갖는 공유 디스크 파일 시스템을 제공한다. 이는 게이트웨어 프로세서(gateway processor), 교환 네트워크, TCP/IP를 지지하는 고속 인트라넷(intranet) 연결, 비균일 메모리 억세스 버스 연결, 또는 다른 유사한 연결을 사용해 이루어질 수 있다. 본 발명에 따라, 공유 디스크 파일 시스템은 연관된 관리 호출을 이용해 디스크 판독 및 기록 호출을 지원한다. 오퍼레이팅 인스턴스는 공통적으로 이용가능하거나 표준적인 것으로, 본 발명의 공유 디스크 파일 시스템을 사용하기 위해 수정될 필요가 없다. 본 발명은 본 발명의 공유 디스크 파일 시스템이 유용한 형태로 작동될 수 있도록 하는데 필요한 새로운 서비스를 제공한다.

본 발명의 공유 파일 시스템은 디스크가 공유되는 환경에서 병렬 파일 시스템으로 동작한다. 본 발명은 안정된 커서(cursor)로 시스템에 대해 측정가능한 디렉토리 서비스(scalable directory service)를 제공한다. 분할된 할당 맵(segmented allocation map)이 제공된다. 본 발명의 측정가능한 병렬 파일 시스템에 대해, 동적 프리페치(dynamic prefetch)를 실현한다. 본 발명의 측정가능한 병렬 파일 시스템에서의 속도는 캐시(cache) 성능와 공간 활용을 개선시킴으로서 개선된다. 부가하여, 확장 파일 특성은 Unix 세계에서 ACL로 공지된, 억세스 제어 리스트를 지원하며, 이는 공유 디스크 환경에서 측정가능한 병렬 파일 시스템에서 처음으로 실시가능하다.

본 발명이 이룬 개선은 다수의 컴퓨터가 디스크 및 파일 환경을 공유하도록 공유 디스크 환경에서 효과적인 기본 파일 제어를 달성한 것이다. 디렉토리 서비스 청구항은 데이터 구조에 대한 큰 방해 없이 데이터 구조에 파일을 효과적으로 삽입 및 삭제하는 것을 제공한다. 이는 수정된 영역에 대해 배타적인 제어가 주어져야 하는 병렬 시스템에서 중요하다.

할당 맵을 개발함으로써 메타데이터의 전체 일관성을 유지시키면서 같은 풀(pool)의 디스크로부터의 저장을 병렬로 할당할 수 있게 된다.이는 파일 시스템에 억세스하는 각 컴퓨터가 다른 컴퓨터에서 진행중인 것에 관계없이 부가적인 데이터를 생성하기 원하기 때문에 중요하다. 본 발명의 프리페치 알고리즘은 데이터가 프리페치될 데이터량을 결정하는데 필요한 어플리케이션과 이용가능한 I/O 대역폭을 계산한다. 이러한 계산은 I/O에 대한 요구가 이용가능한 대역폭을 넘을 수 있는 병렬 시스템에서 중요하다. 본발명은 캐시 성능을 향상시킴으로써 다중 억세스 풀의 균형을 맞출수 있고, 병렬 처리에 관련되지 않는 경우, 이것은 일반적인 파일 시스템 개선이 된다. 지원 메커니즘로서 파일 속성을 사용하는 것은 또한 비병렬 파일 시스템에도 적용될 수 있지만, 본 발명의 전체적인 병렬 파일 시스템 메커니즘내에서, 이는 병렬 파일 시스템내의 억세스 제어 리스트의 효과적인 실행을 허용하기 때문에 매우 중요하다.

공유 디스크 환경에서 같은 파일이나 디렉토리상의 병렬 갱신을 허용하는 것이 제공된다. 본 발명은 병렬 판독 및 기록 작용을 위해 파일 메타데이터를 관리하는 메타데이터 노드를 제공한다. 본 발명의 시스템에서, 토큰(token)은 메타데이터 노드의 선택 및 식별을 위해 사용되고, 본 발명은 파일 억세스 패턴과, 범위 토큰 인터페이스를 사용하는 바이트 범위 고정 알고리즘을 이용하여 파일 크기뿐만 아니라 파일 억세스 패턴과, 범위 토큰 인터페이스를 사용하는 바이트 범위 고정 알고리즘을 이용하여 파일 크기 뿐만 아니라 바이트 범위 토큰의 스마트 캐싱을 제어하기 위해 토큰모드를 개선하였다.

요구되는 병렬 파일 갱신은 다수의 컴퓨터로부터 같은 파일을 업데이터하는 동안 메타데이터를 효과적으로 생성하고 갱신하는 방법에 대한 문제점을 다루도록 제시된다. 본 발명의 해결법 중 하나는 다수의 원래 컴퓨터 애플리케이션으로부터 임의의 변화가능한 특정 메타데이터를 일관성있게 병합하는 것을 처리하는 메타데이터 노드를 생성하는 것이다. 두 번째 해결법은 컴퓨터 서비스를 요구하는 모두에 컴퓨터를 효과적으로 식별하는 로킹 기법(locking scheme)를 제공한다. 이렇게 함으로써 병목 지점이 될 수 있는 고정된 관리 지점을 생성할 필요가 없어진다.

파일 크기는 병렬 갱신 상황에서 자주 변하는 메타데이터의 일종이다. 본 발명은 실행되는 애플리케이션이 파일 크기를 요구할 때 정확한 파일 크기를 "정시"에 구하는 방법을 제공한다. 부가하여, 본 발명은 이 환경에서 토큰 관리자의 오버헤드(overhead)를 줄이는 로킹 기술을 재정의한다.

본 발명은 시스템 장애를 포함하여 많은 이유로 발생될 수 있는 바와 같이, 공유 디스크의 관리에 참가한 컴퓨터가 이용가능하지 않게 되는 경우에 파일 시스템 회복을 제공한다. 본 발명은 메타데이터 노드의 동기화 및 비동기화 전환과 병렬 파일 시스템 회복 모델을 제공한다.

본 발명의 병렬 공유 디스크 시스템은 수정을 위해 특정한 컴퓨터에 특정한 자원의 제어를 임시로 지정하는 것을 가능하게 한다. 이 경우, 다른 컴퓨터에 시각적으로 표시된 디스크상의 구조는 일관되지 않은 상태에 있을 수 있어, 실패된 경우 정정되어야 한다. 이를 처리하기 위해, 본 발명은 표준적인 로깅(logging) 및 로크(lock) 회복을 확장하여, 다른 컴퓨터가 파일 시스템에서 대부분의 데이터를 계속 억세스하는 동안 이 회복이 일어날 수 있도록 하는 방법을 제공한다. 본 발명은 또한 메타데이터 노드의 실패를 처리하는 것을 제공한다. 이러한 개발에는, 이후 설명될 바와 같이, 수정하에 있었던 메타데이터의 정정과 새로운 컴퓨터가 그 파일에 대한 메타데이터 노드로 되는 것을 포함한다.

Unix 세계에서 할당량(quota)은 그 이름으로 공지되어 있다. 이것은 공간의 초기 넓이를 관리하는데 사용될 수 있는 개념이고, 이 개념은 S/390 시스템과 같은 다른 운영 체계와 사용된다. 일반적으로, 할당량을 고려할 때, 이는 적극적으로 관리될 필요가 있으므로, 사용자를 위해 새로운 블록을 할당하기 위해 로크가 항상 요구되는 것은 아니다. 본 발명은, 이후 설명될 바와 같이, 할당량 관리에 대해 회복가능한 국부 몫(local shares)을 제공한다.

할당량은 사용자 또는 사용자 그룹에 의해 사용될 수 있는 디스크량에 대한 제한이므로, 본 발명의 병렬 파일 시스템에서 그 개념을 사용하기 위해, 본 발명은 국부적인 공유가 병렬 할당을 위해 (단일 할당량 파일을 억세스하는) 할당량 관리자에 의해 분산되는 방법을 생성한다. 이는 사용자가 파일 시스템을 공유하는 다양한 컴퓨터에서 운영되는 다수의 애플리케이션을 갖는 경우에 중요하다. 본 발명은 실패시 충분한 할당량이 존재하는 많은 상황에서 즉각적인 회복을 제공한다. 특정한 경우에, 회복을 완료하기 위해서는 "할당량 점검(quotacheck)"이라 칭하여지는 UNIX 표준 유틸리티와 같은 유틸리티를 실행시킬 필요가 있다. 본 발명은 또한 최소의 간섭으로 할당량을 사용하여 애플리케이션과 동시에 할당량 점검 유틸리티를 실행시키기 위한 기법을 제공한다.

이러한 개선 및 다른 개선 내용은 다음의 상세한 설명에서 주어진다. 이점 및 특성을 갖는 본 발명을 보다 잘 이해하기 위해서는 상세한 설명과 도면을 참고한다.

수개의 관련된 구성성분으로 구현된 본 발명의 공유 디스크 파일 시스템의 바람직한 실시예가 도 1에 도시되어 있다. 도 1에서 설명되는 시스템은 파일 시스템의 관리에 참가하는 노드(1), (2), 및 (3)로 고려되는 컴퓨터에 로킹(locking) 기능(locking facility)을 제공하는 토큰(token) 관리자(11)를 포함한다. (주의. 본 발명의 토큰 관리자를 위해, 미국 특허 제5,454,108호의 로크 관리자가 수정하여야 한다.)

본 발명의 파일 시스템 코드는 애플리케이션에 의해 요구되는 판독 및 기록을 관리한다. 이 관리에서는 파일 시스템내에서 데이터를 생성 및 억세스하기 위한 애플리케이션 요구 및 공통적으로 관리되는 메타데이터가 사용된다. 이 기능은 처리의 대부분으로서, 모든 컴퓨터에서 동일하다. 적절한 토큰으로, 이 처리는 디스크 판독, 기록, 및 제어 기능을 통해 디스크를 직접 억세스한다.

도 1에 도시되어 있고 일반적으로 전술된 공유 디스크 실시예는 이전의 병렬 및 클러스터(cluster) 파일 시스템에 비해 여러 주요 이점을 제공한다. 이는 애플리케이션을 이용하여 디스크로부터, 또는 디스크에 데이터를 이동시키기 위한 최단의 이용가능 경로를 제공한다. 데이터나 메타데이터를 위한 경로에는 파일 시스템 서버가 없다. 이용가능한 경로는 서버가 병목 지점에, 또는 단일 실패 지점에 놓이는 것을 방지하는데 사용될 수 있다. 로크 관리자에서 요구되는 중심 기능이 특정한 컴퓨터에 부착되지 않으므로, 이들은 성능 및 이용가능성 요구를 만족시키도록 컴퓨터에서 컴퓨터로 이동될 수 있다.

진술한 시스템을 생성하기 위해, 언급한 바와 같이, 공유 디스크 파일 시스템에 필요한 다양한 회복 전형을 처리할 수 있고 또한 같은 파일의 병렬 갱신을 허용하는데 요구되는 메타노드(metanode) 처리에 필요한 부가적인 로크 상태를 추가하기 위해 수정할 로크 수정된다. 다른 것과 함께 이러한 특성은 이후 다양한 소제목의 상세한 설명에서 부연된다.

관리자가 미국 특허 US5454108에 설명되어 있다.

＆확장가능한 해싱(hashing) 및 안정된 커서를 갖춘 측정가능한 디렉토리 서비스＆

PO997069-PO8970062

본 발명의 공유 디스크 파일 시스템의 실행을 위해서, X/Open의 Single Unix 사양와 같은, 인터페이스 프로그래밍 표준과 충돌하지 않는 방법으로, 단일 체계이더라도 임의의 운영 체계예에서 실행될 수 있는 환경에서 매우 신속한 삽입, 삭제, 및 룩업(lookup) 동작 뿐만 아니라 모든 데이터 레크드의 순차적인 검색("스캔(scan)")을 지원하는 방법으로 많은 데이터 기록 세트를 저장하고 인덱싱(indexing)하기 위한 방법을 개발하였다. 본 발명의 순차적 스캔 및 데이터 레코드를 저장하고 찾아보는 기본 방법부터 설정하고자한다. 이전에 공지된 인덱싱 방법과 다르게, 본 발명의 순차적인 스캔은 스캔이 진행되고 있는 동안에 기록이 삽입 또는 삭제되더라도, 범위가 한정된 적은 양의 문맥(context) 정보("커서(cursor)")만을 사용해 예측가능한 결과를 만든다. 사용되는 방법은 확장가능한 해싱(hashing)이라 칭하여지는 기술 영역내에 있다. 구현된 확장가능한 해싱은 명확한 해시 테이블(hash table)을 저장하지 않고 희소 파일(sparse file)을 사용할 수 있다. 확장가능한 해싱의 사용으로, 그렇게 제한되지 않더라도 Unix 표준을 따르는 파일 시스템에서 디렉토리가 실행될 수 있다. 일반적으로, 본 발명의 바람직한 실시예는 Unix 운영 체계 환경으로 실행되므로, 그 환경은 같은 기능을 사용하는 다른 운영 체계를 고려하더라도 배경으로서 이해되어야 한다. 즉, 오늘날에는 기본 시스템이 컴퓨터라 칭하여지는 기계를 구동할 때 실제로 사용되는 것을 넘어서 많은 운영 체계층으로 동작될 수 있다.

데이터베이스(database) 시스템 뿐만 아니라 범용 파일 시스템은 데이터 기록이나 파일을 식별하는 "키(key)"를 지정함으로서 데이터의 저장 및 검색을 허용한다. 범용 파일 시스템에서는 파일명이 파일에 저장된 데이터를 억세스하기 위한 키로 동작된다; 파일명 세트 및 연관된 파일 억세스 정보를 저장하는 구조는 일반적으로 디렉토리(directory)라 칭하여진다. 데이터 기록 또는 파일명 세트가 클 때는 룩업의 속도를 높이기 위해 인덱스(index)라 칭하여지는 보조 데이터 구조가 때때로 사용된다. 인덱스는 전체적인 데이터베이스 테이블이나 디렉토리를 스켄하지 않고서도 데이터베이스 테이블의 레코드나 디렉토리내의 파일명을 찾을수 있도록 한다.

해시 테이블 뿐만 아니라 AVL 트리(tree) 및 B-트리와 같이 균형이 맞추어진 탐색 트리를 근거로 수개의 공지된 인덱싱 방법이 있다. 양호한 룩업 성능을 달성하기 위해, 이들 방법은 일부 수의 데이터 레코드를 삽입 또는 삭제한 이후에 적어도 인덱스의 일부를 구성할 것을 필요로한다. 예를 들면, B-트리에 레코드를 삽입하려면, 새로운 레코드를 위한 공간을 만들기 위해 B-트리 노드를 2개의 새로운 노드로 분할할 것이 요구된다. 그 결과로, 현존하는 레코드는 다른 물리적 위치로 이동될 필요가 있다.

이는 순차적으로 데이터 베이스 테이블이나 파일 시스템 디렉토리를 스캔할 필요가 있는, 예를 들면 디렉토리의 내용을 리스트화할 필요가 있는 애플리케이션에 대해서는 문제점을 발생시킨다. 이러한 애플리케이션은 모든 레코드 또는 디렉토리 엔트리(entry)가 검색될 때까지 데이터 베이스나 파일 시스템에 대해 반복되는 호출을 만들고, 각 호출에서 하나 이상의 레코드를 검색한다. 호출 사이에는 스캔이 얼마나 진행되었나를 추적하도록 "커서"라 칭하여지는 특정한 양의 문맥 정보가 유지되어야 한다. 이는 다음 호출이 나머지 레코드를 계속 검색할 수 있게 하기 위해 필요하다. 파일 시스템 디렉토리의 실시예들은 전형적으로 순차적인 스캔을 위한 커서로서 디렉토리내의 엔트리의 물리적인 위치나 오프셋(offset)을 사용한다. B-트리 분할과 같은 인덱스 갱신은 현존하는 엔트리를 디렉토리내에서 다른 위치로 이동시키므로, 순차적인 스캔 동안 디렉토리 엔트리를 삽입 또는 삭제하는 것은 스캔의 결과에 바람직하지 않은 효과를 갖게 된다: 현존하는 엔트리가 이동되면, 순차적인 스캔이 엔트리를 놓칠 수 있거나 같은 엔트리를 두 번 복귀(return)시킬 수 있다.

이미 공지된 인덱싱 방법에서의 이 문제점을 해결하기 위해, 인덱스를 데이터 레코드로부터 분리하여 유지시키거나, 스캔하는 동안 더 많은 문맥 정보를 저장할 수 있다. 전자의 접근법은 추가적인 레벨의 간접성이 요구되기 때문에, 룩업, 삽입, 및 삭제 동작을 본 발명의 바람직한 접근법보다 더 비용이 많이 들고 상당히 더 복잡하게 만든다. 후자의 문맥 정보를 저장하는 방법은 시스템이 현존하는 프로그래밍 인터페이스 표준과 호환될 필요가 있는 경우 적용될 수 없다. 예를 들면, X/Open Single Unix 사양에 정의된 디렉토리 인터페이스(readdir, telldir, 및 seekdir 함수)는 순차적인 디렉토리 스캔을 위한 커서로서 하나의 32 비트값만을 허용한다.

확장가능한 해싱을 사용하는 본 발명의 바람직한 실시예를 통해, 매우 신속한 삽입, 삭제, 및 룩업 기능 뿐만 아니라 순차적 스캔을 지지하는 방법으로 다수의 데이터 레코드 정합이 기록되고 인덱싱될 수 있는가를 설명할 수 있다. 더욱이, 본 발명의 바람직한 개발로, 순차적인 스캔이 레크드를 중복하여 리턴하지 않고 현존하는 모든 레코드, 즉 스캔이 진행중인 동안 삽입 또는 삭제되었던 것을 제외한 모든 레코드를 검색하는 것을 보장하기 위해, 한정된 작은 커서값(전형적으로 32 비트)으로 충분함을 인식하게 된다.

기록의 수에 대해 대략적인 경계가 미리 알려지면, 해싱은 잘 동작되는 키에 의해 데이터 기록을 찾고 기록하는 기술임은 공지되어 있다. 해싱은 이용가능한 저장 공간을 고정된 수의 "해시 버킷(hash bucket)"으로 나눔으로써 동작된다. 기록을 저장하기 위해, 키 값을 해시 버킷번호에 매핑시키는 "해시 함수(hash function)"로 공지된 맵핑이 이용된다. 새로운 레코드는 해시값에 의해 주어지는 해시 버킷에 저장된다. 키로써 기록을 찾기 위해서는 그의 해시값이 계산된다; 요구된 기록은 해시값에 의해 주어지는 버킷에 저장된 기록만을 스캔함으로서 찾을 수 있다.

일반적으로, 저장되어질 키 값의 수는 미리 공지되지 않고 임의대로 커질 수도 있다. 이는 표준 해싱 기술에 문제점을 제공하므로, 해시 버킷의 최대수가 시작부터 공지되도록 요구된다. "확장가능한 해싱"으로 공지된 해싱 알고리즘의 진보된 형태는 해시 함수값으로부터의 비트 가변수를 사용해 이 문제점을 해결한다. 해시 버킷이 채워지면, 이를 "분할"한다. 즉, 새로운 해시 버킷을 추가하고 일부 레코드를 현존하는 해시 버킷으로부터 새로운 버킷으로 이동시킨다. 어느 기록이 이동되는가는 해시 함수를 재평가하고 해시 버킷수를 결정하기 위한 한 비트를 더 사용함으로써 결정된다; 부가 비트가 0인 기록은 기존 버킷에 남아있고, 부가 비트가 1인 것은 새로운 버킷으로 이동된다.

확장가능한 해싱을 사용한 본 발명의 바람직한 실시예를 사용해, 인덱스나 디렉토리는 버킷 번호 0인 단일 해시 버킷으로 시작된다. 이에 맞추어져 있는 한, 모든 기록은 해시값에 관계없이 초기 버킷으로 들어간다. 즉, 해시 함수의 0 비트는 해시 버킷 번호를 결정하는데 사용된다. 초기 버킷이 채워질 때, 이는 버킷 번호 1인 새로운 해시 버킷을 추가함으로써 분할된다. 해시 함수의 1 비트는 기록을 배치하는데 사용된다; 해시값의 최하위 비트에 0을 갖는 기록은 버킷 0에 남아있고, 최하위 비트가 1인 기록은 해시 버킷 1로 이동된다. 새로운 기록은 해시값의 최하위 비트값에 의존해 버킷 0이나 1에 부가된다. 예를 들어, 해시 버킷 1이 다시 채워져 분할될 필요가 있다고 가정한다. 이제는 해시 함수 중 마지막 두 비트가 버킷 1로부터의 기록이 배치될 위치를 결정하는데 사용된다. 비트값 01을 갖는 기록은 해시 버킷 1에 머물고, 비트값 11을 갖는 것은 해시 번호 3(이진수 11 = 십진수 3)을 갖는 새로운 해시 버킷으로 옮겨간다. 해시 버킷 0에 있는 기록은 분할에 의해 영향을 받지 않는다. 즉, 마지막 두 비트가 00 또는 10인 기록은 버킷 0이 채워져 분할될 필요가 있을 때까지 버킷 0에 남아있는다. 또한, 버킷 0이 분할되기 이전에 버킷 1이 채워져 다시 분할될 필요가 있을수 있다.

수개의 해시 버킷이 분할된 이후의 디렉토리 구조는 표 1의 예에서 도시된 바와 같이 이진수 트리("해시 트리(hash tree)")에 의해 나타내질 수 있다. 기록은 각 내부 노드에서 어느 가지가 이어지는가를 결정하는 해시값 비트를 사용해 뿌리부분으로부터 잎부분 노드(해시 버킷)로 트리를 횡당함(traversing)으로서 발견될 수 있다. 해시값의 분포에 따라, 해시 트리의 한 가지는 다른 것 보다 더 길어질 수 있다. 잘 선택된 해시 함수, 즉 균일하게 분포된 해시값을 발생하는 함수에서는 모든 트리 가지가 대략 같은 깊이을 가질 것으로 기대된다. 순차적인 디렉토리 스캔은 좌측에서 우측의 순서로 잎부분 노드(해시 버킷)를 순회하는 깊이 우선의 트리 횡단(depth-first tree traverse)에 의해 이루어진다.

〈표 1〉

표 1 : 4회 분할 이후의 해시 트리의 예:

버킷 0은 버킷 0과 버킷 1로 분할되었고,

버킷 0은 다시 버킷 0과 버킷 2로 분할되었고,

버킷 2는 다시 버킷 2와 버킷 6으로 분할되었고,

버킷 1은 다시 버킷 1과 버킷 3으로 분할되었다.

트리의 잎부분 노드는 이진수와 십진수의 해시 버킷 번호로 라벨이 붙여진다.

본 발명의 바람직한 실시예에 따라, 해시 트리는 디스크상의 희소한 파일로 나타내지고, 기록은 해시 버킷이 분할될 때 재배치되어, 현존하는 모든 엔트리가 정확히 한 번씩 리턴될수 있도록 순차적인 디렉토리 스캔은 해시 트리를 가로지른다. 개발된 각 부분은 본 발명의 시스템에 응용가능한 개선을 제공한다.

본 발명의 시스템에서, 희소한 파일은 확장가능한 해싱을 실행하는데 사용된다. 파일 시스템에서, 정규 파일에 기록된 데이터는 디스크상에서 하나 이상의 디스크 블록(disk block)에 저장된다. Unix 및 Unix와 유사한 파일 시스템 인터페이스는 기록 호출 사이에 "탐색(seek)" 호출을 발생시킴으로써 현재 파일의 끝을 지나서 새로운 데이터를 기록하도록 허용한다. 이는 갭(gap)이나 "홀(hole)", 즉 데이터가 기록되지 않았던 파일내의 영역으로 파일을 생성하도록 허용한다. 이러한 파일이 "희소 파일(sparse file)"이라 한다. 희소 파일상에서의 판독 동작은 판독 오프셋 및 길이가 홀과 교차하는 지점에서 0을 리턴한다. 희소 파일을 효과적으로 지지하는 파일 시스템 실시예는 디스크 저장 영역을 홀에 대해서, 또는 적어도 파일 시스템에 의해 사용되는 디스크 할당 단위나 블록 크기 보다 더 큰 홀에 대해서는 할당하지 않고, 데이터가 기록된 파일 영역에 대해서만 할당한다.

확장가능한 해싱을 근거로 한 인덱스나 디렉토리는 본 발명의 바람직한 실시예에서 희소 파일을 사용해 실행된다. 각 해시 버킷은 i*s로 주어지는 오프셋으로 파일내에 저장된다. 여기서, i는 (0으로 시작되는) 해시 버킷 번호이고, s는 해시 버킷 크기이다 (모든 해시 버킷은 같은 크기를 갖는다). 디렉토리는 빈 파일로 시작된다. 첫 번째 기록이 삽입될 때, 이것은 해시 버킷 0에 저장되어, 이어서 파일에 기록되고, 파일 크기를 0에서 s로 증가시킨다. 해시 버킷 0이 분할될 필요가 있을 때는 버킷 1이 기록되고 파일 크기를 s에서 2*s로 증가시킨다. 다음 해시 버킷 분할은 처음 두 버킷 중 어느 것이 다음에 분할될 필요가 있는가에 따라, 해시 버킷 2 또는 3을 기록한다. 버킷 1이 다음에 분할되면, 해시 버킷 번호 3이 기록되고 파일 크기를 2*s에서 4*s로 증가시키며, 이 파일을 해시 버킷 2가 가게되는 위치에서 오프셋 2*s로 홀을 갖는 상태로 남기게 된다. 표 2는 표 1의 예에서 해시 트리가 희소 파일로 저장되는 방법을 도시한다.

〈표 2〉

표 2 : 희소 파일로 맵핑된 표 1로부터의 해시 트리

상술된 바와 같이, 소정의 키를 갖는 기록은 뿌리부분(버킷 0)에서 시작하여 해시 트리를 위에서 아래로 횡단함으로써 발견될 수 있다. 그러나, 모든 트리 가지는 대략 같은 깊이를 갖는 것으로 기대되므로, 트리를 아래에서 위로 가로지르는 것이 더 효과적이다. 이는 다음과 같이 행해진다. 최대 깊이(d)를 갖는 해시 트리에서, 모든 해시 버킷 번호는 d 비트 이하이고 적어도 하나의 해시 버킷은 제d 비트가 1인 버킷 번호를 가져야 하기 때문에, 파일 크기가 주어지면, 가장 긴 해시 트리 가지의 깊이를 계산할 수 있다. 그러므로, 최대 깊이(d)는 f/s-1로 주어지는 최대 해시 버킷 번호내의 비트수로 계산될 수 있다. 여기서, f는 파일 크기이다. 소정의 키로 기록을 찾기 위해서는 소정의 키에 대한 해시값의 d개 최하위 비트로 주어지는 해시 버킷 번호(b)를 먼저 계산한다. 해시 트리의 모든 가지가 같은 깊이를 가지면, 그 키로 주어진 해시 버킷에서 기록을 확실히 찾을 수 있다. 소정의 키를 저장하는 가지가 d 보다 작은 깊이를 가질 수 있으므로, 버킷 b는 해시 트리에 아직 존재하지 않을 수 있다. 이러한 경우에, 파일은 b*s로 주어지는 오프셋에서 홀을 갖게 된다. 그러므로, 홀이 발견되면, 한 비트 더 적은 해시값을 사용해 새로운 해시 버킷 번호(b')를 계산하고, 이는 해시 트리 가지가 깊이(d-1)을 가지면 기록의 위치를 산출하게 된다. 이 과정은 파일에서 홀과 마주치는 동안 반복된다. 일단 홀이 발견되지 않으면, 소정의 키를 갖는 기록은, 이것이 존재한다면, 이 해시 버킷에 있어야 한다. 룩업(loopup) 및 삽입 동작은 다음과 같이 처리된다:

룩업 동작:

1. 룩업되어질 키의 해시값(h)을 계산한다.

2. 해시 버킷 크기로 나누어지는 파일 크기에 밑을 2로 하는 log 값을 취하여 다음 정수로 반올림된 값으로 해시 트리 깊이를 계산한다.

3. h의 d 최하위 비트로 해시 버킷 번호(b)를 계산한다:

b = h mod (2-d)

4. 오프셋 b*s로 파일에서 해시 버킷을 검색한다. 여기서, s는 해시 버킷 크기.

5. 해시 버킷 b가 존재하지 않으면 (파일이 오프셋에서 홀을 포함하면), 1 만큼 d를 감소시키고 단계 3으로 다시 되돌아간다.

6. 해시 버킷 b에서 지정된 키로 기록을 찾는다; 발견되면, 기록을 리턴하고; 그렇지 않으면, "발견되지 않음" 에러를 리턴한다.

삽입 동작:

1. 삽입되는 기록의 키를 사용해, 룩업 동작에 대한 단계 1 내지 5에서 설명된 바와 같이 해시 깊이(d) 및 해시 버킷 번호(b)를 계산한다.

2. 소정의 키를 갖는 기록이 이미 해시 버킷 b에 존재하면, "이미 존재함" 에러를 복귀시킨다.

3. 해시 버킷 b에 새로운 기록을 위한 공간이 충분하면, 기록을 저장하고 복귀한다. 그렇지 않으면, 해시 버킷 b은 아래 단계에서 설명되는 바와 같이 새로운 기록을 위한 공간을 만들도록 분할되어야 한다.

4. b' = 2-d + b를 계산한다.

5. 해시 버킷 b내의 모든 기록에 대해, 다음의 단계를 반복한다:

5a. v = h mod (2 - (d+1))을 계산한다. 여기서, h는 기록의 키에 대한 해시값이다. h mod 2-d는 해시 버킷 b내의 모든 기록에 대해 b와 같기 때문에, v는 b 또는 b'과 같아야 함을 주목한다.

5b. v = b'이면, 기록을 해시 버킷 b'으로 이동시킨다; 그렇지 않으면, 기록을 b에 남겨둔다.

6. 1 만큼 d를 증가시키고 h mod (2-d)로 b를 재계산한다. 여기서, h는 삽입되는 기록의 키이다. 단계 3으로 다시 되돌아간다.

비록 여기서 설명되는 확장가능한 해싱 실행은 임의의 해시 버킷 크기로 동작되지만, 버킷 크기가 파일 시스템 블록 크기나 블록 크기의 배수와 같으면 더 효과적이다. 이는 홀이 파일 시스템 블록 경계상에 정렬되면 희소 파일의 효과적인 실행이 홀을 판독하는 디스크 I/O를 요구하지 않기 때문이다. 그래서, 모든 룩업 동작은 그 해시 버킷이 현재 캐시(cache)되어있지 않으면 기록을 갖고 있는 실제 해시 버킷을 판독하는데 많아야 하나의 디스크 I/O를 요구한다. 이는 파일 디스크 블록의 위치를 포함하는 파일 메타데이터가 캐시되어 있다고 가정함을 주목한다.

균일하게 분포된 해시값에서는 평균적으로 한 룩업 당 0.5 홀과 마주치는 것으로 예측된다. 확장가능한 해싱 실행이 파일 시스템 메타데이터에 직접 억세스하면 (예를 들어, 파일 시스템 자체에서 디렉토리를 실행하는데 사용되면), 홀은 파일 메타데이터를 직접 고려함으로서 인식될 수 있다. 그렇지 않으면, 룩업은 그가 계산한 각 해시 버킷 번호에 대해 적어도 일부 데이터를 판독하고 판독 동작이 모두 0을 리턴하였다는 사실로 홀을 인식하여야 한다. 이는 0이 아닌 값을 포함하는 짧은 헤더와 함께 해시 버킷을 저장함으로써 가장 쉽게 행해진다.

이제는 해시 버킷의 분할 및 병합이 제공된다. 기록은 각 해시 버킷내에 저장되고, 해시 버킷이 분할될 때는 이동된다. 디스크 공간은 기록을 삭제한 이후에 해시 버킷을 병합함으로서 교정된다.

각 해시 버킷은 "해시 트리 레벨(hash tree level)" 필드(field)를 갖는 헤더를 포함한다. 이 필드의 값은 해시 트리내에서 해시 버킷의 레벨, 즉 해시 트리의 뿌리부분으로부터 얼마나 멀리 이전되는가를 나타낸다. 초기에, 트리는 해시 트리 레벨 0에 버킷 0인 단 하나의 버킷만을 갖는다. 버킷 0이 분할될 때, 해시 트리 레벨은 0에서 1로 변한다; 새로운 버킷 번호 1은 분할 이후 버킷 0의 한 가지이다. 즉, 이는 또한 해시 트리 레벨 1을 갖게 된다. 해시 버킷이 분할될 때마다 그의 레벨은 1 만큼 증가되고, 부가된 새로운 버킷은 분할되었던 것과 같은 해시 트리 레벨에 지정된다.

새로운 기록이 해시 버킷에 부가될 때마다, 기록과 함께 그 때에는 해시 버킷의 해시 트리 레벨이 저장된다. 해시 버킷이 분할될 때, 버킷 헤더에 저장된 해시 트리 레벨은 증가되지만, 각 기록과 저장된 해시 트리 레벨은 변하지 않고 남아있다. 새로운 해시 버킷으로 이동된 기록은 원래 해시 트리 레벨값을 또한 유지한다. 그래서, 특정한 기록과 연관된 해시 트리 레벨값을 해시 버킷 헤더에 저장된 해시 트리 레벨과 비교함으로서, 버킷이 마지막으로 분할되기 이전에 또는 이후에 기록이 삽입되었나 여부를 결정하는 것이 가능하다. 이 기능은 이후 더 설명될 바와 같이, 순차적인 디렉토리 스캔에 의해 요구된다.

순차적인 스캔의 또 다른 요구내용은 일단 기록이 삽입되면 해시 버킷내의 기록 오프셋이 안정되게 유지되는 것이다. 그러므로, 해시 버킷에 기록이 삽입 또는 삭제될 때, 현존하는 기록은 원래 위치에 남겨진다. 즉, 자유 공간을 꽉 채우지 않는다. 더욱이, 분할로 인하여 기록이 새로운 해시 버킷으로 이동될 때, 기록은 원래 해시 버킷에서와 같은 상대 오프셋으로 새로운 버킷에 저장된다. 이는 해시 트리 레벨과 함께, 분할되기 이전의 해시 내용을 재구성하는 것을 허용한다.

몇 회의 삭제 동작 이후에는 더 이상 필요하지 않는 디스크 공간을 교정하는 것이 바람직하다. 이는 2개의 노드가 단일 해시 버킷에 맞추어지는데 충분한 기록을 갖지 않으면, 해시 트리에서 가지로 생겨난 2개의 잎부분 노드를 병합함으로서 이루어질 수 있다. 그러나, 순차적인 스캔은 분할하는 동안 뿐만 아니라 병합하는 동안에도 기록 오프셋을 보존시킬 것을 요구한다. 이는 2개의 해시 버킷이 병합될 수 있는가 여부를 결정하기 위해서는 두 버킷내의 자유 공간을 단순히 합하는 것으로 불충분함을 의미한다; 단일 해시 버킷으로 병합될 때 오버랩(overlap)되는 2개의 기록이 없음을 확인할 필요가 있다. 이를 달성하는 가장 쉬운 방법은 둘 중 하나가 완전히 빈 상태로 될 때까지 두 해시 버킷의 병합을 미루는 것이다.

두 해시 버킷이 병합될 때, 더 높은 버킷 번호를 갖는 것으로부터의 기록은 더 낮은 버킷 번호를 갖는 것으로 이동되고 더 낮은 번호의 버킷 헤더내의 해시 트리 레벨은 1 만큼 감소된다. 더 높은 해시 버킷값을 갖는 해시 버킷은 그 내용을 클리어(clear)함으로서 파일에서 제거된다. Unix와 유사한 파일 시스템에서는 이것이 fclear를 호출함으로서 이를 수행한다. 파일 시스템이 파일을 효율적으로 실행하면, 이는 해시 버킷에 의해 이전에 차지되었던 디스크 저장공간을 항당 해제(deallocation)함으로서 홀을 생성하게 된다.

본 발명의 바람직한 실시예에서는 디렉토리나 인덱스에서 모든 기록의 순차적인 스캔을 지지하기 위해, 때로 순차적인 디렉토리 스캔라 칭하여지는, 해시 트리의 내용을 리턴하기 위해 반복적으로 야기될 수 있는 스캔 동작이 제공된다. 각 호출은 하나 이상의 기록 및 다음 기록 세트를 검색하기 위해 다음 스캔 호출에 전달되어야 하는 "커서(cursor)" 값을 복귀시킨다. 먼저, 스캔이 진행 중인 동안 기록이 삽입 또는 삭제되지 않으면 이 디렉토리 스캔이 작동되는 방법을 고려하고, 이어서 스캔 루틴으로의 호출 사이에 삽입 또는 삭제로 인한 해시 트리의 변화를 처리하는 방법을 고려한다.

디렉토리 스캔는 항상 해시 버킷 번호 0인 해시 트리내의 최좌측 해시 버킷으로부터 기록을 검색함으로써 시작된다. 일단 버킷 0으로부터 모든 기록이 리턴되면, 스캔은 해시 트리에서 해시 버킷 0의 가지로 계속된다. 해시 트리가 구성된 방법으로 인해, 해시 트리에서 깊이 d에 있는 두 가지의 해시 버킷 번호는 제d 비트에서만 다르다; 좌측 가지는 해시 버킷 번호의 제d 비트에 0을 갖고 우측 가지는 1을 갖는다. 그래서, 해시 버킷 0의 가지는 해시 버킷 b1 = 2-(d-1)이다 (제d 위치에서 하나의 1 비트). 해시 버킷 b1으로부터 모든 기록을 검색한 이후에, 깊이 우선 트리를 횡단 순서로 해시 트리에서 다음 해시 버킷을 계속 스캔한다. 버킷 b1 이후의 다음 해시 버킷은 가지는 아니지만, 트리의 깊이 d-1에서 해시 버킷 b1과 공통된 조상(anceston)을 공유한다. 그래서, 이 다음 해시 버킷은 비트 위치 d-1에서 1 비트를 갖고 위치 d에서 0 비트를 가지므로, 해시 버킷 번호 b2 = 2-(d-2)를 산출한다. 일반적으로, 해시 트리에서 깊이 d에 해시 버킷 b이 주어지면, 깊이 우선으로 트리를 가로지르는 순서에서 다음 입부분 노드는 b의 d 최하위 비트를 취하고, 이 비트를 반전시키고, 결과의 값에 1 모듈로(modulo) 2-d를 더하고, 또한 결과를 다시 반전시킴으로서 찾아진다.

그러므로, 해시 트리 스캔은 해시 버킷내에서 해시 버킷 번호(b) 및 상대 오프셋(r)으로 구성된 커서 c=(b,r)를 사용해 실행될 수 있다. 커서값 (b,r)로 일어나는 스캔 동작은 먼저 해시 버킷 b에서 r 이상의 오프셋에 기록이 더 있는가 여부를 점검한다. 그러한 경우, 스캔은 r과 새로운 커서값 (b,r') 이후에 새로운 기록을 복귀시킨다. 여기서, r'은 복귀된 기록 이후의 다음 오프셋이다. 버킷 b에서 r 이상의 오프셋에 기록이 더 이상 없으면, 스캔은 (b',0)의 커서값으로 계속된다. 여기서, b'은 버킷 b의 헤더에 저장된 해시 트리 레벨로 주어지는 d의 값으로 상술된 비트-반전/증가 과정을 사용해 계산된 다음 해시 버킷 번호이다. 이 계산으로 b'에 대해 0 값이 산출되면, 해시 트리의 끝에 이르게 되어 복귀될 기록이 더 이상 없다.

삽입 또는 삭제로 인한 해시 트리의 변화는 스캔 루틴으로의 호출 사이에서 처리된다. 새로운 기록을 삽입하거나 오래된 기록을 삭제하기 위해 블록내에서 현존하는 기록을 이동시키지는 않으므로, 해시 버킷의 분할이나 병합을 일으키지 않는 한 순차적인 스캔은 삽입 및 삭제에 의해 영향을 받지 않는다. 이 경우에는 현존하는 기록이 이동되지 않으므로, 스캔은 많아야 한 번 각 기록을 찾게 되고, 스캔이 진행 중인 동안 삭제된 것을 제외하고 현존하는 모든 기록을 복귀시키도록 보장된다. 새롭게 삽입되거나 삭제된 기록은 기록의 위치(해시 버킷과 오프셋) 및 순차적인 스캔에 의해 해시 트리를 가로지르는 것과 관련된 삽입/삭제 타이밍에 의존해 발견되거나 발견되지 않을 수 있다. 순차적인 스캔이 분할/병합에 의해 영향을 받는 해시 버킷에 이르기 이전에 분할/병합이 일어나거나 스캔이 영향을 받는 버킷을 지나서 진행된 이후에 일어나면, 해시 버킷의 분할 또는 병합은 순차적인 스캔에 영향을 주지 않는다.

순차적인 스캔이 분할이나 병합에 의해 영향을 받는 해시 버킷에서 모두는 아니지만 일부 기록을 복귀시켰을 때 해시 버킷이 분할되거나 병합된 경우에만 특별한 고려가 요구된다. 블록이 분할될 때, 스캔 루틴에 대한 이전 호출로 이미 복귀된 일부 기록은 새로운 해시 버킷으로 이동될 수 있고, 이 경우에는 순차적인 스캔이 새로운 블록에 이를 때 같은 기록을 다시 복귀시키게 된다. 반대로, 해시 버킷이 병합되면, 스캔은 아직 스캔이 이르지 않은 블록에서 현재 스캔 커서값으로 주어진 것 보다 더 작은 오프셋에서의 현재 해시 버킷으로 이동되는 기록을 놓치게 될 수 있다. 본 발명은 순차적인 스캔에 영향을 주게 되는 해시 버킷의 분할 또는 병합을 검출함으로서, 또한 기록을 놓치거나 중복시키지 않고 스캔을 계속하기 위해 필요할 때 분할/병합 이전에 해시 버킷의 상태를 재구성함으로서 이러한 문제점을 해결한다. 분할이나 병합을 검출하는 것은 다음과 같이 스캔 루틴에 의해 복귀되는 커서값에 해시 트리 레벨을 포함함으로서 이루어진다. 스캔 루틴이 해시 버킷 b로부터 제1 기록을 복귀시킬 때, 이는 제1 기록이 판독될 때 해시 버킷의 헤더에서 발견된 해시 트리 레벨값(h) 뿐만 아니라, 상술된 바와 같은 해시 버킷 번호 b 및 상대적인 오프셋을 포함하는 커서값 c = (h,b,r)을 복귀시킨다. 이 커서값이 다음에 일어나는 스캔 루틴에 대한 호출에 전해질 때, 커서값에 의해 주어지는 해시 트리 레벨(h)은 해시 버킷의 헤더에서 발견되는 현재의 해시 트리 레벨(h')과 비교된다. h' 〉 h 이면, 해시 버킷 b는 스캔 루틴에 대한 두 호출 사이에서 분할되었음에 틀림없고; h' 〈 h 이거나 해시 버킷 b가 더 이상 존재하지 않으면(여기서, 파일은 오프셋 b*s로 홀을 포함한다), 이는 병합되었음에 틀림없다.

해시 버킷의 분할(h' 〉 h)은 커서가 발생되었을 때 존재하였던 바와 같이 해시 버킷을 재구성하여 처리된다. 재구성된 해시 버킷을 유지하기 위해서 임시 버퍼(buffer)가 사용된다. 원래 해시 버킷의 가지는 한 번에 하나씩 판독되고, 원래 해시 버킷 b에 존재하였던 기록은 임시 버퍼에 복사된다. 복사되는 기록은 상기에서 설명된 바와 같이 각 기록과 함께 저장된 해시 트리 레벨을 조사함으로서 식별된다: h 이하의 해시 트리 레벨을 갖는 모든 기록은 해시 버킷 b가 분할되기 이전에 이미 존재하였으므로 복사된다. 해시 버킷 분할은 새로운 해시 버킷으로 이동시킨 기록의 원래 오프셋을 유지하므로, 이들 기록은 같은 오프셋으로 임시 버퍼에 다시 복사될 수 있어, 임시 버퍼는 커서가 발생되었을 때의 원래 기록같이 보여질 수 있는(삭제된 기록을 제외하고) 것으로 확신한다. 이때, 스캔 루틴은 임시 버퍼에 재구성된 블록을 사용해 처리를 계속한다. 임시 버퍼의 끝부분에 이를 때, 스캔 루틴은 스캔 커서로부터 해시 트리 레벨(h)에 의해 주어지는 d의 값으로 상술된 비트-반전/증가 과정을 사용해 이르게될 다음 해시 버킷을 계산한다.

마지막으로, 해시 버킷 병합은 순차적인 스캔 동안에 처리된다. 스캔 커서 c = (h,b,r)에 의해 주어지는 해시 레벨 h가 해시 버킷 b의 헤더에서 발견된 해시 레벨 h' 보다 더 크거나, 해시 버킷 b가 더 이상 존재하지 않으면, 즉 그 대신에 홀이 발견되면, 병합이 검출된다. 병합의 경우와 유사하게, 이는 커서가 발생되었던 때, 즉 분할되기 이전에 존재하였던 바와 같이 해시 버킷을 재구성함으로서 행해진다. 그러나, 이 경우에는 분리된 버퍼에서 이전의 해시 버킷 내용을 재구성할 필요가 없다. 그 대신에, 스캔은 병합된 해시 버킷에서 동작되지만, 버킷에 걸쳐 다수의 패스가 이루어진다. 패스는 원래 버킷 중 하나로부터의 기록만이 리턴되고, 다른 기록은 무시된다. 이는 각 기록의 해시값을 재계산하고 현재 스캔 커서에 의해 주어지는 해시 버킷 번호 b와 해시값의 h 최하위 비트를 비교함으로서 행해진다. 이들이 같으면, 기록은 병합되기 이전에 해시 버킷 b에 위치하였던 것이므로, 기록은 스캔에 의해 복귀된다. 그렇지 않으면, 기록은 무시된다. 해시 버킷 b가 더 이상 존재하지 않으면 (그 대신에 홀이 발견되면), 해시 버킷 병합의 결과를 포함하는 버킷은 홀이 발견되지 않을 때까지 해시 트리에서 하나 이상의 레벨을 올라감으로서 (룩업과 유사하게) 발견됨을 주목한다. 스캔이 병합된 해시 버킷을 한 번 통과하여 끝부분에 이를 때, 이는 스캔 커서로부터 해시 트리 레벨(h)에 의해 주어지는 d의 값으로 상술된 비트-반전/증가 과정에 따라 다음 해시 버킷 번호 b'를 계산한다. 새로운 버킷 b'이 병합된 해시 버킷의 또 다른 가지이면, 이는 새로운 커서값 c' = (h,b',0)으로 다음 번 병합 버킷의 통과를 시작한다. 그렇지 않으면, 마지막 병합 버킷의 통과가 완료되고, 해시 버킷 b'과 커서값 c' = (h",b',0)으로 정상적인 스캔이 계속된다. 여기서, h"은 버킷 b'의 헤더에서 발견되는 해시 트리 레벨이다.

프로그래머는 아래에 요약된 스캔 동작에 대한 알고리즘을 실행할 수 있는 언어로 설명된 방법을 실행할 수 있다:

입력 : 커서값 c = (h,b,r)

하나 이상의 기록을 복귀시키기 위한 버퍼

출력 : 제공된 버퍼에서 복귀되는 기록

새로운 커서값

주의 : 스캔 루틴에 대한 첫 번째 호출에서는 (0,0,0)의 커서값이 전해져야 하고; 이어지는 호출에서는 이전 호출에 의해 복귀된 커서값이 다음 스캔 호출에 전해져야 한다.

1. h' = h, b' = b 라 설정한다.

2. 오프셋 b'*s로 파일에서 해시 버킷 b'을 판독한다. 여기서, s는 해시 버킷의 크기이다. 해시 버킷 b'이 존재하지 않으면(파일이 오프셋 b'*s로 홀을 포함하면), h'을 1 만큼 감소시키고, b' mod 2-h'으로 b'을 다시 계산하고, 또한 단계 2의 시작부로 다시 되돌아간다.

3. h'을 해시 버킷의 헤더에서 발견되는 해시 트리 레벨로 설정한다. h, b, 및 r이 모두 0(스캔의 시작)이면, h를 h'과 같은 값으로 설정한다.

4. h'을 h에 비교한다. 비교 결과에 따라, 아래에 나타내진 바와 같은 단계 5, 6, 또는 7로 계속된다:

5. h' = h 이면:

이 경우에는 b가 b'과 같아야 함을 주목한다.

5.1 해시 버킷 b에서, r 이상의 오프셋으로 다음 기록을 탐색한다. 이러한 기록이 아직 있는가 여부에 따라, 아래에 나타내진 바와 같은 단계 5.2 또는 5.3으로 계속된다.

5.2 이러한 기록이 존재하면:

기록을 복귀시키기 위해 제공된 버퍼에 아직 공간이 있는가를 점검한다. 있으면, 제공된 버퍼에 기록을 복사하고, 스캔 커서에서 오프셋 r을 방금 복사된 기록 이후의 다음 오프셋으로 갱신하고, 또한 단계 4로 다시 되돌아간다.

제공된 버퍼에 더 이상 공간이 없으면, 스캔 루틴에서 빠져나와, 현재 커서값을 복귀시킨다.

5.3 이러한 기록이 존재하지 않으면:

깊이 우선의 순서로 다음 해시 버킷이 되는 b"을 계산한다:

b" = reverse(reverse(b,h) + 1, h)

여기서, reverse(x,n)은 x의 n개 최하위 비트를 취하여 이들을 반전시키는 것을 의미한다.

b"이 0이면, 스캔의 끝부분에 이르게 된다. 이 경우에는 스캔 루틴에서 빠져나와, 현재 커서값을 복귀시킨다.

그렇지 않으면, 다음과 같이 커서 c = (h,b,r)를 갱신한다: b 및 b'을 b"과 같게 설정한다. r을 0으로 설정한다. b의 새로운 값에 의해 주어진 해시 버킷을 판독하고 h 및 h'을 해시 버킷의 헤더에서 발견된 해시 트리 레벨로 설정한다. 이어서, 단계 4로 다시 되돌아간다.

6. h' 〉 h 이면:

이 경우는 해시 버킷 b가 분할되었음을 의미한다.

6.1 아직 행하여지지 않았으면, 해시 트리에서 해시 버킷 b의 모든 가지를 임시 버퍼로 병합시킴으로서 분할 이전에 존재하였던 해시 버킷 b의 내용을 재구성한다. 이는 이전의 반복에서 버킷 b에 대해 이미 행하여졌을 수 있다; 이 경우에는 이 단계가 스킵될 수 있다.

6.2 r 이상의 오프셋으로 임시 버퍼에서 다음 기록을 찾는다. 이러한 기록이 아직 있는가 여부에 따라, 상기에 나타내진 바와 같은 단계 5.2 또는 5.3으로 계속된다.

7. h' 〈 h 이면:

이 경우는 해시 버킷 b가 병합되었음을 의미한다.

7.1 r 이상의 오프셋으로 해시 버킷 b'에서 다음 기록을 찾는다. 이러한 기록이 아직 있는가 여부에 따라, 아래에 나타내진 바와 같은 단계 7.2 또는 7.3으로 계속된다.

7.2 이러한 기록이 존재하면:

기록에서 키의 해시값을 계산하고, b"을 해시값의 h 최하위 비트로 설정한다. b"이 b와 같지 않으면, 이 기록을 스킵, 즉 스캔 커서에서 오프셋 r을 이 기록 이후의 다음 오프셋으로 갱신하고, 단계 7.1로 다시 되돌아간다.

기록을 복귀시키기 위해 제공된 버퍼에 아직 공간이 있는가를 점검한다; 그렇지 않으면, 현재 커서값과 함께 복귀한다.

충분한 공간이 있으면, 제공된 버퍼에 기록을 복사하고 스캔 커서에서 오프셋 r을 방금 복사된 기록 이후의 다음 오프셋으로 갱신한다.

단계 4로 다시 되돌아간다.

7.3 이러한 기록이 존재하지 않으면:

깊이 우선의 순서로 다음 해시 버킷이 되는 b"을 계산한다:

b" = reverse(reverse(b,h) + 1, h)

b"이 0이면, 스캔의 끝부분에 이르게 된다. 이 경우에는 스캔 루틴에서 빠져나와 현재 커서값을 복귀시킨다.

그렇지 않으면, (b mod 2-h')이 (b' mod 2-h')과 같은가 여부를 점검한다. 그러한 경우, 이는 이르게 되는 다음 버킷이 아직 버킷 b'으로 병합된 버킷 중 하나임을 의미한다. 이 경우에는 r을 0으로 설정하고 단계 7의 시작부로 다시 되돌아가, 병합된 버킷 b'의 다음 통과를 시작하게 된다.

그렇지 않으면, 병합된 버킷의 마지막 통과가 종료된다. 이 경우에는 단계 5.3에서와 같이 진행된다. 즉, b 및 b'을 b"으로 설정하고, r을 0으로 설정하고, h 및 h'을 해시 버킷 b의 헤더에서 발견된 해시 트리 레벨로 설정하고, 또한 단계 4로 다시 되돌아간다.

설명된 본 발명의 순차적인 스캔 과정의 실행으로, 이제는 커서값을 부호화하는데 사용되는 방법에 착수한다.

커서값을 유지하는데 요구되는 비트의 수를 최소화하기 위해, 해시 트리 레벨과 해시 버킷 번호는 허용가능한 가장 큰 버킷 번호를 유지하는데 요구되는 비트수 보다 단 한 비트만을 더 요구하는 단일 값으로 조합될 수 있다. 이는 L이 레벨인 경우에서, 버킷 번호가 항상 2-L과 같거나 작아야 하기 때문에 가능하다. 부호화는 그 이하이다. 이 부호화에 의해 사용되는 한 매개변수는 최대 해시 트리 레벨, 즉 트리의 가지가 성장될 수 있는 최대 깊이이다.

해시 트리 레벨 L과 해시 버킷 번호 B에 대한 커서 부호화에서:

M = 최대 해시 트리 레벨로 놓고,

H = M - L을 계산하고,

R = B의 비트 위치 반전을 계산하고,

2-H + R * 2-(H+1)로 버킷 번호와 레벨을 부호화한다.

복호화하기 위해, 낮은 차수의 0 비트수를 카운트하고, 레벨(L)을 구하도록 이 값을 M에서 감산한다. 버킷 번호를 얻기 위해, 부호화된 값을 우측 L+1 비트 만큼 쉬프트하고, 그 결과를 비트 위치로 반전시킨다.

물론, 종래 기술에 숙련된 자에게는 이 설명을 읽은 이후에 선택적인 사항이 생각날 수 있다. 예를 들면, 시스템은 다른 해시 버킷에서 수반되는 갱신을 허용하도록 로킹(locking) 및 병행성 제어를 실행할 수 있고, 또한 오버플로우(overflow) 블록을 실행할 수 있다. 순차적인 스캔 동안의 분할 처리를 위한 임시 버퍼가 정말로 필요하지 않으면, 호출자에 의해 제공되는 버퍼를 사용할 수 있다. 특히, 한 번에 한 기록만을 복귀시키는 순차적인 스캔 인터페이스를 사용해 애플리케이션(application)을 상상할 수 있고, 이 경우에서는 단지 한 기록을 복귀시키기 위해 전체 버킷을 재구성하는 것이 의미가 없다.

＆공유 디스크 파일 시스템에서의 저장 영역 활당＆

PO997067-PO8970060

병렬 할당은 본 발명의 바람직한 실시예의 특징이다. 이는, 종래 부호화된 할당 맵(encoded allocation map)과 비교해, 공유 디스크 파일 구조를 구성하는 다수의 디스크상에서 디스크 블록을 동시에 할당하는 다수의 노드간에 간섭을 줄이는 할당 맵(예를 들면, 비트 맵(bit map))을 부호화하는 것을 제공함을 의미한다. 본 발명의 시스템은 또한 다수의 노드가 줄어든 간섭으로 디스크 블록을 동시에 할당 해레하는 것을 허용한다.

파일 시스템에서 구체화된 할당 개념이 있고 저장을 할당하도록 파일 시스템에 의해 사용되는 종래의 방법이 있지만, 공유 디스크 파일 시스템에서 사용되는 종래의 방법에는 문제점이 있어서, 이는 병렬 파일 시스템에서 사용되는 바와 같이 공유 디스크 파일 시스템에서 잘 실행되는 저장의 할당 및 할당 해레을 허용하는 본 발명을 필요로 한다.

일반적으로, 파일 시스템은 다른 애플리케이션 프로그램이 디스크 드라이브와 같은 매체에서 데이터를 저장 및 검색하는 것을 허용하는 컴퓨터 프로그램이다. 간략하게, 이어지는 논의는 디스크란 용어를 사용하지만, 그 개념은 저장 매체를 구성하는 유사한 블록에 적용된다. 파일은 지명된 임의의 크기의 데이터객체이다. 파일 시스템은 애플리케이션 프로그램이 파일을 생성하여 그에 이름을 정해 주고, 파일에 데이터를 저장(또는 기록)하고, 파일로부터 데이터를 판독하고, 파일을 삭제하고, 또한 파일에 대해 다른 동작을 실행하는 것을 허용한다.

일반적으로, 파일 구조는 디스크 드라이브상의 데이터 조직이다. 파일 구조는 파일 데이터 자체에 부가하여, 메타데이터(metadata): 파일명이 대응하는 파일에 맵핑되는 디렉토리(directory), 파일에 대한 정보, 특히 디스크상에서 파일 데이터의 위치(즉, 디스크 블록이 파일 데이터를 유지하는)를 가장 중요하게 포함하는 파일 메타데이터, 메타데이터 및 파일 데이터를 저장하는데 현재 사용되는 디스크 블록을 기록하는 할당 맵(allocation map), 및 파일 구조에 대한 전체적인 정보(예를 들면, 디렉토리의 위치, 할당 맵, 및 다른 메타데이터 구조)를 포함하는 수퍼블록(superblock)을 포함한다.

한편, 공유 디스크 파일 시스템은 하나 이상의 디스크상에 위치하는 파일 구조가 분리된 컴퓨터에서 실행되는 다수의 파일 시스템에 의해 억세스되는 것임을 인식하여야 한다. 본 발명의 바람직한 실시예를 위해서는 파일 구조를 위해 이들 컴퓨터(또는 노드)가 공유된 메모리를 갖지 않고(비록 가질 수 있고, 다수의 가능한 실행에서는 국부 메모리 및 적어도다수의 SMP로 행해지는 일부 공유 메모리를 갖더라도), 이 목적을 위해 통신 네트워크로 고려될 수 있는 스위칭 네트워크(switching network)나 버스(bus)와 같은 일부 수단에 의해 파일 구조가 위치하는 디스크에 연결되는 것으로 가정한다.

더욱이, 노드는 유사한 수단에 의해 서로 통신하는 것으로 가정한다. 공유 디스크 파일 시스템은 파일 구조를 사용하는 계산이 다수의 노드에서 평행하게 실행될 수 있는 다수의 부분으로 해체되는 것을 허용한다. 이는 이 다수 노드의 처리력이 계산을 견딜 수 있게 한다.

할당 맵은 본 발명의 파일 구조 일부이다. N개의 디스크 (D0), (D1), ..., (DN-1)상에 저장된 파일 구조를 고려한다. 파일 구조에서 각 디스크 블록은 (i,j)쌍으로 식별된다. 예를 들어, (5,254)는 디스크(D5)상의 제254 블록을 식별한다. 할당 맵은 전형적으로 어레이(array) A에 저장된다. 여기서, A(i,j) 성분의 값은 디스크 블록(i,j)의 할당 상태(할당됨/무관함)를 나타낸다.

할당 맵은 전형적으로 파일 구조의 일부로 디스크상에 저장되어, 하나 이상의 디스크 블록에 위치한다. 통상적으로, A(i,j)는 맵에서 제k의 순차 성분이다. 여기서, k = iM+j이고 M은 디스크상에서 가장 큰 블록 번호 보다 더 큰 상수이다.

디스크 공간 중에서 자유로운 블록을 찾기 위해, 파일 시스템은 메모리 버퍼로 A의 블록을 판독하고, 대응하는 블록(i,j)이 자유로움을 나타내는 값을 갖는 A(i,j) 성분을 찾기 위해 버퍼를 탐색한다. 블록(i,j)을 사용하기 이전에, 파일 시스템은 블록(i,j)의 상태가 할당됨을 나타내도록 버퍼에서 A(i,j)의 값을 갱신하고, 버퍼를 다시 디스크에 기록한다. 더 이상 필요하지 않은 블록(i,j)을 자유로운 상태로 만들기 위해, 파일 시스템은 A(i,j)를 포함하는 블록을 버퍼로 판독하고, 블록(i,j)이 자유로움을 나타내도록 A(i,j)의 값을 갱신하고, 또한 버퍼로부터의 블록을 다시 디스크에 기록한다.

특별히 필요하면, 할당 맵으로의 공유 억세스가 처리된다. 공유 디스크 파일 시스템을 구성하는 노드가 공유 디스크로의 억세스를 적절하게 동기화하지 않으면, 파일 구조가 바뀌어 버린다. 이는 특히 할당 맵에 적용된다. 이를 설명하기 위해, 상술된 자유 블록을 할당하는 처리를 고려한다. 2개의 노드가 동시에 블록을 할당하도록 시도한다고 가정한다. 이러한 처리에서, 두 노드는 모두 같은 할당 맵 블록을 판독하고, 모두 자유 블록(i,j)을 기술하는 같은 A(i,j) 성분을 찾고, 모두 할당된 블록(i,j)을 나타내도록 A(i,j)를 갱신하고, 모두 그 블록을 디스크에 다시 기록하고, 또한 모두 다른 목적을 위해 블록(i,j)을 사용하도록 진행되므로, 파일 구조의 보존성(integrity)을 위반하게 된다. A(x) 및 A(y)가 모두 같은 맵 블록에 포함되면, 노드가 다른 블록 X 및 Y를 동시에 할당하더라도 마찬가지로 심각하지만 보다 민감한 문제점이 발생된다. 이 경우에, 제1 노드는 A(x)를 할당되게 설정하고, 제2 노드는 A(y)를 할당하게 설정하고, 또한 둘 모두는 동시에 맵 블록을 복사하여 버퍼처리한 것을 디스크에 기록한다. 어느 기록이 먼저 행해지는가에 의존해, 디스크상의 맵에서 블록 X나 Y가 자유롭게 나타난다. 예를 들어, 제2 노드의 기록이 제1 노드의 기록 이후에 실행되면, 디스크상의 맵에서 블록 X가 자유롭게 된다. 제1 노드는 블록 X를 사용하도록(예를 들면, 파일의 데이터 블록을 저장하도록) 진행되지만, 얼마 후에 또 다른 노드가 다른 목적을 위해 블록 X를 할당할 수 있으므로, 결과적으로 다시 파일 구조의 보존성을 위반하게 된다.

파일 구조를 바꾸어 버리는 것을 방지하기 위해, 노드는 메모리로 판독하기 이전에 각 비트 맵 블록에 대한 토큰(token)을 구해야 하고, (즉, 블록을 할당하거나 자유롭게 함으로서), 노드가 블록을 수정하면 토큰을 해제시키기 이전에 블록을 디스크에 기록하여야 한다. 토큰은 일반적으로 미국 특허 5,454,108에서 설명되는 로크 관리자(lock manager)와 같이 "분산된 토큰 관리자(distributed token manager)"로부터 구해지고 그로 해제된다. 토큰 관리자로부터 토큰을 구하고, 블록에 유지되는 토큰을 해제하기 이전에 맵 블록을 디스크에 다시 기록하는 오버헤드(overhead)는 실질적으로 공유 디스크 파일 시스템의 성능를 저하시킬 수 있다.

본 발명에서는 RAID 환경에서와 같이 다수의 디스크에 걸친 데이터의 스트라이핑(striping)이 허용된다. 스트라이핑은 개별적인 디스크상에 연속적인 데이터 블록(예를 들면, 파일 중에서)을 저장하는 기법이다. 스트라이핑의 이점은 높은 성능과 로드(load) 균형을 포함한다. 스트라이핑시에, 파일 시스템은 디스크 번호 0, ..., N-1의 순환적인 순열에 따라 별개의 디스크에 연속적인 파일 블록을 기록한다. 통상적으로 구조화된 할당 맵에서, N개 블록 또는 그 이상의 파일을 기록하는 것은 N개 맵 블록(또는, N 블록 보다 더 적은 경우에는 전체 할당 맵)을 로킹(locking)하고, 탐색하고, 갱신하고, 또한 기록하는 것을 요구한다. 이를 행하는데 대한 오버헤드는 N개 블록을 단일 디스크상에 인접하여 할당하는 것 보다 훨씬 더 높다. 더욱이, 공유 디스크 파일 시스템에서, 파일을 기록하는 노드는 요구되는 할당 맵 블록에 대한 로크(lock)를 해제하기 위해 다른 노드를 대기하는 상당한 지연을 초래할 수 있다.

이 결점에 대하여, 본 발명은 블록을 할당하는 것과 연관된 로킹, I/O, 및 탐색 오버헤드를 최소화하면서, 다수의 디스크에 걸친 스트라이핑 파일을 지지하는 할당 맵을 저장 및 관리하도록 제공된 분할 할당 맵을 사용하는 디스크 할당기(disk allocator)를 제공한다. 상술된 종래의 할당 맵과 비교해, 본 발명의 디스크 할당기는 스트라이핑된 파일을 할당될 때 억세스된 할당 맵 블록의 수를 상당히 줄인다. 더욱이, 공유 디스크 파일 시스템에서, 이는 다수의 노드가 스트라이핑된 파일을 동시에 할당할 때 할당 맵 블록 판독 및 기록과 로크 논쟁을 상당히 줄인다.

여기서 설명되는 디스크 할당기에 대한 기본적인 생각은 할당 맵을 다수의 영역으로 세부 분할하는 것이다. 맵이 K개 영역으로 나뉘면, 각 영역은 N개 디스크 각각에서 블록의 1/K를 제어한다. 파일 시스템은 맵으로의 억세스를 동기화시키기 위해 각각의 할당 맵 블록 보다는 영역을 로크시킨다. 별개의 영역을 사용함으로서, 다수의 노드는 서로 방해되지 않고 스트라이핑된 파일을 동시에 할당할 수 있다.

M개 블록을 갖는 디스크에서, 각 영역은 MN/K개의 할당 맵 성분을 포함한다. 이상적으로는 이들 MN/K개의 성분이 단일 할당 맵 블록에 맞추어지지만, 디스크의 수(또는 각 디스크의 크기)가 충분히 크거나 영역의 수가 충분히 작으면, 할당 맵 블록 보다 영역이 더 커진다. 할당 맵이 정규 파일과 같은 블록 크기를 사용하도록 허용하기 위해, 영역은 하나 이상의 세그먼트(segment)로 구성되고, 각 세그먼트는 기껏해야 할당 블록의 크기로서, N 디스크의 서브세트에서 블록 할당을 제어한다. 영역이 맵 블록 크기의 반 보다 작으면, 다수의 영역이 각 맵 블록으로 모아진다.

분할된 할당 맵의 조직을 결정하는 매개변수로는 디스크의 수(N) 뿐만 아니라 영역의 수(K), 및 디스크 당 블록의 수로 표시되는 디스크 용량(M)이 있다. 영역의 수는 적어도 파일 시스템 노드수 만큼의 크기로 선택되어야 하므로, 각 노드는 다른 영역으로부터 할당될 수 있다.

B개의 할당 맵 성분이 한 블록에 맞추어지면, 각 영역이 각 디스크에 대한 성분의 1/K, 즉 영역당 NM/K 성분을 저장하므로, 블록의 최소수, 즉 각 영역을 저장하는데 요구되는 세그먼트의 최소수는

ceil((NM/K)/B)

로 주어진다. 그러나, 특정한 디스크상에서 블록을 할당하기 위해서는 같은 세그먼트내에서, 즉 같은 할당 맵의 블록내에서는 같은 디스크를 칭하는 모든 할당 맵 성분을 보존하는 것이 바람직하다. 이러한 제한으로, 각 세그먼트는 d개의 다른 디스크에 대한 할당 성분을 유지할 수 있다. 여기서, d는

d = floor(B / (/K) = floor(BK/M)

로 주어진다. K는 적어도 M/B가 되도록 선택되어야 함을 주목한다: 그렇지 않으면, d는 0이 된다. 즉, 같은 디스크를 칭하는 할당 맵 소자는 단일 블록내에 맞추어지지 않게 된다. 그러므로, 영역당 세그먼트의 수는

L = ceil(N/d) = ceil(N / floor(BK/M))

로 주어진다.

제p 할당 맵 영역의 제q 세그먼트를 칭할 때는 표시 S(p,q)가 사용된다. 여기서, p는 0에서 K-1의 범위에 있고 q는 0에서 L-1의 범위에 있다. 할당 맵의 성분은 다음과 같이 세그먼트에 지정된다. 제i 디스크상에서 제j 블록의 할당 상태를 나타내는 성분 A(i,j)는 세그먼트 S(p,q)에 저장된다. 여기서,

p j mod K 이고,

q = floor(i/d) 이다.

세그먼트는 다음의 순서로 연속적인 할당 맵 블록에 배치된다:

S(0,0), S(1,0), S(2,0), ..., S(K-1,0),

S(0,1), S(1,1), S(2,1), ..., S(K-1,1),

...

S(0,L-1), S(1,L-1), S(2,L-1), ..., S(K-1,L-1).

다른 말로 하면, 각 영역의 제1 세그먼트는 할당 맵의 시작부에 저장되고, 계속하여 각 영역의 제2 세그먼트로 이어진다. 이 배열은 할당 맵의 완전한 재조직을 요구하지 않고 디스크를 더 부가함으로서 파일 시스템을 확장하는 것을 가능하게 한다: 파일 시스템에 디스크를 더 부가하는 것은 각 영역에 할당 맵 성분을 더 저장할 것을 요구하여, 각 영역에 하나 이상의 세그먼트를 부가하는 것을 요구할 수 있다. (얼마나 많은 세그먼트가 요구되는가는 N에 대한 새로운 값으로 L을 재계산함으로서 결정된다.) 부가되는 세그먼트는 현존하는 할당 맵의 끝부분에 간단히 추가된다.

스트라이핑된 파일의 연속적인 블록을 할당하기 위해, 노드는 영역에 대한 토큰을 구하고, 영역내의 자유로운 블록(즉, 할당 맵 성분이 자유로운 상태를 나타내는 블록)을 사용해 스트라이핑 순열에 따라 연속적인 블록을 할당한다. 토큰을 해제하기 이전에, 노드는 그 영역을 디스크에 다시 기록한다. 특정한 디스크상에서 블록을 할당하려 할 때, 영역이 그 디스크상에 자유로운 블록을 포함하지 않는 것으로 발견되면, 노드는 영역을 교환한다: 노드는 그 영역을 디스크에 다시 기록하고 토큰을 해제한 이후에, 또 다른 영역에 대한 토큰을 구하여 이로부터 할당하도록 시도한다. 노드가 특정한 디스크상에서 자유로운 블록을 찾으려는 시도를 모든 영역에서 성공하지 못하면, 이는 또 다른 디스크상에서 블록을 할당하거나(파일 시스템의 스트라이핑법에 의존해) "공간을 벗어난(out of space)" 상태임을 애플리케이션에 복귀시킬 수 있다. 전자의 경우에서, 모든 디스크에 대한 시도가 성공되지 못할 때, 파일 시스템은 "공간을 벗어난" 상태임을 복귀시킨다. 성능의 증진으로서, 파일 시스템은 전형적으로 노드가 파일 블록 기록간의 영역에 대한 토큰을 "스틸(steal)"하는 것을 허용한다. 토큰 스틸 요구에 응답해, 노드는 그 영역을 디스크에 기록하고 토큰을 철회한다. 블록 할당 해제는 2 페이지상의 Section 2.1.에서 설명된 바와 같이 유지된다; 블록을 할당 해제하기 위해, 파일 시스템은 블록을 기술한 할당 맵을 포함하는 영역을 판독하고, 그 상태를 자유로운 상태로 갱신하고, 또한 토큰을 해제하기 이전에 그 영역을 다시 디스크에 기록한다.

상술된 할당 맵 조직 및 알고리즘이 동시에 파일을 기록하는 노드간에 간섭을 상당히 줄이지만, 약간의 간섭이 가능하다. 이는 영역을 교환할 때, 노드가 교환되는 영역의 선택 근거에 대한 정보를 갖지 않는다는 사실로 인한 것이다. 이상적으로는 또 다른 노드에 의해 현재 사용되지 않는 영역으로서, 더 이상 영역을 교환하지 않고 기록을 계속하도록 허용하기에 충분한 자유 블록을 갖는 것으로 교환되어야 한다.

노드가 정보에 입각한 영역의 선택을 이룰 수 있게 하는 수단을 제공하기 위해, 본 발명은 어느 노드가 (만약 있다면) 각 할당 영역을 사용하고 있는가, 또한 각 영역에 대략 얼마나 많은 자유 공간이 남아있는가를 추적하는 프로그램인 할당 관리자를 제시한다. 파일 시스템이 초기화되는 동안, 할당 관리자는 각 영역내의 자유 블록의 수를 카운트하도록 각 영역을 조사하고, 이 정보를 테이블(table)로 보관한다. 영역을 교환하기 이전에, 파일 시스템 노드는 교환되는 영역을 알리고(그 영역내의 현재 자유 공간량을 포함하여) 교환되도록 제안된 영역을 구하도록 할당 관리자에 메시지를 전달한다. 할당 관리자는 교환되는 영역내의 자유 공간을 나타내고 이것이 더 이상 사용되지 않음을 나타내도록 테이블을 갱신한다. 이어서, 할당 관리자는 사용중이지 않고 가장 많은 양의 자유 공간을 갖는 또 다른 영역을 결정하도록 테이블을 조사하고, 그 영역이 사용중임을 나타내도록 테이블을 갱신한다. 다른 모든 영역이 사용중이면, 할당 관리자는 무작위로 하나를 선택한다. 이 프로토콜(protocol)은 사용되지 않은 영역에 교환되는 것을 장려함으로서 영역 교환수를 줄인다.

비록 상기의 알고리즘은 파일 생성을 위한 할당 맵 억세스를 국부적으로 제한하지만, 파일 삭제를 위해서도 빈번한 영역 스위치를 일으키므로, 파일을 동시에 기록하고 있는 노드와 간섭을 일으키는 것이 가능하다. 각 파일내의 블록이 단일 영역에 제한되더라도, 노드가 다른 노드에 의해 또는 다른 시간에 생성되어 다른 영역으로부터 할당된 다수의 파일(예를 들면, 디렉토리의 내용)을 삭제하게 되는 것은 자주 일어나는 경우이다. 이는 할당 해제를 일으키므로, 빈번한 영역 교환을 실행하게 한다.

이러한 영역 교환을 줄이기 위해, 할당 관리자와 파일 시스템은 할당 해제될 블록을 제어하는 영역을 현재 사용하고 있는 노드에(만약 있다면) 블록 할당 해제를 지시하는 수단을 제공한다. 이는 다음과 같이 실행된다: 블록을 삭제하기 위해, 파일 시스템은 먼저 현재 그 영역을 사용하고 있는 노드의 신원을 구하도록 할당 관리자에 메시지를 전달한다. 할당 관리자는 노드의 신원이나 영역이 사용중이 아니라는 표시에 응답한다. 후자의 경우에서는 노드가 4 페이지상의 Section 3.2.에서 설명된 바와 같이 블록을 할당 해제한다. 전자의 경우에서는 노드가 할당 관리자에 의해 지시된 노드에 메시지를 전하여 그 블록을 할당 해제함을 알린다. 제2 노드가 실제로 그 영역을 사용하고 있으면, 이는 블록을 할당 해제하고, 할당 해제했음을 알리도록 제1 노드에 응답한다. 제2 노드가 그 영역을 사용하고 있지 않으면, 이는 이 사실을 제1 노드에 알리도록 이에 응답하고, 그 후에 제1 노드가 블록을 할당 해레한다.

메시지 통화량을 줄이기 위해, 할당 해레 메시지는 일괄 처리될 수 있다. 예를 들면, 파일을 삭제할 때, 그 파일에 속하는 블록은 할당 영역으로 분류되고, 이어서 같은 영역에 속하는 블록을 포함하는 단일 할당 헤레 메시지가 현재 그 영역을 사용하고 있는 노드에 전달될 수 있다.

＆공유 디스크 파일 시스템의 간섭 처리＆

본 발명의 시스템은 노드가 서로 불필요한 간섭을 방지하는 공유 디스크 파일 시스템을 포함하는 것을 허용한다. 이를 성취하기 위해 다양한 개선이 이루어졌다.

＆측정가능한 병렬 파일 시스템에 대한 동적 프리페치＆

PO997068-PO8970061

프리페칭(prefetching)은 애플리케이션 프로그램에 의해 데이터가 요구되기 이전에 순차적으로 억세스되는 파일의 블록을 판독함으로서 I/O 대기시간을 줄이기 위해 파일 시스템에서 사용되는 기술이다. 본 발명의 시스템은 프리페칭을 위해 주어진 파일 시스템 자원을 동적으로 스케줄링하고 조정하는 문제점을 처리하여, 병렬 파일 시스템, 즉 같은 파일에 대한 데이터가 다수의 디스크 디바이스에 걸쳐 분산된 파일 시스템에서 처리량을 최대화하고 I/O 대기시간을 최소화한다.

시스템내에서, "버퍼 관리자(buffer manager)"라 칭하여지는 시스템 서비스는 메모리를 차지하기 위해 경합하는 다른 시스템 성분간에 메모리 자원의 사용을 중재한다. 각 구성성분은 얼마나 많은 메모리가 각 구성성분에 할당되는가를 결정하기 위해 버퍼 관리자가 필요로 하는 정보를 버퍼 관리자에 제공하여야 한다. 이 정보는 다음의 두 숫자로 구성된다:

1. 원하는 메모리 크기

이 숫자는 이용가능한 경우에 구성성분이 얼마나 많은 메모리를 효과적으로 사용할 수 있는가를 나타낸다.

2. 현재 작용 레벨

이 숫자는 전형적으로 시간 주기당 억세스된 메모리량으로 표시되는 구성성분의 메모리 사용 빈도의 측정을 제공한다.

버퍼 관리자는 차례로, 각 구성성분이 그 구성성분에 의한 사용을 위해 얼마나 많은 메모리를 지정하였나를 각 구성성분에 알린다.

자원을 차지하도록 경합하는 구성성분 중 하나는 최근에 억세스된 파일 데이터와 순차적인 판독기에 프리페치된 데이터를 캐시(cache) 처리하는데 사용되는 파일 시스템 버퍼 풀(file system buffer pool)이다. 본 발명은 프리페칭에 요구되는 자원을 고려하는 적절한 정보를 버퍼 관리자에 제공하고, 파일 시스템 처리량을 최대화하고 I/O 잠재시간을 최소화하도록 버퍼 관리자에 의해 지정된 자원을 예정한다.

다음에는 이것이 어떻게 달성되는가에 대한 개요를 설명한다. 부가적인 상세한 내용은 표 3 및 표 4에 제공되어, 이 개요에 이어서 더 설명된다.

- 파일 시스템 버퍼 풀은 논리적으로 두 부분으로 분할되어, 하나는 프리페칭을 위해 사용되고("프리페치 풀(prefetch pool)"), 하나는 최근에 억세스된 파일 블록의 캐시 처리를 위해 사용된다("일반적인 풀(general pool)"). "논리적으로 분할"되었다는 것은 각 버퍼가 한 풀 또는 또 다른 것에 특별히 지정될 필요가 없음을 의미한다; 그 보다, 이 분할은 총 버퍼 공간 중 얼마나 많은 공간이 프리페칭을 위해 사용되어야 하는가를 나타내는 단일 숫자를 유지함으로서 나타내진다.

- 이러한 두 가지 풀은 2개의 분리된 구성성분으로 버퍼 관리자에 주어진다. 즉, 파일 시스템은 일반적인 풀 및 프리페치 풀에 대해 작용 레벨과 원하는 메모리 크기를 분리하여 계산한다.

- 두 풀 모두의 작용 레벨은 기준 카운트와 같이, 데이터 억세스 비율을 측정하는 전통적인 기술을 사용해 계산된다. 두 풀은 단지 논리적으로만 분리되므로, 이는 각 풀에 대해 분리된 카운트를 유지함으로서 행해진다; 각 버퍼 억세스에서, 적절한 카운트는 버퍼가 순차적인 또는 무작위의 I/O에 의해 억세스되고 있는가 여부를 근거로 갱신된다.

- 원하는 일반적인 풀의 크기는 일정 시간 주기에 걸쳐 억세스된 별개의 파일 데이터의 총량을 결정하도록 기준 비트와 카운터를 사용해 작업 세트를 측정함으로서 계산된다.

- 그러나, 원하는 프리페치 풀의 크기는 다르게 계산된다. 이 계산은 파일 시스템에 속하는 디스크 디바이스의 수와 용량 뿐만 아니라 순차적으로 억세스되는 파일의 수 및 데이터가 판독되고 있는 비율을 고려한다. 이 계산은 아래에서 더 설명되고 표 3에서 상세히 기술된다.

- 이전 단계에서 계산된 수는 버퍼 관리자에 제공되고, 버퍼 관리자는 파일 시스템의 일반적인 풀 및 프리페치 풀을 나타내는 두가지 성분에 얼마나 많은 메모리가 지정되는가를 결정하는데 이들을 사용한다. 파일 시스템은 버퍼 풀의 총 크기를 이들 두 구성성분에 지정된 메모리의 합으로 설정한다. 프리페치 풀을 나타내는 구성성분에 지정된 메모리량은 얼마나 많은 데이터를 프리페치하는가를 결정하는데 사용된다. 데이터가 프리페치되는 때와 데이터가 프리페치되는 것은 도 2에서 상세히 설명된다.

표 3 및 표 4에 주어지는 알고리즘은 비병렬(단일 디스크) 파일 시스템에 저장된 한 파일로부터 판독되는 간단한 단일 애플리케이션의 예로 시작하여 가장 잘 설명된다; 이어서, 다수의 디스크를 갖춘 파일 시스템 및 다수의 애플리케이션이 처리되는 방법을 고려한다.

간단한 예에서는 최적의 처리량과 성능을 제공하는데 이중 버퍼링(double buffering)(2개의 프리페치 버퍼)으로 충분하다. 애플리케이션이 파일 판독을 시작할 때, 파일 시스템은 파일의 제1 블록을 프리페치 버퍼 중 하나로 판독한다. 제1 I/O가 종료되자마자, 파일 시스템은 파일의 제2 블록을 다른 프리페치 버퍼로 판독한다. 제2 I/O가 진행중인 동안, 제1 버퍼로부터 파일 데이터를 검색함으로서 애플리케이션으로부터의 판독 요구가 만족된다. 제1 버퍼의 끝부분에 이르면, 이어지는 판독 요구는 제2 I/O가 종료되자마자 제2 버퍼로부터 만족될 수 있다. 일단 제2 I/O가 완료되고 애플리케이션이 제1 블록으로부터 최종 바이트(byte)를 판독하면, 제1 프리페치 버퍼는 파일의 제3 블록 등을 프리페치하도록 재사용된다.

애플리케이션이 디스크 보다 느리게 판독하면, 프리페치 I/O는 애플리케이션이 이전 블록에서의 데이터 판독을 종료하기 이전에 완료된다. 이 경우에, 다음 프리페치 I/O는 애플리케이션이 이전 버퍼의 최종 바이트를 판독하자마자 시작된다. 이 경우에, 데이터는 애플리케이션이 이를 판독하는 것 만큼 빠르게 공급되어, 애플리케이션은 결코 디스크 I/O를 대기할 필요가 없다. 이것이 최선이다. 애플리케이션이 디스크로부터 검색될 수 있는 것 보다 더 빠르게 데이터를 판독하면, 한 블록의 끝부분에 이를 때마다 현재 활성화된 I/O가 종료되는 것을 대기할 필요가 있고, 새로운 프리페치 I/O는 이전 것이 종료되자마자 시작된다. 이 경우에는 데이터가 디스크로부터 검색될 수 있는 것 만큼 빠르게 판독되므로, 또 다른 최선이 된다.

표 3에 도시된 알고리즘은 이 동작을 파일 시스템에 대한 다수의 디스크 및 다수의 애플리케이션 프로그램에 일반화시킨다; 다음과 같이 되도록 요구되는 다수의 프리페치 버퍼를 계산한다: (1) 모든 애플리케이션 프로그램이 데이터를 판독하도록 시도하는 조합된 데이터 비율이 이용가능한 총 디스크 대역폭 보다 작으면, 데이터는 I/O 대기 없이 애플리케이션이 데이터를 판독하는 것 만큼 빠르게 각 에플리케이션에 공급된다. (2) 애플리케이션 프로그램의 조합된 데이터 비율이 이용가능한 총 디스크 대역폭 보다 크면, 데이터는 디스크로부터 판독될 수 있는 것 만큼 빠르게 판독된다.

두 경우 모두는 각 애플리케이션 프로그램이 데이터를 판독하도록 시도하는 비율을 결정할 것을 요구한다. 이는 애플리케이션 "사고 시간(think time)", 즉 애플리케이션이 파일 시스템에 의해 공급된 데이터를 처리하는데 소비하는 시간을 측정함으로서 행해진다. 사고 시간은 파일 시스템 버퍼 풀에서 데이터를 억세스하고 이를 애플리케이션 버퍼로 복사하기 위한 판독 시스템 호출에서의 오버헤드(overhead)를 포함하지만, 파일 시스템에서 데이터가 디스크로부터 판독되는 것을 대기하는데 소비되는 시간을 포함하지는 않는다. 본 발명은 일정 시간 간격에 걸친 애플리케이션 "데이터 소모 비율"을 그 시간 간격에서의 총 사고 시간으로 나누어진 간격 동안 애플리케이션에 의해 판독된 데이터량인 것으로 정의한다.

먼저, 총 소모 비율이 총 디스크 대역폭 보다 작은 경우를 생각해본다. 이 경우에, 적절한 프리페칭은 어떠한 애플리케이션도 I/O를 대기할 것을 전혀 요구하지 않고 원하는 데이터를 공급할 수 있어야 한다. 총 소모 비율이 단일 디스크의 대역폭 보다 더 크면, 원하는 데이터 비율을 유지하기 위해서는 다수의 디스크상에서 프리페치 I/O를 병렬로 행할 필요가 있다. 요구되는 병렬 I/O의 최소수는 총 소모 비율을 단일 디스크의 대역폭으로 나누고 그 결과를 다음의 정수로 반올림함으로서 계산될 수 있다. 이 숫자는 "병렬 계수(parallelism factor)"라 칭하여진다. 어떠한 애플리케이션 프로그램도 I/O를 대기할 것을 요구하지 않고 원하는 데이터를 공급하기 위해서는 프리페치 I/O가 진행 중인 동안 각 애플리케이션 프로그램이 또 다른 버퍼로부터 앞서 인출한 데이터를 판독할 수 있을 만큼 충분한 부가 버퍼가 이용가능해야 한다. 그러므로, 프리페칭을 위한 최적의 버퍼수는 순차적인 I/O를 위해 오픈(open)된 파일예의 수를 병렬 계수에 더함으로써 주어진다. 애플리케이션 프로그램이 앞서 인출된 블록으로부터 최종 데이터를 판독하기 때문에, 그 버퍼는 다음 프리페치 I/O를 행하는데 이용가능해진다. 표 4에서의 알고리즘에 도시된 바와 같이, 이 버퍼는 현재 판독하고 있는 버퍼의 끝부분에 가장 가까운 애플리케이션으로 다음 데이터 블록을 프리페치하는데 사용된다. "버퍼의 끝부분에 가장 가까운 애플리케이션"이란 현재의 소모 비율에 따라 가장 빨리 다음 블록으로부터 데이터를 요구하는 애플리케이션이다.

최적의 수의 프리페치 버퍼를 사용해, 측정된 소모 비율을 근거로 예측된 시간 보다 더 일찍 데이터를 판독하지 않는다면, 애플리케이션은 I/O를 대기할 필요가 없다. 실제 소모 비율이 일정하지 않으면, 프리페치 버퍼의 수는 소모 비율에서의 변화를 고려하여 증가될 수 있다. 이는 사고 시간의 평균 뿐만 아니라, 각 애플리케이션에 대한 사고 시간의 편차를 측정함으로서 행해진다. 이는 "편차 조정 소모 비율(variance adjusted consumption rate)", 즉 거의 모든 판독 요구(예를 들면, 모든 요구의 90%나 95%)가 편차 조정된 소모 비율을 근거로 예측된 시간 보다 더 일찍 도착하지 않도록 하는 비율을 계산하는데 사용된다. 이 편차 조정 소모 비율은 평균 소모 비율 대신에 병렬 계수를 계산하는데 사용된다.

이제는 모든 애플리케이션의 총 소모 비율이 파일 시스템의 총 디스크 대역폭을 넘는 경우를 생각해본다. 이 경우에, 상술된 바와 같이 계산된 병렬 계수는 파일 시스템에 이용가능한 디스크의 수보다 더 큰 수이다. 디스크의 수보다 많이 동시 I/O를 시작하는 것이 가능하지 않으므로, 디스크가 있는 것 같이 프리페치 I/O에 더 많은 버퍼를 지정하는 순간이 없다. 그러므로, 원하는 프리페치 버퍼의 수는 순차적인 I/O를 위해 오픈된 파일예의 수에 항상 더 작은 병렬 계수 또는 디스크의 수를 더한 것으로 계산된다. 소모 비율이 총 디스크 대역폭을 넘으면, 이 프리페치 버퍼의 수는 모든 디스크를 사용중인 상태로 유지하는데 충분하다. 즉, 디스크상에서의 이전 I/O가 종료되자마자 새로운 프리페치 I/O를 시작하는데 충분하다. 그래서, 데이터는 이것이 디스크로부터 검색될 수 있는 것 만큼 빠르게 공급된다.

마지막으로, 파일 시스템 디스크가 부착된 I/O 서브시스템의 특징을 고려하는 상술된 계산에 대한 두가지 개선이 설명된다. 첫 번째 것은 디바이스 드라이버에 I/O 요구가 전해지는 시간과 실제 I/O가 시작되는 시간 사이에 상당한 지연이 이 있는 시스템에 적용된다. 예를 들면, 이러한 지연은 I/O 요구가 디스크에 이르기 전에 네크워크를 통해 전해질 필요가 있는 경우 네트워크에 부착된 디스크(예를 들면, VSD)로 발생된다. 최대 디스크 처리량을 달성하기 위해, 디스크에 대한 다음 I/O 요구는 이전 I/O가 종료되기 이전에 디바이스 드라이버에 전해져야 한다. 그렇게 하기 위해, 다음 I/O를 시작하는 프리페치 버퍼는 그렇지 않은 것 보다 더 일찍 이용가능해져야 한다. 그래서, 프리페치 I/O에 전용된 버퍼의 수는 (1+epsilon)의 계수 만큼 디스크의 수 보다 커야 한다. 여기서, epsilon은 평균 I/O 요구 지연과 평균 디스크 I/O 시간의 비율로 주어진다.

버퍼 계산에서의 두 번째 개선은 디스크 제어기 및 I/O 버스와 같은 I/O 서브시스템 구성성분의 제한을 고려한다. 파일 시스템 디스크의 수가 크면, 디스크 대역폭을 합산하는 것은 시스템이 지지할 수 있는 총 디스크 I/O 처리량 보다 더 큰 수를 산출한다. 이러한 경우에, 프리페치 I/O에 전용된 프리페치 버퍼의 수는 디스크의 수 만큼 클 필요가 없다. 그 대신에, 단일 디스크의 대역폭으로 나누어진 총 I/O 처리량과 같은 버퍼의 수는 시스템이 효과적으로 지지할 수 있는 만큼의 디스크 I/O를 별렬로 시작하기에 충분하다. 총 디스크 I/O 처리량은 하드웨어 명세서로부터, 파일 시스템이 인스톨(install)될 때 처리량을 정확히 측정함으로서, 또는 파일 시스템이 실행되고 있는 동안 측정된 최대 처리량을 기록함으로서 결정될 수 있다.

상술된 개선은 모두 "효과적인 디스크의 수"를 계산하여, 표 3에 도시된 바와 같이, 프리페치 버퍼 계산에서 실제 디스크의 수 대신에 사용함으로서 나타내질 수 있다.

〈표 3〉

원하는 프리페치 풀의 크기를 계산

1. 다음과 같이 효율적인 디스크의 수를 계산한다:

n_eff = MIN(ceil((1 + L_start/L_io)*n_disks),ceil(T_sys/T_disk))

여기서,

n_disks = 파일 시스템에 이용가능한 디스크의 수

L_io = 디스크로부터 블록을 판독하는 평균 I/O 잠재시간

L_start = 평균 I/O 시작 잠재시간

T_sys = 디스크 서브시스템의 최대 총 I/O 처리량

T_disk = 단일 디스크의 평균 I/O 처리량.

2. 순차적으로 억세스되고 있는 각 오프 파일(open file)의 예 i에서, 다른 데이터 블록에 대한 모든 요구의 일부(예를 들면, 90%)가 조정된 소모 비율에 의해 예측되는 시간, 즉 파일 시스템 블록 크기를 c_i로 나눈 값으로 주어지는 길이 간격 보다 더 일찍 도착하지 않도록 조정된 소모 비율 c_i을 계산한다. 이는 그 예에 대한 평균 소모 비율과 편차를 측정함으로서 통계적으로 계산될 수 있다.

조정된 총 소모를 순차적인 모든 오픈 파일예의 조정된 소모 비율의 합으로 계산한다:

c_total = sum c_i, i = 1, ..., n_inst

여기서,

n_inst = 순차적으로 억세스되는 오픈 파일예의 수

원하는 프리페치 병렬 계수를 다음과 같이 계산한다:

n_para = c_total/T_disk

3. 원하는 프리페치 버퍼의 수는 단계 1 및 단계 2에서 계산된 값들을 사용해 다음과 같이 계산된다:

n_bufs_desired = MIN(n_para, n_eff) + n_inst

〈표 4〉

프리페치 I/O의 스케쥴링(scheduling)

이 과정에서의 입력은 표 3에 도시된 바와 같이 계산된 원하는 버퍼의 수 n_bufs_desired를 근거로 버퍼 관리자에 의해 지정되었던 실제 프리페치 버퍼의 수 n_bufs_assigned이다.

알고리즘은 전체적으로 2개의 카운터를 유지한다: n_io_total은 현재 진행중인(또는 디바이스 드라이버에 전해진) 프리페치 I/O의 수이고, n_prefetched는 블록이 프리페치된 애플리케이션에 의해 아직 판독되지 않은 프리페치 블록을 가지고 있는 버퍼의 수이다. 이들 두 숫자의 합은 프리페칭을 위해 현재 사용되는 버퍼의 수이다.

또한, 순차적으로 억세스되는 각 오픈 파일예 i에 대해, 알고리즘은 애플리케이션이 아직 프리페치 I/O를 시작하지 않은 다음 블록으로 억세스할 예측 시간을 추적한다. 이 숫자는 t_next[i]로 나타내진다.

1. n_io_total 및 n_prefetched를 0으로 초기화한다.

순차적으로 억세스되는 각 오픈 파일예 i에 대해, n_io[i]를 0으로 초기화하고, 조정된 소모 비율 c_i를 근거로 애플리케이션이 다음 데이터 블록을 요구할 시간으로 t_next[i]를 초기화한다.

순차적으로 억세스되는 모든 오픈 파일예를 t_next[i]에 의해 가장 작은 값을 갖는 것을 처음으로 분류하여 순서가 정해진 파일예의 리스트를 구성한다.

2. n_io_total + n_prefetched가 n_bufs_assigned와 같거나 크면, 단계 4로 진행하고; 그렇지 않으면, 다음 단계로 계속된다.

3. 순서가 정해진 파일예의 리스트에서 제1 파일예 i(이는 가장 작은 t_next[i] 값을 갖는 파일예이다)에 다음 프리페치 I/O 요구를 전한다.

프리페치 I/O가 막 시작된 것 이후에 애플리케이션이 다음 데이터 블록을 요구할 예측 시간으로 t_next[i]를 갱신한다. 새로운 t_nest[i] 값에 따라 모든 파일예의 순서가 정해진 파일예 리스트에서 이 파일예의 순서를 다시 정한다.

n_io_total을 증가시킨다.

단계 2로 다시 되돌아간다.

4. 발생될 다음의 사건 중 하나를 대기한다:

a) 프리페치 I/O가 완료된다:

n_io_total을 감소시키고 n_prefetched를 증가시킨다.

단계 4의 시작부로 다시 되돌아간다(다음 사건을 대기한다).

b) 판독 동작이 프리페치된 블록의 끝부분에 이른다:

판독 동작은 프리페치 버퍼로부터의 데이터를 애플리케이션의 어드레스 공간으로 복사하므로, 이제는 그 버퍼가 또 다른 프리페치에 이용가능하다.

n_prefetched를 감소시키고 단계 2로 다시 되돌아간다.

c) 버퍼 관리자가 프리페치 풀에 지정된 버퍼의 수(n_bufs_assigned)로 바뀌었다:

단계 2로 다시 되돌아간다.

d) 오픈 파일예 i를 닫는다:

순서가 정해진 파일예 리스크에서 그 파일예를 제거한다.

그 파일예에 대해 프리페치된 버퍼의 수 만큼 n_prefetched를 감소시킨다.

단계 2로 다시 되돌아간다.

＆개선된 캐시 성능을 갖춘 버퍼 관리＆

PO997071-PO8970065

본 발명의 병렬 파일 시스템은 성능이 중요한 계수인 IBM 기계에서 사용되도록 개발되었다. 성능에 영향을 줄 수 있는 특징 중 하나는 파일 시스템의 캐시(cache) 이용이다. 문제점은 시스템에 예측가능하지 않은 형태로 변하는 크기의 캐시 공간을 요구하는 점이다. 본 발명은 시스템에서의 현재 사용 패턴을 식별하고 그에 따라 캐시 동작을 조정하므로, 성능 및 공간 사용을 모두 개선하는 캐시 관리 구조를 실행한다. 본 발명은 일반적으로 본 발명의 사용 패턴 분석을 통해 캐시 성능, 공간 사용 및 분포를 개선한다.

본 발명의 시스템은 현재 동작되고 있는 작업 부하(workload) 종류를 인식하고, 그에 따라 캐시 동작을 조정하기 때문에, 본 발명의 캐시 사용 및 대치 효과가 상승된다. 제안된 구조에 의해 검출되고 응답되는 2가지 종류의 작업 부하에는 순차적인 작업 부하와 랜덤(random) 작업 부하가 있다. 이러한 분리의 근거가 되는 이론적 해석은 두 작업 사이에서 작업 설정 크기를 정의하는 차이로부터 유래된다. 미래의 동작은 현재 상태를 분석함으로써 예측된다. 일단 시스템에서 현재 사용 패턴이 정해지면, 이는 비교적 안정되고, 그에 따라 캐시가 응답하게 하는 것으로 가정한다.

완전한 캐시는 각각이 완전한 캐시 공간의 일부를 제어하고 상이한 크기의 버퍼를 책임지는 서로 다른 작업 유닛(unit)들로 분할된다. 각 작업 유닛은 시스템이 동작되는 두 종류의 작업(workload)을 모니터하는 2개의 서브-유닛(sub-unit)으로 구성된다. 서로 다른 작업유닛의 양과 이들이 책임지는 버퍼 크기는 동적으로 변한다. 캐시 관리자는 매 순간 시간에 맞게 많은 요구가 있을 가능성이 높은 버퍼 크기를 인식하고, 그에 따라 작업 유닛을 설정한다. 또한, 언제나 고정된 크기의 다른 모든 작업 유닛과 다른 버퍼 크기를 위한 인입 요구(incoming requests) 취급하는 하나의 작업 유닛이 더 존재한다. 이는 원하는 크기의 버퍼를 담당하는 캐시 부분에 인입 요구를 직접 지시함으로서 캐시 응답 시간을 증진시킨다. 이 특성은 문제점을 하나의 작업 유닛에 제한시키고 거기에서만 병합 및 재 맵핑(re-mapping)과 같은 추가 측정을 취함으로서 캐시 분열의 문제점을 완화시키는데 도움이 된다. 사용 통계량은 모든 작업 유닛의 각 서브-유닛에 대해 계속 갱신된다.

모아지는 사용 통계량은 주기적으로 조사된다. 그 결과로, 캐시 공간은 다른 작업 유닛간에 재분할된다. 본 발명의 시스템은 현재 패턴을 분석함으로써 미래 사용 패턴을 예측하므로, 새로운 공간 재분할은 즉시 작용되지 않고, 어느 정도 요구에 영향을 준다. 각 작업 유닛은 두 종류의 공간 제한, 즉 내부적인 것과 외부적인 것을 갖는다. 내부 공간 제한은 2개의 서브-작업 유닛간을 분할한다. 외부 공간 제한은 두 종류의 제한, 즉 물리적인 제한과 가상적인 제한으로 더 분할된다. 물리적인 제한은 각각의 작업 유닛에 속하는 사용 패턴 구조 분포의 제어하에서 실제 공간량을 나타낸다. 가상적인 제한은 사용 패턴 분석-이 작업 유닛이 달성하도록 시도하여야 하는 물리적인 제한으로서의 예측 처리-에 의해 반영되는 것이다. 가상적인 제한은 특정한 작업 유닛의 물리적인 제한이 성장되도록 허용되었나 여부, 또는 성장되도록 허용된 작업 유닛으로부터 요구가 있으면 그의 제어하에서 공간의 일부를 포기하게 강요되어, 본질적으로 축소되도록 허용되었나 여부를 추론하는데 사용된다.

새로운 가상적인 제한을 설정하는 과정은 다음과 같이 동작된다. 서브-작업 유닛의 통계량은 분석되어, 그에 의해 최적으로 필요로 되는 공간을 결정하는 작용 레벨 및 사용 패턴을 추론하는데 사용된다. 각 서브-작업 유닛은 필요한 것(작업 설정 크기)에 대해 최적으로 결정된 공간량을 구하고자 시도한다. 서브-작업 유닛의 상대적인 작용 레벨은 최적으로 필요로 되는 공간에서 캡(cap)을 나타낸다.

새로운 공간 획득은 각 작업 유닛 내에서의 물리적인 제한 및 가상적인 제한이 다음과 같이 상호작용하는 구조에 의해 관리된다. 새로운 버퍼에 대한 요구가 도착될 때, 이는 요구되는 크기를 제어하는 작업 유닛에 의해 다루어진다. 작업 유닛에서 자유롭거나 구해지기 매우 쉽고 신속한 버퍼가 있으면, 이는 전해지는 요구를 만족시키도록 사용된다. 이어서, 작업 유닛은 그의 물리적인 제한을 가상적인 제한과 비교하도록 진행된다. 물리적인 제한이 가상적인 제한보다 더 작지 않으면, 작업 유닛은 그의 제어하에서 구해지기 가장 쉬운 공간을 찾도록 진행된다. 그렇지 않으면, 현재 작업 유닛은 축소되도록 허용된 작업 유닛을 찾고 이에 공간 획득 요구를 전달한다. 수신한 작업 유닛은 그의 제어하에서 구해지기 가장 쉬운 공간을 찾고, 이에 대한 제어를 포기한다. 이어서, 원래 작업 유닛은 새로운 공간에 대한 제어를 가정하도록 진행되고, 전해지는 요구를 만족시키기 위해 이를 사용한다.

사용 패턴 검출 처리가 실행되는 빈도는 전체 구조의 효과에 중대한 영향을 갖는다. 처리가 너무 자주 실행되면, 이는 특정한 서브-작업 유닛에서 매우 짧은 작용 피크(peak)에 너무 거칠게 반응하게 된다. 한편, 이 처리가 긴 간격으로 실행되면, 시간이 지남에 따라 그의 효과 및 정확도가 줄어든다. 그래서, 처리가 실행될 때마다, 이것이 다음에 실행되어야 할 때를 결정한다. 그 계산은 모든 작업 유닛이 그의 제어하에서 모든 공간을 억세스하는 기대 시간을 근거로 한다. 그 주기에는 미리 정의된 상단 및 하단 경계가 가해진다. 이 간격은 사용 패턴 처리가 하나의 변형 사건에 의해 영항을 받지 않고 현재의 작업 부하 분포를 추론하는 것을 허용한다. 랜덤 작업 부하 클라이언트의 작업 세트 뿐만 아니라 순차적인 작업 부하 클라이언트를 앞서 판독하기 위해 필요로 되는 공간을 추론할 수 있다.

이 구조는 다중 목적의 환경에서 이용가능한 캐시 공간의 사용 및 부가되는 성능을 포함한다.

파일 시스템 캐시를 관리하는 종래의 방법과 유사한 것은 사용 패턴을 식별함으로서 캐시 사용을 최적화하는 본 발명의 방법이 캐시를 단일 작업 유닛으로 보고 가장 최근에 사용된 형태로 전해오는 요구를 단순히 만족시켰던 종래의 처리를 개선하는 방법임을 옳게 인정하게 한다.

전해오는 요구의 본질을 예상하고 이를 준비할 때, 전해오는 각 요구는 높은 가능성으로 이를 만족시키게 사용될 캐시 영역으로 전해진다. 더욱이, 각 작업 유닛에서 각 작업 부하에 전용될 수 있는 공간량을 알고 있으므로, 그에 따라 다른 시스템 작용(예를 들면, 프리페칭 비율)을 조정할 수 있다.

＆억세스 제어 리스트를 지지하기 위한 확장 파일 속성＆

PO997070-PO8970063

언급한 바와 같이, 그 환경에서 다른 컴퓨터에 의한 병렬 실행을 위해 본 발명의 공유 디스크 파일 시스템에 대한 억세스 제어 리스트(Access Control List)를 제공하는 것이 바람직한 것으로 결론이 지어졌다. 이를 행하기 위해, Unix 환경에서 공지된 종류의 억세스 제어 리스트를 효과적으로 지지하기 위한 확장 파일 속성이 제공되었다.

확장된 속성은 파일 자체에 저장된 데이터로부터 분리되어 억세스될 수 있는 파일과 가변 길이의 정보를 연관시키는 것을 허용한다. 확장 속성의 한 가지 사용은 무슨 사용자 또는 그룹이 무슨 방법(판독, 기록 등)으로 파일을 억세스하도록 허용되는가를 제어하는데 사용되는 억세스 제어 리스트, 간단하게 "ACL"을 저장하는 것이다. ACL은 확장된 속성의 다른 많은 사용과 상이한 확장 속성 실행에 대한 요구를 배치한다: 억세스 허가를 점검하는 모든 파일 시스템 동작은 파일의 ACL을 억세스할 필요가 있으므로, ACL 데이터에 대해 신속하고 효과적인 억세스는 파일 시스템 성능에 중요하다. 한편, ACL은 전형적으로 짧고 매우 자주 변하지 않아서, 모든 파일이 ACL을 갖더라도, 이들 ACL 중 다수가 같다. 즉, 전형적으로, 파일에서 보다 다른 ACL 값이 훨씬 적다. 본 발명은 ACL에 의해 나타내지는 사용 특징을 개척하고 속성 데이터로의 신속한 억세스를 허용하는 효과적인 공간 속성 저장을 제공하는 방법으로 확장된 속성을 실행하는 방법을 설명할 것이다. 더욱이, 이 실행은 속성 계승을 매우 효과적으로 지지한다. 이는 특히 POSIX ACL을 실행하는데 매우 적절하다.

기본적으로, 본 발명에서의 확장 속성 실행은 다음의 구성성분을 사용한다:

- 속성 파일 (간단하게 "AttrFile")

이것은 모든 속성 데이터를 저장하는 특수 파일이다. 이는 엔트리(entry)의 순차로 구성된다; 각 엔트리는 다음의 두 종류 중 하나이다: 특정한 속성값을 포함하는 속성 엔크리, 또는 속성 파일 내에서의 자유 공간, 즉 AttrFile에 새로운 속성 엔트리를 부가할 필요가 있는 경우 다음 번에 재사용될 수 있는 공간을 표시하는 자유 공간 엔트리. 두 종류의 엔트리 모두 가변 길이이지만, 분열을 줄이기 위해 적절한 경계상에(예를 들면, 8 또는 16 바이트의 배수) 정렬된다. 특정한 정렬 크기의 선택은 속성 엔트리의 최소 및 평균 크기에 의존한다.

- 속성 기준 (간단하게 "AttrRefs")

이들은 파일에 대한 속성 데이터를 AttrFile에 위치시키도록 허용하는 각 파일의 이노드(inode)에 저장되는 짧은 값이다. 이 위치는 정렬 크기의 단위로 주어진 AttrFile내에서 속성 엔트리의 오프셋으로 나타내진다. 즉, AttrRef는 정렬 크기로 나누어지는 바이트 오프셋(byte offset)으로 계산된다.

- 속성 인덱스 (간단하게 "AttrIndex")

이는 AttrFile에서 특정한 속성값을 찾도록 허용하는 데이터 구조이다. AttrIndex의 구조 및 사용은 다음 섹션의 "속성값 룩업(lookup)" 하에서 보다 상세히 설명된다.

- 속성 불요 정보 수집기(attribute garbage collector)

이는 현존하는 파일에 의해 더 이상 기준이 되지 않는 AttrFile로부터의 속성 엔트리를 제거하기 위해 적절한 시간에 시작되는 처리이다.

속성값 공유

본 발명의 공유 디스크 파일 시스템의 바람직한 실시예에서, 속성값 공유는 확장된 속성 실행으로서 제공된다. 이는 동일한 값의 속성을 갖는 모든 파일 간에 물리적인 속성 저장기의 공유를 허용한다. 이는 모든 속성 데이터를 공통된 위치에 저장함으로서 이루어지고, 그 위치는 AttrFile이라 칭하여진다. 파일 "f"의 이노드에 저장된 AttrRef는 AttrFile에서 엔트리의 오프셋으로 나타내지는, AttrFile에서 "f"에 대한 속성 데이터를 유지하는 엔트리의 위치를 포함한다. 동일한 속성값을 갖는 파일은 그들의 이노드에 같은 AttrRef 값을 포함한다. 이 속성값 공유는 다음의 2가지 방법으로 이루어진다:

1. 속성 계승:

속성 계승은 새로운 파일이 생성될 때, 그의 확장된 속성을 그 파일이 유도되는 현존 파일과 같은 값으로 설정됨을 의미한다. 예를 들어, 파일을 복사할 때, 복사본의 속성값은 원래 파일과 같은 값으로 설정될 수 있다. POSIX ACL은 다른 종류의 속성 계승의 예이다: 제안된 POSIX ACL 표준은 새로운 파일이나 디렉토리가 생성될 때, 그의 ACL은 파일이 생성되는 디렉토리와 연관된 디폴트(default) ACL 값으로 설정되도록 지정한다. 다른 말로 하면, POSIX ACL 하에서 새로운 파일은 원 디렉토리(parent directory)로부터 ACL을 계승한다.

본 발명에 따라, 이 특성 계승은 단순히 속성이 계승되는 디렉토리나 파일의 이노드로부터 AttrRef를 복사함으로써 이루어진다. 이 방법으로 계승된 속성은 원래 속성과 같은 물리적인 저장기를 공유하게 된다.

2. 속성값 룩업(lookup):

또 다른 파일로부터 계승되지 않은 값으로 속성을 설정 또는 변화시키기 위해, 같은 값을 갖는 엔트리가 AttrFile에 이미 존재하는가 여부를 결정하도록 속성 인덱스가 사용된다. 이를 위해서는 해싱(hashing)과 같은 인덱싱 방법이 사용될 수 있다: 속성값을 설정 또는 변화시키기 위해, 속성 데이터에 해시 함수(hash function)가 적용된다. 결과의 해시값은 해시 테이블(hash table)로의 인덱스로 사용되고, 여기서는 같은 해시값에 해시된 속성 데이터를 갖는 AttrFile내의 엔트리를 참고로 AttrRef의 리스트가 찾아지게 된다. 저장되는 새로운 속성 데이터는 이들 모든 엔트리내의 데이터에 대해 비교된다. 정합되면, 현존하는 엔트리를 참고로 한 AttrRef는 파일의 이노드에 저장된다. 정합되지 않으면, 새로운 속성값을 포함하는 새로운 엔트리는 AttrFile에 부가되고, 새로운 엔트리에 대한 AttrRef는 같은 속성값을 사용하는 미래의 속성 갱신이 새로운 엔트리를 찾게 되도록 해시 테이블 뿐만 아니라 파일의 이노드에 저장된다.

속성값 공유 가능성을 증가시키기 위해, 새로운 속성값은 가능하면, 이를 저장 또는 룩업하기 이전에 정규형으로 변환된다. 예를 들면, 억세스 제어 리스트내의 엔트리는 사용자 또는 그룹 식별번호(ID)에 의해 분류될 수 있다; 이는 2개의 ACL이 설정될 때 정확히 같은 포맷으로 주어지지 않았더라도, AttrFile에서 같은 저장기를 공유하도록 기능적으로 동일한 2개의 ACL을 허용한다.

확장된 속성을 저장하기 위해 실행된 본 발명의 시스템은 특히 ACL을 저장하는데 적절하고, 다른 유사한 경우에도 사용된다. 사용자가 많은 수의 파일을 소유할 때, 사용자가 다른 ACL을 그들 파일 중 각 한 파일과 연관시킬것 같지 않다. 오히려, 전형적으로 모두가 그에 연관되어 있는 같은 억세스 권리를 갖는 관련 파일 그룹이 있다. 예를 들면, 특정한 프로젝트에 속하는 파일은 전형적으로 모두 같은 ACL을 갖고, 그 프로젝트와 연관된 사용자에 억세스를 승인한다. 또 다른 예로, 같은 디렉토리 또는 디렉토리 계층구조 중 서브트리(subtree)내의 파일은 때로 같은 ACL을 공유하게 된다. 사실상, 제안된 POSIX ACL 표준에서 ACL 계승의 목적은 사용자가 같은 디렉토리에서 파일에 대한 공통된 ACL을 유지하는 것을 더 쉽게 만드는 것이다. 그러므로, 파일 시스템에서 다른 ACL 값의 총 수는 파일의 총 수 보다 상당히 작을 것으로 기대된다; 사실상, 이는 큰 계수 만큼 더 작을 것으로 기대된다. 이는 파일간에 ACL 저장기를 동일한 ACL과 공유하는 것이 각 ACL을 별개로 저장하는 것과 비교해, 적어도 같은 계수 만큼 ACL을 저장하는 공간 오버헤드를 줄이게 됨을 의미한다.

더욱이, ACL은 일반적으로 리스트를 관리하기 어렵기 때문에 각 사용자의 긴 리스트를 포함하지 않는다. 오히려, 대부분의 시스템은 사용자 그룹을 정의하는 것을 허용한다; 그룹은 ACL에서 그 그룹에 속하는 사용자를 조회하는데 사용될 수 있다. 그러므로, ACL이 매우 긴 것은 드문 경우이고, 이는 ACL이 항상 작은 양의 공간에 저장될 수 있음을 의미한다. 이 사실은 ACL 공유와 조합되어, 메모리에서 많은 수의 파일에 대해 ACL 데이터를 캐시하는 것이 가능함을 의미한다. 이는 ACL 데이터가 메모리에서 캐시되기 쉽기 때문에 파일에 대해 ACL을 검색하는 것이 매우 효과적이 되므로, 부가적인 디스크 I/O 없이 억세스될 수 있다.

많은 수의 파일에 대한 ACL이 변할 때, 이들 ACL 중 다수가 같은 새로운 값으로 변하는 것이 가능하다. 예를 들면, 이러한 변화는 특정한 프로젝트와 연관된 파일에 새로운 사용자가 억세스하는 것을 승인하도록 발생된다. ACL 공유로 인해, 한 세트의 관련된 ACL 변화 동작 중 첫 번째 것만이 AttrFile의 업데이터를 요구한다: 같은 ACL 값을 사용한 이어지는 ACL 변화 동작은 단지 AttrIndex에서 ACL 값을 룩업하는 것만을 요구한다. 이는 동시 발생되는 많은 수의 ACL 갱신을 갖는 작업 부하하에서도, AttrFile로의 억세스는 대부분 판독 전용임을 의미한다. 그래서, 모든 속성이 공통 장소에 저장된다는 사실은 병목 현상의 문제점을 일으키지 않는다. 이는 특히 국부적으로 속성 데이터를 캐시하는 것이 바람직하여, 다른 노드에서 캐시되는 속성 데이터를 무효화할 필요가 있기 때문에 AttrFile 갱신에서 비용이 훨씬 많이 들게 하는 분포된 환경에서 중요하다.

불요 정보 수집(garbage collection)은 제공될 필요가 있는 필요물이다. 속성값 공유는 속성 엔트리가 더 이상 필요로 되지 않을 때 AttrFile내의 공간을 교정하는 것을 다소 더 어렵게 만든다. 문제는 엔트리를 삭제하는 것이 안전할 때, 즉 엔트리를 참고하는 최종 파일이 삭제되거나 속성이 변할 때를 검출하는 것이다. 이 문제에 대한 일반적인 해결법은 각 엔트리에 대한 기준 카운트를 유지하는 것이다; 기준 카운트는 엔트리를 참고하는 AttrRef가 파일의 이노드에 저장될 때 증가되고, AttrRef가 삭제될 때 감소된다. AttrFile 엔트리는 기준 카운트가 다시 0으로 되돌아갈 때 삭제될 수 있다. 그러나, 이 해결법은 새로운 속성값이 AttrFile에 이미 존재하더라도, 속성이 계승되거나 저장 또는 갱신될 때마다 기준 카운트를 갱신할 것을 요구한다. 그래서, AttrFile로의 억세스는 더 이상 주로 판독 전용이 아니고, 잠재적인 병목 현상을 일으킨다.

기준 카운트 대신에, 본 발명은 불요 정보 수집을 통해 속성 공간을 교정한다. 불요 정보 수집은 다음과 같이 사용되지 않는 속성 엔트리를 찾아서 삭제한다. 각 속성 엔트리의 일부는 새로운 엔트리가 AttrFile에 부가할 때 항상 설정되는 기준 플래그, 간단하게 "RefFlag"이다. 불요 정보 수집은 다음의 세 단계로 진행된다:

단계 1:

전체 AttrFile을 스캔하고, 파일내의 모든 속성 엔트리에서 RefFlag를 off 시킨다.

단계 2:

모든 이노드를 스캔한다. 이노드에서 발견되는 각 AttrRef에 대해, AttrFile에서 대응하는 속성 엔트리의 RefFlag를 다시 on 시킨다.

단계 3:

AttrFile을 다시 스캔하고, 아직까지 off 상태인 RefFlag를 갖는 모든 속성 엔트리를 삭제한다.

불요 정보 수집이 불요 정보 수집 처리 동안에 새로운 기준을 생성한 엔트리를 삭제하지 않는 것을 보장하기 위해, 불요 정보 수집은 상기의 "속성값 공유" 중 "속성값 룩업" 섹션하에서 설명된 바와 같이 파일 속성을 설정 또는 변화시키는 것의 일부인 룩업 동작과 동기화될 필요가 있다. 불요 정보 수집은 비교적 오랜 시간-특히, 단계 2에서-이 걸리므로, 불요 정보 수집이 실행되고 있는 동안에 속성의 설정/변화 동작을 모두 단순히 디스에이블(disable)시키는 것은 바람직하지 않다. 그 대신에, 속성의 설정/변화 동작이 발견되고 새로운 값과 정합하는 값으로 AttrFile에 현존하는 엔트리가 설정될 때는 또한 AttrRef를 파일의 이노드에 저장하기 이전에 엔트리내의 RefFlag가 on 상태로 되는가 여부를 점검한다. 이 방법으로, 불요 정보 수집과 속성값 룩업 사이의 명확한 동기화는 불요 정보 수집의 최종 단계 동안과 속성값 룩업이 off 상태인 RefFlag를 갖는 속성 엔트리를 발견하는 경우에만 필요하다.

불요 정보 수집 처리를 시작하는 처리는 중요하다. 불요 정보 수집이 없으면, 활성화 상태인 속성 데이터(아직까지 기준이 되는 속성값)의 총량이 증가되지 않더라도, AttrFile은 경계없이 계속 성장된다. AttrFile이 성장되는 비율은 속성의 설정/변화 동작의 비율에 의존한다. ACL과 같은 속성의 사용에서, 이러한 동작의 비율은 본래 예측가능하지 않다. 그러므로, 고정된 정규 간격(예를 들면, 하루에 한 번)으로 불요 정보 수집을 시작하는 방법은 적절하지 않다. 그 대신에, 속성 데이터의 총 크기, 즉 AttrFile의 크기 - AttrFile내의 총 자유 공간을 모니터한다. 불요 정보 수집은 속성 데이터의 양이 특정한 계수(예를 들면, 1.5 또는 2) 만큼 성장될 때마다 시작된다. 이 방법은 활성화 상태인 속성 데이터의 양이 일정하게 머무르면 AttrFile이 성장되는 것을 방지하는데 효과적이다.

＆메타데이터 노드 동작＆

본 섹션은 다수의 컴퓨터가 같은 데이터물을 갱신 또는 확대할 필요가 있는 경우에 성능을 개선하는 메타데이터 노드(metadata node)의 동작을 설명한다. 본 발명은 이들 함수를 위한 메타노드(metanode)의 생성으로 시작하여, 메타데이터 노드를 식별하고 이를 검색하는 방법을 설명하는 것으로 이어진다.

＆메타데이터 노드의 사용＆

PO997065-PO8970072

본 발명의 메타데이터 노드에 대한 이 첫 번째 섹션은 일반적으로 본 발명의 메타데이터 노드가 무엇이고 어떠한 문제점을 해결하는가를 설명한다. 메타데이터 노드는 공유 디스크 환경에서 병렬 판독 및 기록을 위해 파일 메타데이터를 관리하도록 본 발명의 시스템에서 사용된다. 병렬 파일 시스템은 파일 시스템을 구성하는 모든 디스크나 임의의 디스크가 독립적으로 다수의 프로세서에 의해 억세스되는 것을 가능하게 한다. 이 기능을 개발하기 위해, 파일은 판독 및 기록 모두를 위해 다수의 프로세서에 의해 공유되어야 한다.

이러한 억세스의 성능을 상당히 줄일 수 있는 몇가지 문제점이 있다. 비록 노드가 파일의 다른 영역을 판독 및 기록하더라도, 판독 또는 기록하고 있는 부분에 적절한 로크(lock)를 제공하면, 이들은 모두 같은 메타데이터를 억세스할 필요가 있다. 메타데이터는 파일 크기, 파일 억세스와 수정 시간, 및 파일 데이터 블록의 어드레스를 포함한다. 예를 들어, 파일을 판독 및 기록하는 모든 동작은 이들이 파일 크기를 넘는가를 알 필요가 있고, 이들이 파일을 확장하면 메타데이터를 갱신할 필요가 있다. 이와 같은 중요한 단일 지점은 한 파일을 공유하는 진정한 병렬 기록이 필요로 되는 경우에 심각한 병목 현상을 나타낼 수 있다.

본 발명은 같은 파일을 판독 및 기록할 때 각 노드가 가능한한 독립적으로 작용하는 것을 허용하는 시스템을 실행하고, 메타데이터 정보를 관리하는 방법을 제공함으로서 파일의 일관된 관찰이 모든 노드로부터 이용가능하도록 이들 동작을 동기화하는 기계를 고안한다. 공유 디스크 파일 시스템에서 파일에 대한 메타데이터 정보를 관리하는 본 발명의 방법은 각 파일에 대해, 단일 노드가 그 파일에 대한 메타데이터-노드(또는 메타노드)로 선택되는 것을 제공한다. 메타노드는 메타데이터가 위치하는 디스크(또는 다수의 디스크)에 대한 메타데이터의 I/O 작용을 모두 처리하는 것을 담당한다.

다른 모든 노드는 메타데이터 정보를 인출 또는 갱신하기 위해 메타데이터 노드와 통신한다. 그러나, 이들 노드는 디스크상의 메타데이터 정보와 직접적으로 억세스하지 않는다.

메타데이터 노드는 파일을 억세스하는 제1 노드로 선택된다. 그래서, 단 하나의 노드만이 파일을 억세스할 필요가 있으면, 노드가 메타데이터를 직접 억세스할 수 있으므로 가외의 오버헤드가 초래되지 않는다. 부가적인 노드는 메타데이터를 위해 메타노드를 억세스하게 된다.

메타노드의 제시는 상당한 양의 디스크 작용을 방지하므로, 신속한 통신 스위치로 병렬 파일 시스템에 대해 상당한 성능 개선을 제공한다.

메타노드는 디스크상에 메타데이터를 반영하는 메타데이터의 캐시(cache)된 복사를 보존한다. 다른 노드는 또한 메타노드로부터 과거에 판독하였고 필요한 경우 증가된(예를 들면, 억세스 시간을 변화시킨) 메타데이터의 캐시된 복사를 보존한다.

각 메타데이터 성분(억세스 시간, 수정 시간, 파일 크기, 데이터 블록 디스크 어드레스)은 자체 사용 패턴과 특수한 특징을 갖는다. 예를 들면, 본 발명의 시스템은 매우 정확한 억세스 시간을 요구하지는 않지만, 5분내에서 정확한 것을 요구한다. 그래서, 메타노드에 대한 갱신이 자주 일어날 필요가 없어, 상당한 통신량이 절약된다.

또한, 파일 크기는 시스템이 일관되게 작용되는 한, 모든 노드에서 정확하지 않다. 모든 노드에서 파일 크기를 제어하는 복잡한 방법을 사용하면, 다수의 노드가 동시에 파일을 확장시킬 수 있는 병렬 기록 구조가 허용된다.

유보된 싱크 알고리즘(sync algorithm)을 사용함으로서, 많은 양의 디스크 억세스가 절약된다. 싱크 디몬(sync daemon)은 각 노드의 운영 체계 일부를 실행하는 소프트웨어의 일부이다. 싱크 디몬은 매 N 초마다 부정한 데이터 및 메타데이터를 플러쉬(flush)하도록 시도한다. M개의 노드가 평행하게 파일을 기록하면, 이는 매 N 초마다 메타데이터만을 위한 M개 디스크 억세스가 있음을 의미한다. 병렬 기록으로, 모든 노드는 메타노드에 갱신된 메타데이터를 전달하고, 메타노드는 싱크 디몬으로부터의 신호를 받을 때 매 N 초마다 파일을 플러쉬한다.

모든 노드가 메타데이터를 판독 또는 기록하기 위해 디스크를 억세스하게 된다.

＆토큰의 사용＆

PO997072-PO8970066

이 설명에서 두 번째의 병렬 기록 섹션은 메타데이터 관리자 노드를 찾기 위한 로크 모드(lock mode)의 사용에 관한 것이다. 메타데이터 관리자 노드를 찾기 위한 로크 모드를 사용하는 토큰(token)은 파일 시스템을 구성하는 모든 디스크가 다수의 프로세서에 의해 독립적으로 억세스될 수 있는 병렬 파일 시스템에서 메타데이터 노드 선택 및 식별을 위해 사용된다. 이 기능을 개발하기 위해, 파일은 판독 및 기록 모두를 위해 다수의 프로세서에 의해 공유되어야 한다.

본 시스템에서, 노드는 파일의 메타데이터를 억세스 및 갱신하는 것을 담당하는 각 파일에 지정된다. 이 메타데이터 노드(또는 메타노드)는 요구되면 다른 노드와 이 정보를 공유한다.

메타데이터 노드는 파일의 메타데이터에 대한 정보를 보존하고, 파일을 억세스하는 모든 노드와 디스크 사이에서 스마트 캐시(smart cache)로 작용한다. 메타데이터 노드(또는 메타노그)가 이 기능의 수행을 중지하는 경우가 있다. 이러한 상황은 매끄러운 동작과 검색을 가능하게 하기 위해 처리될 필요가 있다. 메타노드를 억세스하는데 사용된 노드는 똑바른 방법으로 새로운 메타노드를 선택할 필요가 있다.

메타노드를 선택하고 이 정보를 모든 노드에 이용가능하게 만든다. 선택 처리는 파일의 억세스 패턴을 고려한다. 파일당 하나, 및 단 하나의 메타노드가 있어야 한다. 또한, 구조는 메타노드 전환 및 검색을 허용해야 한다. 본 발명의 시스템에서는 메타노드가 선택되어 그 정보가 다른 노드에 공지된다.

본 발명은 토큰 관리자 서브시스템을 사용한다. 토큰 관리자는 토큰을 노드에 부여하는 배급된 서브시스템이다. 모든 노드는 특정한 모드로 지명된 토큰을 요구할 수 있다. 토큰 관리자는 모드가 다른 노드에 부여된 같은 이름의 토큰과 충돌하지 않으면 노드에 토큰을 부여한다. 각 토큰에 대해, 가능한 모드와 충돌 테이블의 리스트가 있다. 요구되는 토큰이 또 다른 노드에 부여된 토큰과 충돌하면, 이는 취소되고, 충돌하는 노드는 토큰 모드를 요구되는 모드와 충돌하지 않는 모드로 다운그레이드(downgrade)시킨다.

메타데이터 노드는 파일을 억세스하는 제1 노드가 되도록 선택된다. 그래서, 단 하나의 노드가 파일을 억세스할 필요가 있으면, 노드가 메타데이터를 직접 억세스할 수 있으므로, 가외의 오버헤드가 필요로 된다는 메시지가 없다. 부가적인 노드는 메타데이터를 위해 메타노드를 억세스하게 된다.

각 파일에 대해서, "메타노드 토큰"이 정의된다. 메타노드 토큰에는 3가지 모드가 있다: "ro" (read-only), "ww" (weak-write), 및 "xw" (exclusive-write). 규칙은 다음과 같다: "xw" 토큰은 모든 모드와 충돌한다. "ww"는 "xw" 및 자기 자신과 충돌한다. "ro"는 "xw"하고만 충돌한다. 그래서, 2가지의 가능성이 있다: 0 이상의 노드가 "ro"에서 토큰을 유지하여 많아야 한 노드가 "ww"에서 토큰을 유지할 수 있거나, 단일 노드가 "xw"에서 토큰을 유지한다. 토큰 관리자 서브시스템(간략하게 TM)은 노드에 대한 토큰을 관리하고 토큰 모드가 이 정의와 일관되도록 보장하는 것을 담당한다. 다른 모드간의 충돌은 다음의 표 5에서 요약될 수 있다:

〈표 5〉

ro ww xw

ro **

ww ** **

xw ** ** **

메타노드에 대해, 다음의 알고리즘이 고안되었다: 노드가 처음으로 파일을 오픈할 때, 이는 모드 "ww"로 메타노드 토큰을 획득하도록 시도한다. 토큰 관리자 TM은 할 수 있는 경우, 즉 다른 노드가 "ww"나 "xw"로 토큰을 유지하지 않는 경우 "ww"로 토큰을 부여한다. 이와 같이 되면, 노드는 메타노드 관리자가 된다. 그러나, 또 다른 노드가 "ww"로 토큰을 유지하면, TM은 "ro"로 토큰을 부여한다. 이때, 노드는 또 다른 노드가 메타노드임을 알게 된다. 이는 이 파일에 대한 메타노드가 누구인가를 알아내도록 TM에 질문할 수 있다.

한 노드가 메타노드로 되어야 하는 상황이 있다. 이 경우에, 오래된 메타노드가 그의 토큰을 다운그레이드시키지 않으므로, "ww" 토큰을 요구하는 것은 도움이 되지 않는다. 여기서, 메타노드가 되기를 원하는 노드는 "xw" 토큰을 요구한다. 이는 취소 메시지를 현존하는 메타노드로 전달되게 한다. 이어서, 오래된 메타노드는 그의 토큰을 "ro"로 다운그레이드시키고, TM은 "ww" 토큰을 새로운 메타노드에 복귀시킨다. 한 노드가 "xw" 토큰을 요구하고 다른 노드가 이 토큰을 전혀 유지하지 않으며, TM은 토큰을 그 모드로 부여한다.

한 노드가 "xw"로 토큰을 유지하면, 이는 이 파일에 대한 메타노드가 되지만, 부가하여 다른 노드는 이 파일을 오픈시키지 않는다. 이 경우에, 노드가 "ww"로 토큰을 획득하도록 시도하면, 그 메타노드에는 취소 메시지가 전달된다. 그 결과로, 노드는 그의 "xw" 토큰을 "ww"로 다운그레이드시키므로, TM은 "ro" 토큰을 새로운 노드에 부여할 수 있다.

＆파일 크기를 제어하도록 향상된 토큰 모드의 사용＆

PO997074-PO8970068

관련된 파일 시스템 표준은 요구가 있는 즉시 정확한 파일 크기가 이용가능할 것을 요구한다; 그러나, 데이터를 파일에 추가하는 다수의 애플리케이션이 존재할 때 모든 노드에서 평행하게 파일 크기를 보존하는 것은 성능면에 있어서 복잡하고 비용이 많이 든다. 이 특성 시리즈 다음에는 파일 크기가 보존되는 방법이 설명되어, 이는 일정한 오버헤드 없이 필요로 될 때 이용가능하게 된다. 그렇게 되면, 파일 시스템을 구성하는 모든 디스크가 다수의 프로세서에 의해 독립적으로 억세스될 수 있는 병렬 파일 시스템은 일정한 오버헤드 없이 판독 및 기록 모두를 위해 다수의 처리기에 의해 공유되는 파일로 개발될 수 있다.

파일을 공유하는 판독 및 기록은 파일의 크기를 억세스하는 것을 포함한다. 모든 판독 및 기록은 동작 오프셋이 현재 파일 크기의 범위를 벗어나는가를 점검할 필요가 있고, 그러한 경우에는 EOF(end-of-file)를 복귀시킨다. 모든 기록은 동작 오프셋이 현재 EOF의 범위를 벗어나는가를 점검할 필요가 있고, 그러한 경우에는 이를 확장시켜야 한다. 수개의 판독기 및 기록기가 있을 때, 이들은 모두 일관적이어야 한다. 그래서, 한 노드가 오프셋 1000으로 기록하면, 그 위치에서 임의의 노드에 의한 판독은 EOF를 복귀시키지 말아야 한다.

일관된 상태를 유지하는 한가지 방법은 파일 크기로의 억세스를 일렬로 나열하는 것이다. 그러나, 이것은 각 기록( 및 판독)이 각 동작 이전에 현재의 파일 크기를 구할 필요가 있으므로, 병렬 기록기에 두드러진 병목 현상을 주게 된다.

본 발명의 바람직한 실시예에서는 파일 크기의 국부적인 복사가 각 노드내에 유지된다. 또한, 각 복사와 함께, 로크 모드(lock mode)가 유지된다. 로크 관리자는 충돌되는 로크 모드가 함께 존재하지 않는 것을 보장한다. 각 판독 및 기록 동작에 대해 적절한 로크 모드는 국부적으로 캐시(cache)된 파일 크기가 이 동작의 올바른 결과를 위해 충분히 정확한 것을 보장한다. 다른 모드는 다음과 같다:

- 국부적으로 캐시된 파일 크기내에서 판독 및 기록하는 동작을 위한 "rw"

- 국부적으로 캐시된 파일 크기의 범위를 넘어서 판독하는 동작을 위한 "rf"

- 국부적으로 캐시된 파일 크기의 범위를 넘어서 기록되는 동작을 위한 "wf"

- 파일에 추가되는 기록 동작을 위한 "wa"

- 파일 크기를 감소시키므로(절단하는 것과 같이), 배타적인 기록 로크(exclusive write lock)를 필요로 하는 동작을 위한 "xw".

파일 크기의 로크 모드에 대한 충돌 테이블은 다음과 같다:

〈표 6〉

rw rf wf wa xw

rw **

rf ** ** **

wf ** ** **

wa ** ** ** **

xw ** ** ** ** **

노드가 로크 모드를 업그레이드(upgrade)시킬 때마다, 이는 파일 크기를 추적하는 특수 노드로부터 새로운 파일 크기를 판독한다(메타데이터 노드, 또는 간단하게 메타노드). 노드가 로크 모드를 다운그레이드시킬 때마다, 이는 파일 크기를 메타노드에 전달한다. 메타노드 그 자체는 수신된 모든 파일 크기 중 최대인 파일 크기를 유지한다(노드가 "xw" 모드로 파일 크기를 로크시켜, 파일 크기의 감소를 허용할 때를 제외하고).

일부 노드는 단지 파일 크기를 판독하는 것만을 허용한다(rw rf). 일부 모드(wf, wa)는 파일 크기를 증가시키는 것을 허용한다. 한 모드(xw)는 파일 크기를 감소시키는 것을 허용한다. 진정한 파일 크기는 노드가 유지하는 파일 크기의 모든 국부적인 복사 중 최대값이다.

파일 크기의 국부적인 캐시 복사내에서 판독 또는 기록하는 동작은 파일 크기에 "rw" 로크를 필요로 한다. 파일 크기의 국부적인 캐시 복사의 범위를 벗어나 판독하는 동작은 이들이 마지막으로 파일 크기를 판독하였으므로 파일 크기가 증가되지 않았음을 확실하게 할 필요가 있다. 그래서, 이들은 "rf" 로크(파일 크기를 증가시키는 모드와 충돌하는)를 획득할 필요가 있다.

파일 크기를 증가시키는 동작은 "wf"나 "wa" 로크를 획득한다. "wf" 로크는 기록기가 새로운 절대 파일 크기를 알면 필요하다. "wa" 로크는 APPEND 동작을 위해 필요하다. APPEND 동작은 현재 EOF에 기록된다. 그래서, 수회의 APPEND 동작은 다른 것의 끝부분에 하나를 기록하게 된다. 이와 같이, "wa"는 한 APPEND 동작이 다른 APPEND 동작을 대기하여야 하므로 자기 자체와 충돌한다.

파일 크기를 감소시키도록 허용하는 모드는 단지 "xw"이다. 이는 다른 모든 노드가 그들의 로크를 포기하여 국부적으로 캐시된 파일 크기를 잃게 한다. 그래서, "xw"를 획득한 노드가 그의 동작(예를 들면, 파일 절단)을 끝낸 이후에, 모든 노드는 메타노드로부터 새로운 파일 크기를 얻어야 한다.

파일을 공유하는 병렬 기록이 최대화되도록 다른 파일 크기가 다른 노드에서 캐시되는 시스템이 알려지지는 못하지만, 시스템은 모든 사용자에게 파일의 일관된 관찰을 제공한다.

상기 해결법은 다른 노드에 있는 사용자가 파일을 확장하여 매우 높은 기록 공유도를 성취하는 것을 허용한다. 기록 동작은 사용자가 파일 크기를 확장하더라도, 일렬로 나열될 필요가 없다.

＆파일 억세스 패턴을 사용하는 바이트 범위 토큰의 스마트 캐싱＆

PO997063-PO8970070

본 발명의 병렬 기록 개발에 대한 다음 내용은 모든 억세스, 즉 병렬 및 비병렬에 사용되는 로킹(locking)을 다룬다. 즉시 요구되는 파일의 일부만을 로킹하는 것은 가격이 비싸고 매 애플리케이션 호출마다 로크 관리자에 대한 호출을 요구한다. 이 알고리즘은 그 밖에 시스템에서 무슨이 진행중인가를 고려하여 애플리케이션의 요구사항을 예측하고 토큰 관리자의 호출수를 최소화하도록 시도한다.

같은 파일에 대한 병렬 판독 및 기록에서는 한 파일에서 같은 영역으로의 억세스를 일렬로 나열하기 위해, 배급된 로크 기계가 사용된다. 그러나, 이러한 로크를 얻는 것은 통상 토큰이 먼저 획득될 것을 요구하여, 이는 비용이 많이 드는 동작으로 고려된다. 그래서, 파일의 억세스 패턴을 예측하여 한 노드에서 토큰을 캐시하는 것이 유리하다. 한편, 필요하지 않은 토큰을 획득하는 것은 이 토큰이 또 다른 노드에 의해 필요될 수 있으므로, 성능을 감소시키게 된다. 본 발표내용은 파일의 억세스 패턴을 예측함으로서 성능을 최대화하도록 노드가 토큰을 획득하는 알고리즘을 설명한다.

다른 노드에서의 처리가 평행하게 기록하는 파일에서 다른 영역으로의 억세스를 일렬로 나열하는 것은 배급된 바이트 범위 로크(byte range lock)에 의해 행해진다. 처리가 바이트 범위를 로크시킬 필요가 있을 때, 이는 먼저 적절한 바이트 범위 토큰을 획득할 필요가 있다. 바이트 범위 토큰은 파일 일부에 대한 노드의 억세스 권리를 나타낸다. 그래서, 노드가 판독 모드에서 파일 X에 대한 바이트 범위 토큰을 범위(100,200)으로 유지하면, 이는 노드가 파일의 그 부분을 안전하게 판독할 수 있음을 의미한다. 그러나, 또 다른 노드가 같은 부분을 기록할 필요가 있으면, 이는 그 토큰을 스틸(steal)할 수 있으므로, 토큰의 스틸을 방지하기 위해, 노드는 실제적인 판독 이전에 토큰을 로크시켜야 한다. 판독이 완료된 이후에, 토큰은 로크 해제(unlock)된다.

토큰은 "캐싱(caching)" 로크의 방법으로 관찰될 수 있다. 노드가 파일의 일부를 로크시킬 필요가 있을 때, 이는 토큰을 로크시킬 필요가 있다. 먼저, 토큰을 획득하여 이를 로크시키게 된다. 일단 동작이 종료되고 토큰이 로크 해제되면, 이는 여전히 그 노드에 상주한다. 그래서, 같은 영역에 대해 이어지는 동작은 토큰 허가를 억세스할 필요가 없다. 토큰이 스틸될 때에만 토큰에 대한 새로운 요구가 필요로 된다.

이러한 경우가 주어지면, 로크될 필요가 있는 것 보다 더 큰 토큰을 요구하는 것이 유리하다. 예를 들어, 프로세서가 파일을 순차적으로 판독하는데, 범위 1000에서 2000까지를 판독하면, 다음 로크가 범위 1000에서 2000에 있더라도, 더 큰 토큰, 예를 들면, 1000에서 10000까지의 더 큰 토큰을 요구할 수 있다. 그러나, 이것은 다른 노드에서 과도한 토큰 통화량(token traffic)을 생성할 수 있다. 또 다른 노드가 5000에서 6000까지의 기록을 처리중이면, 토큰 획득은 동작을 지연시킨다.

새로운 개념은 바이트 범위 토큰을 획득할 때 2개의 범위를 제공하는 것이다: 필수 범위(동작에 필요한 최소 범위) 및 원하는 범위(사용되도록 기대되는 최대 범위). 토큰 관리자는 필수 범위를 포함하지만 원하는 범위 보다는 더 크지 않은 토큰을 부여하도록 보장한다.

두 알고리즘은 다음에 대해 지정될 필요가 있다: (1) 각 동작에 대해 원하는 범위와 필수 범위를 어떻게 계산하는가; 이는 요구하는 측에 있다; (2)부여되는 범위를 어떻게 계산하는가; 이는 충돌하는 토큰을 유지하는 노드에 있다.

상기의 알고리즘에서, 본 발명은 두 파일 억세스 패턴간을 구별짓는다: 랜덤 억세스 및 순차적인 억세스. 랜덤 억세스로는 다음 동작의 시작 오프셋을 예측할 수 없다. 순차적인 동작은 이전 동작이 종료된 곳에서 시작되는 것으로 가정된다. 각 파일은 각 노드에서 여러번 오픈될 수 있고, 이와 같은 각각의 예는 다른 억세스 패턴을 나타낸다.

본 발명은 다음의 알고리즘을 취한다. 주 목표는 토큰 통화량을 최소화하는 것이다.

바이트 범위를 로크시키도록 시도할 때는 먼저 토큰 관리자에게 질문하여 호환가능한 토큰이 노드상에 존재하는가를 본다. 조사된 범위는 동작에 의해 요구되는 최소 범위이다. 토큰이 국부적으로 이용가능하면, 이것이 로크되고 더 이상 토큰 작용은 일어나지 않는다.

그러나, 그 토큰이 이용가능하지 않으면, 토큰이 요구된다. 필수 범위는 파일 동작의 오프셋과 길이를 근거로 계산된다. 원하는 범위는 파일의 억세스 패턴을 근거로 한다. 파일이 랜덤하게 억세스되면, 아마도 다른 노드로부터 토큰을 스틸하는데 이점이 없으므로(대개 필요하지 않으므로), 원하는 범위는 필수 범위와 같게 된다. 그러나, 파일이 순차적으로 억세스되면, 원하는 범위는 필수 범위의 시작으로부터 시작되지만, 무한대에서 끝난다(무한대를 나타내는 특별한 값이 있다). 이는 필요하게 될 미래의 로크가 예측될 수 있으므로, 미래의 토큰 요구를 최소화하는 의도이다.

한 노드가 또 다른 노드에서의 토큰 요구와 충돌하는 토큰을 유지할 때, 이는 취소 요구를 받는다. 그 요구는 요구하는 노드의 필수 범위 및 원하는 범위를 포함한다. 여기서, 노드는 어떠한 범위를 포기할 수 있는가를 결정하여야 한다. 필수 범위가 원하는 범위와 같으면, 결정이 쉬워서, 부여된 범위는 필수 범위( 및 원하는 범위)가 된다. 그러나, 원하는 범위가 필수 범위와 다르면, 이는 요구하는 노드가 순차적으로 파일을 억세스하고 있음을 의미하여, 필수 범위의 시작에서 시작되지만 무한대에서 끝나는 토큰을 갖기를 원한다. 이어서, 노드는 파일을 억세스하는 모든 활성화된 처리를 넘기고, 이들이 파일을 순차적으로 또는 랜덤하게 억세스하는가 여부를 점검한다. 모두가 파일을 랜덤하게 억세스하면, 노드는 원하는 범위를 부여한다. 그러나, 하나 이상의 처리가 파일을 순차적으로 억세스하면, 어떠한 토큰이 곧 요구될 것인가를 알 가능성이 높으므로, 원하는 범위를 포기하는 처리는 낭비가 된다. 이 경우에는 모든 순차적인 동작의 파일 포인터(file pointer)(즉, 다음 동작이 예측되는 위치)가 조사되어, 최소 오프셋이 계산된다. 이들 동작은 순차적이므로, 최소값 이하에 있는 파일 영역을 억세스하지 않을 것으로 예측된다. 그래서, 필수 범위 보다 더 높으면, 부여된 범위는 그 계산된 최소값으로 늘여진다.

바이트 범위 토큰이 파일의 억세스 패턴을 근거로 요구되는 시스템을 알지 못한다.

상기 해결법은 파일 억세스 패턴에 대한 토큰의 캐싱(caching)을 허용한다. 이는 비용이 많이 드는 동작인 토큰의 획득을 절약하므로, 시스템의 전체적인 성능을 개선한다.

파일을 공유하는 병렬 기록을 허용할 필요성을 갖는 병렬 처리 시스템은 파일에서 같은 영역으로의 억세스를 일렬로 나열할 필요가 있다.

＆바이트 범위 토큰 인터페이스＆

PO997073-PO8970067

이 병렬 기록 개선은 바이트 범위 토큰 인터페이스(byte range token interface)로 바이트 범위 로크 알고리즘을 사용해 토큰을 설명하는 정보의 관리를 제공한다. 개발될 때 파일 시스템을 구성하는 모든 디스크가 다수의 프로세서에 의해 독립적으로 억세스될 수 있는 본 발명의 병렬 파일 시스템은 판독 및 기록 모두를 위해 파일이 다수의 프로세서에 의해 공유되어야 함을 요구한다. 파일의 일관성을 보장하면서 병렬 기록 동작을 가능하게 하기 위해, 파일내의 영역에 대한 로킹 기계(locking mechanism)가 요구된다. 배급된 환경에서는 토큰이 때때로 사용된다. 이 토큰은 목표물에 대한 노드의 억세스 권리를 나타낸다. 그러나, 노드는 한 파일의 같은 영역을 억세스하도록 시도하는 수개의 처리를 실행할 수 있다; 그래서, 국부적인 로크 기계가 토큰에 요구된다. 부가하여, 또 다른 노드는 같은 영역을 억세스할 필요가 있어서 이 노드로부터의 토큰을 취소하도록 시도할 수 있다; 그래서, 국부적인 처리가 토큰을 로크하는 한, 취소는 진행되지 말아야 한다. 이와 같이, 일부 종류의 로킹 알고리즘(locking algorithm)이 이들 토큰에 대해 사용되어야 하고, 이들은 국제 사무 기계회(International Business Machines Corporation)에 부여된 미국 특허 5,343,108에 걸친 본 발명의 개선인 토큰 관리자(TM)에 의해 관리된다.

파일에서 한 영역에 대한 억세스를 얻기 위해, 노드는 먼저 적절한 토큰을 얻고, 이를 로크시키고, 동작을 실행하고, 또한 토큰을 로크 해제(unlock)하여야 한다. 토큰을 로크시키는 것과 연관되어 몇가지 문제점이 있다; 첫 번째로, 토큰은 노드에 이미 캐시되어 있을 수 있다. 이 경우에는 이를 다시 획득할 필요가 없다. 두 번째로, 같은 노드내의 로크가 충돌되지 않도록 보장하여야 한다; 세 번째로, 현재 유지하고 있는 토큰과 충돌하는 토큰을 필요로 하는 다른 노드로부터 취소 요구를 처리하여야 한다. 여기서 제공되는 본 발명의 로킹 알고리즘은 이러한 문제점을 효과적으로 해결한다.

본 발명의 로킹 알고리즘은 API의 세트로 주어진다. 2개의 API는 바이트 범위를 로크(lock) 및 로크 해제(unlock)하는데 사용된다. 제3 API는 토큰 관리자에 의해 호출되는 콜백(callback) 함수이다. 토큰 관리자는 또한 3개의 API를 제공하는 것으로 가정된다. 한 API는 바이트 범위 토큰을 획득하기 위해 필요로 된다("Acquire"). 제2 API는 바이트 범위 토큰이 노드에 이미 캐시되었나 여부를 테스트하기 위해 필요로 된다("Test"). 제3 API는 취소의 응답으로 토큰을 포기할 때 필요로 된다("Relinquish"). 파일내의 영역을 억세스할 목적으로, 각 토큰은 억세스할 수 있는 파일 영역의 범위(시작, 끝)를 포함한다.

이제는 가정인 토큰 관리자 API를 상세히 설명한다. 다음 형태의 획득 함수는 범위 토큰을 획득하기 위해 호출된다:

Acquire(byte_range)

다음 형태의 취소 콜백 함수는 또 다른 노드가 그 토큰을 필요로 할 때마다 TM에 의해 호출된다:

Revoke(byte_range)

그 결과로, 노드는 다음을 호출하여야 한다.

Relinquish(byte_range)

본 발명이 실행한 알고리즘은 또한 TM에 의해 제공되어야 하는 제4 인터페이스를 근거로 한다:

Test(byte_range)

이는 노드상의 토큰의 존재를 TM에게 질문한다.

실행을 간략화하기 위해, 유지되는 토큰은 추적되지 않고 이를 토큰 관리자에 맡겨두며, 토큰이 획득될 필요가 있는가 여부를 질문하기 위해서는 Test 인터페이스를 사용한다. 통상적으로, 토큰이 획득될 때 실행되는 작용이 있다. 그래서, 이러한 작용이 면하여질 수 있도록 토큰이 이미 유지되는가를 아는 것이 바람직하다.

알고리즘은 현존하는 모든 로크를 유지하는 로크 테이블(range lock table, RLT)을 근거로 한다. 테이블은 로크의 미소 삽입 및 삭제를 가능하게 하도록 뮤텍스(mutex)로 보호된다. 3가지의 주요 함수가 있다: 바이트 범위를 로크시키는 LOCK; 이전에 로크된 범위를 로크 해제하는 UNLOCK; 및 취소 요구를 처리하는 REVOKE.

본 발명은 이들 인터페이스를 위한 의사 코드(pseudo code)를 제공한다:

LOCK(range)

{

retry:

old_revokes = nrevokes;

if(not Test(byte_range)) {

// 토큰은 이 노드에 존재하지 않는다.

acquire_mutex;

i_am_fetching = true;

fetch_is_pending = true;

release_mutex;

Acquire(byte_range);

get_data_associated_with byte_range;

goto retry;

} else {

// 국부적으로 토큰을 갖는다 - 이것이 스틸(steal)되지 않았음을 점검한다.

acquire_mutex;

if(old_revokes != nrevokes)

release_mutex;

goto retry;

}

// 진행중인 획득이 없음을 확인한다; 만약 있으면

//이들이 먼저 종료됨을 확인한다.

if(not i_am_fetching) {

if(fetch_is_pending) {

sleep( );

goto retry;

}

}

// Test 이전에 토큰을 획득하였으면,

// 다른 연결선(thread)을 포기한다. 뮤텍스를 유지하므로,

// 여기서는 취소가 간섭되지 않을 수 있다.

if(i_am_fetching) {

i_am_fetching = false;

fetch_is_pending = false;

wakeup( );

}

}

err = insert_range_into_lock_table;

if(err == E_CONFLICT) {

sleep( ); // 누군가가 로크를 포기할 것을 대기한다.

goto retry;

}

exit:

if(i_am_fetching) {

fetch_is_pending = false;

i_am_fetching = false;

}

release_mutex;

}

UNLOCK(range)

{

acquire_mutex;

delete_range_from_lock_table;

wakeup;

release_mutex;

}

REVOKE(range)

{

retry:

acquire_mutex;

err = insert_range_into_lock_table;

if(err == E_CONFLICT) {

sleep( );

goto retry;

}

nrevokes++;

release_mutex;

put_data_associated_with_byte_range;

Relinquish(range);

acquire_mutex;

delete_range_from_lock_table;

wake_up;

release_mutex;

}

이와 같이, 바이트 범위 로크가 설명되었다. 바이트 범위 로크에 대한 알고리즘을 알지 못하였지만, 비-바이트 범위 로크(non-byte range lock)에 대한 이전 해결법은 토큰 관리자 이외에서 토큰 상태의 복사를 보존함을 주목한다.

여기서는 본 발명의 분포된 토큰 관리자가 범위(즉, 파일의 바이트 범위)의 로킹을 위한 인터페이스(Acquire, Revoke, Relinquish, 및 Test)를 제공함을 인지하게 된다. 소정의 범위는 공유되는 판독 또는 배타적인 기록 모드로 요구될 수 있다.

본 발명의 특성 중 하나는 완전한 다중노드 시스템에서 현존하는 충돌 범위와 요구를 비교하여 또 다른 컴퓨터로부터 토큰 취소를 요구하지 않을 가능성이 가장 큰 바이트 범위를 부여하도록 지정된 바이트에 대한 토큰 요구를 조사하는 것이다. 이는 요구하는 노드에 대한 다음 동작이 또 다른 토큰 요구를 청할 가능성을 줄인다. 카운터 및 비블로킹(non-blocking) 로크 호출은 다른 로크를 유지하면서 토큰을 획득하는데 사용된다. 이 기술은 요구되는 다중 노드 일렬화를 허용하는 단일 노드내에서 다수의 요구에 대해 보다 효과적인 일렬화를 허용한다.

본 발명은 토큰 관리자의 Acquire 인터페이스가 입력으로서 모드 뿐만 아니라 2개의 범위, 즉 "필수" 범위 및 "원하는" 범위를 갖도록 제공한다. 원하는 범위는 필수 범위의 수퍼세트이다. Acquire 인터페이스를 호출하는 애플리케이션은 최소한 필수 범위에 부여될 것으로 보장된다. 토큰 관리자는 충돌 범위(즉, 충돌 모드에서 필수 범위와 오버랩(overlap)되는 범위)가 다른 노드에 부여되었나를 결정한다. 충돌 범위가 발견되면, 토큰 관리자는 충돌 범위를 갖는 각 노드가 오버랩된 범위를 비충돌 모드로 다운그레이드시킬 것을 요구한다.

본 발명은 또한 필수 범위와의 충돌이 해결될 때, Acquire 인터페이스가 전체적으로 필수 범위를 포함하고, 또한 원하는 범위의 서브세트인 최대 인접 범위를 결정하도록 제공한다. 이것은 Acquire 인터페이스가 호출하는 애플리케이션으로 복귀하게 될 범위이다. 사실상, 토큰 관리자는 부가적인 취소 처리가 실행되는 것을 요구하지 않는 가능한 최대의 범위(원하는 범위 매개변수로 경계가 지워지는)를 부여한다.

토큰 관리자의 Revoke 인터페이스는 또 다른 노드로부터 충돌 범위 요구에 대한 정보를 애플리케이션에 통신하는데 사용된다. Acquire 요구가 다른 노드에 부여된 충돌 범위를 검출하면, 이는 각 충돌 노드에서 실행되는 애플리케이션이 부여된 범위를 다운그레이드시킬 것을 요구한다. Revoke 인터페이스를 통해 전달되는 정보는 모드 뿐만 아니라, Acquire 호출에서 지정되었던 필수 범위 및 원하는 범위를 포함한다.

취소 요구가 수신되면, 애플리케이션은 부여된 충돌 범위를 비충돌 모드로 다운그레이드시키도록 Relinquish 인터페이스를 발동시키게 된다. 최소한, 애플리케이션은 "필수" 범위와 충돌하는 범위를 비충돌 모드로 다운그레이드시키도록 요구되지만, 원하는 경우 더 큰 범위를 다운그레이드시킬 수 있다.

토큰 관리자는 또한 소정의 범위가 국부적인 노드에 부여되는가를 결정하는 Test 인터페이스를 제공한다. 이는 소정의 범위에 대한 Acquire 요구가 토큰 서버(server) 노드로의 통신 요구를 청하는가를 결정하도록 애플리케이션에 의해 사용될 수 있다.

소정의 바이트 범위에 대한 숫자열을 사용하여 처리함으로서, 같은 바이트 범위에서 정확한 획득 및 취소 처리가 제공된다. 토큰 관리자 Acquire 인터페이스는 독립 변수로 숫자열을 갖는다. 각 토큰에서, 토큰 관리자는 범위에 부여된 각 노드에 대해 숫자열을 유지한다. 토큰 관리자는 Acquire 동작의 완료시 노드 숫자열을 포함하는 필드(field)를 Acquire 인터페이스에서 지정된 값으로 갱신한다. 이어지는 Acquire가 충돌 노드로부터 범위를 취소하여야 할 때, 토큰 관리자는 그 노드로부터 성공적으로 최종 획득된 숫자열을 토큰 관리자 Revoke 인터페이스를 통해 전달한다.

분포된 토큰 관리자에 대한 인터페이스(Acquire, Revoke, Relinquish, Test)를 고려할 때, 본 발명은 사용되는 코드에 국부적인 바이트 범위 로크를 실행하기 위한 개선된 방법을 제공하였다. 몇가지 잠재적인 복잡성은 일부 정교한 특성을 가능하게 하면서, 이 프로그램 방법이나 알고리즘에 의해 훌륭하게 해결된다.

본 발명은 본문에서 의사 코드와 아래에 설명된 로킹 기술을 사용해 다수의 토큰 획득 및 취소를 평행하게 처리한다. 본 발명은 수회의 토큰 획득이 평행하게 처리되는 것을 허용한다. 이는 예를 들면, 수개의 파일 시스템 동작이 파일의 다른 부분을 평행하게 억세스하도록 시도하는 경우에 일어날 수 있다.

또한, 본 발명은 두가지가 충돌하지 않는 한, 파일의 일부에 대한 토큰 취소가 획득과 동시에 일어나는 것을 허용한다.

바이트 범위 로크 코드(byte range lock code)내에서 국부적인 토큰 상태의 복사를 보존할 필요가 없음을 인식하게 된다.

본 발명은 획득된 이후이지만 로크되기 이전에, 토큰이 또 다른 노드에 의해 취소되는 라이브로크(livelock) 상태를 제거한다. 다른 노드는 토큰을 획득하고, 로크되기 이전에 이는 다시 스틸(steal)된다. 이러한 핑퐁(ping-pong) 효과는 처리를 중단시킨다.

바이트 범위 로크 코드내에서 국부적인 토큰 상태의 복사를 보존할 필요가 없는 것의 결과는 이 정보가 이미 TM에 저장되므로, 프로그램에 필요한 비용이 줄어드는 것이다. API는 토큰이 이미 캐시되었나를 알아내도록 TM에 질문한다. 바이트 범위를 로크시킨 이후에는 토큰 존재에 대한 테스트 이후이지만 이를 로크시키기 이전에 취소가 일어나지 않았음을 확실하게 하도록 특수한 기계가 제공된다. 토큰은 그 사이에 취소되는 것이 가능하다. 이 경우에, 토큰은 획득되어 다시 시도된다.

파일 시스템 동작에 의해 사용되는 같은 바이트 범위 로크 코드는 또한 취소 콜백(revoke callback) 함수에 의해 사용된다. 그러나, 특수한 플래그(flag)가 이것이 취소를 위한 로크임을 나타낸다. 이는 코드를 보다 간결하게 만들고, 같은 로크 테이블의 사용을 허용한다.

바이트 범위를 로크시키기 위한 API는 그의 동작을 증진시키는 다양한 옵션을 지지한다: 비-블로킹(Non-blocking); 로컬-로크(Local-lock); 테스트(Test); 및 순차적(Sequential) 옵션. 비-블로킹 옵션은 비-블로킹 동작을 허용한다; 토큰을 갖지 않거나 충돌 로크가 유지되고 있으면, 로크 코드는 적절한 복귀 코드로 즉시 복귀된다.

로컬-로크 옵션은 비분포 동작을 허용한다; 전반적으로 로크시킬 필요는 없지만 노드내에서만 로크되면, 이 옵션이 사용될 수 있다.

테스트 옵션은 실제로 로크시키지 않고 바이트 범위가 로크될 수 있는가를 볼 수 있게 허용한다.

순차적 옵션은 순차적으로 억세스되는 파일을 판독(또는 기록)하도록 바이트 범위를 로크시킨다는 암시를 제공한다. 이 암시는 토큰이 필요로 되는 경우에 사용된다. 이 경우에, 실제로 필요한 것 보다 더 큰 토큰이 바람직하다(그렇지만, 요구되지는 않는다).

연결선(thread)에 의해 유지되는 다양한 로크를 추정하기 위해 특수한 설비가 이루어진다. 디버깅 유틸리티(debugging utility)는 현존하는 바이트 범위 로크와 그들을 유지하고 있는 연결선 번호를 덤프(dump) 처리한다. 또한, 로크 동작과 파일 억세스의 패턴을 이해하기 위한 통계가 보존된다.

성공적인 각 로크 동작에 대한 처리를 복귀시킴으로서, 로크 해제(unlock) 동작은 신속해지고, 탐색이나 룩업(lookup)을 요구하지 않는다.

현존하는 다양한 로크 모드의 카운터를 보존함으로서, 충돌 로크가 존재하는가를 점검하는 동작이 빠르다. 예를 들어, 활성화 공유-판독 로크 및 활성화 배타적-기록 로크의 수에 대한 카운터가 보존되면, 범위 오버랩에 대해 점검할 필요가 있는가를 알 수 있다. 예를 들어, 배타적-기록 로크가 없고 공유-판독 로크가 필요로 되면, 충돌이 없음을 알 수 있어, 단지 로크 테이블에서 빈 슬롯(slot)을 찾는 것만이 필요하다.

로크 코드는 제한되지 않은 수의 바이트 범위 로크 요구를 지지한다. 로크 테이블이 가득 차거나, 충돌 로크가 요구되는 경우에, 룩업을 원하는 연결선은 휴지 상태에 놓이고, 로크 해제될 때 부활된다.

본 발명의 해결법은 토큰 정보를 이중으로 하지 않으므로, 간결하고 효과적이다.

＆토큰 관리자 환경에서의 회복＆

다수의 프로세서가 임의의 순간에 파일 시스템의 다양한 부분으로 기록 및 판독하므로, 병렬 파일 시스템의 복잡성이 매우 커진다. 이 환경에서 무엇인가가 고장날 때 일어난 것이 요구될 수 있다. 본 발명은 이 환경에서의 회복을 제공한다. 제1 회복 기계는 노드가 고장나고 메타데이터가 고장시 갱신되고 있을 때 일어난 것에 관련된다. 이는 토큰 상태의 회복, 메타데이터 로그(log)의 재생, 및 확고한 동작 순서를 포함하는 기술을 설명한다.

＆병렬 파일 시스템 회복 모델＆

PO997062-PO8970059

본 발명의 회복 모델은 본 발명의 공유 디스크 파일 시스템에 적용될 수 있다. 디스크는 다수의 디스크 케이블(예를 들면, scsi 또는 ssa)을 통하거나 저장기에 부착된 네트워크의 형태를 통해 부착된다. 각 프로세서는 디스크에 독립적으로 억세스하고, 분포된 로크 관리자를 사용해 데이터/메타데이터 일관성이 유지된다. 메타데이터 갱신은 고장시 파일 시스템 스캔의 필요성을 방지하도록 각 프로세서에 의해 독립적으로 로그된다.

어려운 문제점은 프로세서가 고장날 수 있다는 점이다(소프트웨어나 하드웨어). 이러한 고장은 프로세서의 실제적인 완전 손실이나 로크 관리 프로토콜(lock management protocol)에 관여하는 통신 기능의 손실의 형태를 취할 수 있다. 이러한 고장 동안에, 고장난 프로세서는 공유 디스크의 특정 영역을 수정하도록 허용하는 로크를 유지할 수 있다. 로크 관리자의 형태에 의존해, 부가적인 로크를 획득할 수도 있다. 고장난 프로세서는 결국 그의 상태를 인식하지만, 이를 행해야 하는 시간은 고장난 프로세서에서 무엇이 진행중인가에 의존하므로 외부적으로 알 수 없다.

상기 목적은 생존하는 모든 프로세서가 공유 디스크를 사용해 안전하게 실행되도록 허용하는 것과 고장된 프로세서가 또한 공지되는 상태로 복귀되자마자 애플리케이션을 사용하는 것을 지지하도록 허용하는 것이다.

본 발명의 회복 모델은 다음의 개념을 실행한다:

- 모든 프로세서에서의 처리를 모니터하고 프로세서 및 통신 고장을 검출하는 그룹 모니터링 서비스(group monitoring service)(피닉스(Phoenix) 그룹 서비스와 같은). 이 서비스는 "처리 그룹"과 결합함으로서 제공된다; 한 그룹의 모든 멤버에게는 멤버가 고장날 때나 한 그룹과 결합하도록 새로운 처리가 시도할 때가 통지된다. 시작 시간 동안, 프로세서는 "처리 그룹"과 결합하여야 한다.

- 분포된 로킹(distributed locking). 모든 디스크 억세스는 분포된 로킹을 통하여 그룹 멤버간에 조정된다:

- 한 멤버는 공유 디스크상에서 특정한 부분의 데이터/메타데이터를판독하거나 변경하기 이전에 로크를 얻어야 한다.

- 한 그룹 멤버는 로크 조정기(lock coordinator)이다; 로크 조정기는 어느 로크가 어느 노드에 유지될 수 있는가를 알 수 있다.

- 정족수(quorum). 시작 동안과 통신 고장이 있을 때는 하나 이상의 그룹이 형성되는 것이 가능하다. 이는 다른 그룹내의 로크 조정기가 충돌 로킹 결정을 하는 것에 이르게 할 수 있다. 이를 방지하기 위해, "처리 그룹"의 멤버가 디스크를 억세스할 수 있는 처리기의 과반수 보다 작으면, 파일 시스템 동작이 허용되지 않는다.

- 로깅(logging). 고장 이후에 비일관성이 될 수 있는 모든 데이터/메타데이터 갱신이 로그된다. 각 프로세서는 자체 로그를 갖고 있지만, 로그는 고장난 경우에 모든 노드로 억세스가능하도록 공유 디스크상에 저장된다.

- 펜싱(fencing). 소정의 프로세서로부터 소정의 디스크로의 억세스를 저지하는 기능이 있어야 한다.

- 장벽(barrier). 회복 단계는 본래 순차적이고 모든 노드에서 실행되는 특정한 회복 단계를 요구하므로, 다음 단계를 어디서든 실행하기 이전에 모든 노드에서 단계가 완료되는 것을 보장하는데 "장벽"이 사용된다.

본 발명의 회복 모델은 하드웨어 로킹 없이 노드 고장을 처리한다. 각 파일 시스템의 예는 "처리 그룹"의 활성화 멤버가 될 수 있을 때에만 동작된다. 실질적인 프로세서 고장이나 통신 무능력으로 나타내질 수 있는 프로세서의 고장이 검출될 때, 이는 그룹 모니터링 서비스에 의해 남아있는 모든 그룹 멤버에 알려진다. 고장난 프로세서의 회복은 생존하는 그룹 멤버간에 장벽 동기화 프로토콜(barrier synchronization protocol)을 사용해 이후 설명될 회복 단계를 실행함으로서 행해진다. 일부 회복 단계는 한 프로세서에서 행해지므로, 이들 단계를 행하기 위해 파일 시스템 조정기가 선택된다.

- 생존하는 모든 프로세서는 고장난 프로세서로의 통신을 종료한다.

- 파일 시스템은 고장난 처리기를 둘러막는다(fence). 이는 디스크 서브시스템이 고장된 프로세서로부터 디스크 요구를 받는 것을 중단시키게 한다. 고장난 프로세서는 통신 고장을 아직 검출하지 않았더라도 공유 디스크를 억세스할 수 없다.

- 필요한 경우, 다음 장벽은 로크 상태의 회복이다. 파일 시스템 조정기는 이를 로크 조정기에 알린다. 로크 조정기는 고장시 고장난 프로세서에 의해 유지되는 로크를 부여하는 것을 중지시킨다. 이는 다른 노드가 고장난 노드에 의한 일관되지 않은 상태에서 남겨질 수 있는 데이터를 억세스하는 것을 방지한다. 고장난 프로세서가 로크 조정기이면, 생존하는 프로세서로부터 캐시된 로크 상태 정보를 수집함으로서 새로운 로크 상태가 다른 조정기에 의해 계산된다. 이 단계가 필요하지 않으면, 중지된 로크에 의해 포함되지 않는 데이터에 대한 정상적인 파일 시스템 동작이 생존하는 노드에서 재개된다.

- 제3 장벽은 파일 시스템 조정기에 의해 고장난 노드의 로그를 재생하는 것이다. 이 재생은 고장된 프로세서가 디스크로부터 둘러막혀 있고 생존하는 프로세서가 저지된 블록을 부여하지 않음을 알도록 행해진다. 이 단계가 완료될 때, 디스크상의 데이터는 일관되고 로크가 해제될 수 있다. 이 장벽으로부터의 해제는 생존하는 모든 프로세서에서 성공적인 회복과 정상적인 동작이 재개될 수 있음을 의미한다.

- 회복 동안에 검출된 프로세서 고장은 처음부터 시작함으로서 처리된다. 각각의 회복 단계는 이들이 멱등(idempotent)인 방법으로 실행되므로, 회복 프로토콜이 부가적인 고장 없이 완료될 때까지 이들 단계가 여러번 실행되면, 하자가 생기지 않게 된다.

상기의 회복 단계는 한 파일 시스템에 대한 회복을 설명한 것이고, 하나 이상의 파일 시스템이 설치되어 있으면, 각 단계에서의 모든 회복 작용은 모든 파일 시스템에 적용된다.

노드 회복을 처리하기 위해, 고장난 프로세서는 가능한한 빨리 그룹과 재결합하도록 시도한다. 고장 회복이 아직까지 진행중이면, 고장 회복 프로토콜이 완료될 때까지 "처리 그룹"과 결합할 수 없다. 고장난 노드가 현존하는 그룹과 결합하거나 정족수를 대기하는 그룹과 결합하는 2가지의 가능한 경로가 있다. 정족수를 대기하는 그룹과 결합하면, 정족수가 존재하자마자 로그 재생(log replay)이 일어난다(이때, 충돌 로크가 존재하지 않음을 알게 된다). 현존하는 그룹과 결합하면, 이는 자체를 둘러막지 않고 정상적인 파일 시스템 동작을 허용한다.

제2 회복 특성은 메타데이터 노드에 대한 요구와 회복의 교차 부분을 처리한다. 메타데이터 노드는 고장에 걸쳐서 보존될 필요가 있는 상태를 유지한다.

＆메타데이터 노드의 동기화 및 비동기화 전환＆

PO997075-PO8970069

본 발명의 병렬 파일 시스템은 파일 시스템을 구성하는 모든 디스크가 TCP/IP 네트워크나 다수의 프로세서가 상호작용하도록 허용하는 스위치와 같은 통신 네트워크에 분포되는 경우에 대량 병렬 기계나 클러스터(cluster)에서와 같이 동작되므로, 파일은 다수의 프로세서에 의해 억세스될 필요가 있고 독립적으로 억세스될 수 있다. 이 기능을 개발하기 위해, 파일은 판독 및 기록 모두를 위해 다수의 프로세서에 의해 공유되어야 한다.

분포된 파일 시스템에서 파일의 기록 공유에는 몇가지 문제점이 있다. 이들 중 하나는 제공된 메타데이터의 억세스와 갱신이다. 메타데이터 노드는 분포된 파일 시스템에서 메타데이터를 제어하는 기계이다. 파일을 억세스하는 모든 노드는 메타데이터 정보를 메타데이터 노드(또는 메타노드)에 기록 또는 판독할 필요가 있다.

메타데이터 노드는 파일의 메타데이터에 대한 정보를 유지하고, 파일을 억세스하는 모든 노드와 디스크 사이에서 스마트 캐시(smart cache)로 동작한다. 메타데이터 노드(또는 메타노드)가 이 기능을 만족시키는 것을 중단하는 상황이 있다. 매끄러운 동작 및 회복을 가능하게 하기 위해, 이러한 상황은 처리될 필요가 있다. 메타노드를 억세스하는데 사용되는 노드는 수월한 방법으로 새로운 메타노드를 선택할 필요가 있다.

여기서는 메타노드 전환을 트리거(trigger)할 수 있는 상황과 전환을 가능하게 하기 위해 선택되는 방법을 설명한다.

메타노드가 메타노드로 동작되는 것을 중단하는 상황은 3가지가 있다; 처음 2개는 비동기화이다. 즉, 다른 노드가 이를 즉시 알지 못한다. 세 번째 것은 동기화이다. 즉, 모든 노드가 전환을 알고 있다.

1. 메타노드가 고장난다(파손된다).

2. 메타노드가 파일을 닫거나 캐시로부터 이를 플러쉬(flush)한다;

3. 또 다른 노드가 메타노드로 될 필요가 있다.

이러한 모든 경우에서, 확실한 전환이 일어나는 것을 보장할 필요가 있다. 비동기화 동작에서, 오래된 메타노드를 억세스하도록 시도하는 제1 노드는 에러를 검출한다; 노드가 고장난 경우에서는 통신 에러가 얻어지고, 오래된 노드가 더 이상 메타노드가 아닌 것으로 결정되는 경우에는 오래된 메타노드로부터 적절한 에러가 얻어진다. 이러한 두 경우 모두에서, 노드는 TM으로부터 적절한 토큰을 요구함으로서 메타노드가 되도록 시도한다. 다른 메타노드가 없으면(오래된 메타노드를 억세스하는 것이 처음인 경우), 노드는 새로운 메타노드가 된다. 오래된 메타노드를 이어서 억세스하도록 시도하는 다른 노드는 또한 같은 처리를 겪지만, 적절한 토큰을 얻지 못한다. 토큰 관리자에 질문함으로서 새로운 메타노드가 드러나게 된다. 그래서, 모든 노드는 결국 새로운 메타노드가 되는 것이나 메타노드가 바뀌는 것을 발견한다. 어느 경우에서도 적절한 작용이 취해진다. 노드가 메타노드로 되면, 이는 디스크로부터 가장 최근의 메타데이터를 판독한다. 노드의 메타노드가 바뀌면, 이들을 플러쉬하기 이전에 고장난 오래된 메타노드가 디스크로 갱신되는 것이 가능하므로, 노드는 자체 메타데이터의 갱신을 새로운 메타노드에 재전달한다. 이러한 각 갱신에 대한 버전수를 사용함으로서, 모든 노드는 디스크상에 어떤 갱신이 있는가 및 어느 것이 새로운 메타노드로 재전달되어야 하는가를 알게 된다.

노드는 메타노드로 되도록 시도하는 동안 파손되므로, 메타노드로의 억세스를 포함하는 모든 동작은 다음의 윤곽을 갖는다.

〈표 7〉

retry:

if(I_am_metanode) then

Do this_and_that

else {

err1 = send_message_to_the_metanode; // 그래서, 메타노드는

// "this_and_that"을 행한다.

if(err1 == METANODE_IS_DEAD ∥ err1 == METANODE_NOT_ANY_MORE){

err2 = try_to_become_metanode;

if(err2 == OK) then // 메타노드가 된다.

read_metedata_from_disk ( 및 메타노드가 될 때 행하여진

다른 요소)

else // 다른 어떤 것이 메타노드로 된다.

// find_out_the_new_metanode,

and_send_it_information_that_is_not_yet_on_disk

// 메타데이터가 변화된다; 두 경우 모두, 원래 동작이 재시도된다.

}

goto retry

}

메타노드의 동적 전환을 위해 본 발명에서 설명된 시스템은 유일한 것이고, 본 발명의 특별한 해결법은 파일 작용을 근거로 새로운 메타노드를 선택하도록 다른 용도를 갖는 서브시스템(토큰 관리자)를 개발하는 이점을 갖는다. 모든 동작이 본래의 "재시도" 기계를 포함하고, 모든 노드가 메타노드로 작용할 수 있으므로, 메타노드가 결국 선택되고 전환이 결국 동적으로 일어나는 것을 보장하게 된다.

모든 노드에 보존되는 정보는 메타노드가 고장나더라도, 파일의 일관된 관찰이 이용가능하도록 회복 처리가 모든 정보를 재구성하는 것을 보장한다.

＆할당량의 할당＆

PO997066-PO8070073

다음에는 이 공유 디스크 파일 시스템에서 할당량(quotas)의 할당을 포함하는 본 발명의 개선이 논의된다. 기본적인 차이는 할당량이 한 세트의 노드에 걸쳐 엄격하게 유지되어야 하는 점이다. 이들은 중앙 서버(central server)에서 유지되는 것으로 생각될 수 있지만, 중앙 서버는 각 데이터의 새로운 기록이 데이터를 기록하기 이전에 단일 서버에 허락을 요구할 때 병목 지점이 되기 때문에, 이는 알맞은 해결법이 아님을 알 수 있다. 여기서는 할당량 보유 사용자 대신에 파일 시스템으로 활발히 기록하고 있는 컴퓨터에 할당량의 몫을 할당하는 본 발명의 방법이 설명된다. 이후에는 고장시 이러한 몫을 회복하는 방법을 다룬다.

다양한 디스크상의 파일에 활발히 기록 및 판독하기 위해 파일 시스템을 구성하는 모든 디스크가 다수의 프로세서에 의해 독립적으로 억세스될 수 있는 병렬 파일 시스템에서, 디스크의 섹터(sector)수는 각 프로세서가 파일을 생성할 때 파일에 지정되어야 한다. 특정 사용자가 소유하는 파일에 할당된 섹터는 이 사용자 또는 사용자 그룹이 얼마나 많은 디스크 공간을 사용하도록 허용되는지를 지정하는 할당량에 의해 제한된다. 문제는 사용자가 동시에 다수의 프로세서에서 실행하고 같은 할당량을 채우는 것이다. 새로운 디스크 블록의 할당을 집중시키는 것은 대량 병렬 처리 시스템의 사용 속도를 저하시킨다.

본 발명은 각 노드에 할당량의 몫을 할당하고, 요구를 근거로 이를 재할당하고, 또한 고장에 걸쳐 이를 회복하는 시스템을 실행한다. 본 발명의 해결법은 설명되고 있는 대량 병렬 계산 환경이나 다수의 컴퓨터의 다른 환경에서 파일 시스템마다 디스크 블록 할당량과 이노드(inode)를 관리하는 방법이다. 작업은 파일 시스템내에서 데이터에 대해 활발히 작업하고 있는 파일 시스템에 대한 노드당 할당량 클라이언트와 파일 시스템에 대한 하나의 할당량 서버 사이에서 나뉜다.

할당량 제한치는 사용자가 이노드 또는 파일 시스템 공간을 할당하도록 허용된 한계값이다. 본문에서는 사용자에 허용된 공간량 및 이노드의 수가 할당량이라 칭하여진다. 국부적인 몫은 할당량 서버와의 상호작용 없이 사용자 대신에 할당량 클라이언트에 할당될 수 있는 공간량이다.

서버는 완전한 MPP 시스템에서 모든 사용자에 대해 축적된 사용과 할당량 제한치를 포함하는 디스크 상주 파일을 유지한다. 이는 모든 프로세서에 대한 이 파일의 모든 판독 및 갱신을 실행하는 서버에서만 이용가능하다. 그래서, 서버만이 아직까지 이용가능한 할당 및 할당량의 사용을 전체적으로 관찰한다.

전반적인 할당량 관리에 관련된 모든 작용은 할당량 서버에서 실행된다. 제한치에서의 변화, 국부적인 몫의 할당, 및 현재 상태의 디스플레이는 할당량 서버와의 상호작용을 요구한다. 할당량 클라이언트는 국부적인 몫에 의해 허용되는 바와 같이 파일 시스템 할당을 변화시키고, 이 몫의 사용을 근거로 서버를 주기적으로 갱신한다. 서버는 또 다른 클라이언트로부터의 몫에 대한 요구를 만족시키도록 클라이언트로부터의 몫을 취소할 수 있다.

할당량 클라이언트는 국부적인 몫을 0으로 시작한다. 프로세서에서 애플리케이션이 새로운 파일 시스템 데이터를 생성하도록 시도하는 경우에만, 사용자에 대한 국부적인 몫이 요구된다. 클라이언트가 충분한 국부적인 몫을 수신하는 경우에만, 애플리케이션 요구가 만족된다; 그렇지 않으면, 애플리케이션은 무시된다. 할당량 클라이언트는 국부적인 몫과 그 몫 중 얼마나 많은 양이 사용되었나에 대한 기록을 유지한다. 디스크 공간을 해제하는 애플리케이션은 사용자에 대한 국부적인 몫을 증가시킨다. 할당량 클라이언트는 사용할 때 할당량 서버를 주기적으로 갱신하고, 애플리케이션 사용 패턴을 근거로 과도한 할당량 몫을 해제한다.

할당량 서버는 아직까지 이용가능한 할당량을 갖는 한, 즉 시스템의 광범위한 할당량 제한치를 넘지 않는 한, 국부적인 몫을 할당한다. 모든 할당량 제한치가 국부적인 몫으로 주어지면, 할당량 서버는 새로운 요구를 만족시키기 위해 국부적인 몫을 취소한다. 이는 클라이언트가 남아있는 몫을 계속 사용하는 것을 허용하도록 국부적인 몫의 일부를 취소함으로서 행해진다. 이들 요구가 더 강해지면, 애플리케이션 요구가 거절되게 하는 요구를 만족시키도록 할당량이 이용가능하지 않을 때까지 더 많은 부분을 취소한다.

이 방법에서의 어려움은 클라이언트와 서버 모두의 고장을 제공하여야 한다는 점이다. 클라이언트는 부분적으로 사용되는 국부적인 몫으로 고장날 수 있고, 서버는 클라이언트의 고장과 동시에 고장날 수 있다. 사용자는 할당된 할당량을 넘도록 허용되지 말아야 하고, 또한 이 공간량을 얻을 수 있도록 기대된다. 이는 할당량 할당의 "의심적(in-doubt)" 방법 사용을 요구한다. 할당량 서버가 국부적인 몫을 할당할 때마다, "의심적인 값"인 국부적인 몫의 합의 회복가능한 디스크상에 기록이 배치된다. 이는 서버가 정확한 정보를 갖지 않는 할당량 공간의 양을 나타낸다. 의심적인 공간은 사용자가 그의 제한치를 넘도록 허용할 위험성 없이는 재할당될 수 없다. 의심적인 값은 국부적인 몫의 사용을 나타내는 클라이언트로부터의 주기적인 메시지에 의해 갱신된다. 이 공간은 의심적인 값으로부터 사용되는 값으로 이동된다. 클라이언트에 의해 포기되는 공간은 또한 의심적인 값으로부터 감소된다. 한 사용자에게 이용가능한 전체 할당치는 그의 할당치 - 사용되도록 공지된 값 - 의심적인 값이다. 의심적인 값에 대한 모든 수정은 회복을 즉시 처리하도록 디스크에 강요된다.

클라이언트가 고장나면, 의심적인 저장량은 사용자에 의한 실제 저장 사용을 유효하게 하는 "할당량 점검(quota check)" 유틸리티 프로그램이 실행될 때까지 그 사용자에게 이용가능하지 않다. 의심적인 값의 일부는 사용자에 의한 실제 사용을 나타내지만; 일부는 임시적으로 손실된 잠재적인 사용을 나타낸다. 몫을 할당하는 알고리즘은 클라이언트에서의 새로운 디스크 저장 사용에 민감하고, 성능을 이유로 클라이언트에게 무엇이 곧 사용될 것인가를 제공하고 회복을 이유로 과도한 국부적인 몫을 제한하도록 시도한다. 이 방법은 할당량 점검 유틸리티가 실행될 때까지 의심적이지 않은 그의 할당량 일부에 대한 사용자의 계속적인 동작을 허용한다. 이는 또한 실행을 위한 디스크 블록의 병렬 할당을 허용한다.

할당량 서버가 고장날 때는 새로운 할당량 서버가 선택된다. 이는 디스크에 아직 기록되지 않은 변화 정보를 갖지 않는다. 이는 모든 국부적인 몫을 취소하고 응답을 근거로 의심적인 값을 갱신함으로서 이 정보를 발생시킨다. 서버 고장과 동시에 일어나는 클라이언트 고장은 할당량 점검 유틸리티가 실행될 때까지 결과적으로 블록을 손실시키게 됨을 주목한다. 이 알고리즘은 고장 이후 신속하게 의심적이지 않은 할당을 위해 할당량 시행이 정확시 실행되도록 허용한다.

병렬 시스템의 모든 노드에서 독립적으로 디스크 블록을 할당하는 병렬 파일 시스템을 알지 못한다. 이는 네트워크에 부착된 저장 시스템을 시도할 때까지 아무도 문제에 직면하지 않음을 의미한다.

본 발명은 성능을 이유로 저장을 평행하게 할당한다. 할당량 서버 해결법은 병목 현상 및 회복 문제를 갖게 된다. 사용자는 전체 병렬 처리 시스템에 걸쳐 디스크 저장 사용을 제어하기 원하기 때문에, 할당량을 가져야 한다. 해결법은 병렬 할당을 허용하고, 느려지게 되는 전체 할당량의 연속적인 로킹(locking)을 강요하지 않고, 또한 시기 적절한 형태로 처리 고장의 회복을 제공한다.

공유 디스크 모델의 디스크 연결을 사용하는 병렬 처리 시스템은 이러한 개발을 사용할 수 있다.

＆병렬 처리에서의 할당량 관리를 위한 국부적인 몫의 회복＆

PO997064-PO8970071

이 섹션은 이 환경에서 본 발명의 할당량 점검 유틸리티의 동작을 설명한다. 할당량 점검의 기능은 Unix 운영 환경에서 고장 이후에 할당량 파일을 고정시키기 위한 표준 유틸리티인 Quotachk와 유사하지만, Quotachk는 앞선 발명에서 설명된 바와 같이 할당량을 공유하는 다수의 노드로 실행되지 않는다. 본 발명의 개발은 모든 컴퓨터가 데이터를 억세스하는 것을 막지 않고 "Quotachk"의 실행을 허용한다.

이 섹션은 고장 이후에 몫이 사용/할당되는가 또는 아직까지 이용가능한가 여부를 알지 못할 때 몫을 회복하는 유틸리티/방법을 설명한다. 유틸리티는 파일 시스템에서 사용자가 디스크 공간을 할당 또는 재할당하는 것을 중단시키지 않고 작업한다.

대량 병렬 계산 환경에서 파일 시스템마다 디스크 블록 할당량과 이노드(inode)를 관리하기 위해, 작업은 파일 시스템내에서 데이터에 대해 활발히 작업하고 있는 파일 시스템에 대한 노드당 할당량 클라이언트와 파일 시스템에 대한 하나의 할당량 서버 사이에서 나뉜다.

할당량 제한치는 사용자가 이노드 또는 파일 시스템 공간을 할당하도록 허용된 한계값이다. 본문에서는 사용자에 허용된 공간량 및 이노드의 수가 할당량이라 칭하여진다. 국부적인 몫은 할당량 서버와의 상호작용 없이 사용자 대신에 할당량 클라이언트에 할당될 수 있는 공간량이다.

서버는 완전한 MPP 시스템에서 모든 사용자에 대해 할당량 제한치, 축적된 사용, 및 "의심적인 값"을 포함하는 디스크 상주 파일을 유지한다. "의심적인 값"은 서버가 정확한 정보를 갖지 않는 할당량 공간의 양을 나타낸다. 의심적인 공간은 사용자가 그의 제한치를 넘도록 허용할 위험성 없이는 재할당될 수 없다. 의심적인 값의 일부는 사용자에 의한 실제 사용을 나타내지만; 일부는 임시적으로 손실된 잠재적인 사용을 나타낸다.

여기서 설명된 해결법은 "의심적인 값"으로부터 국부적인 몫을 회복하여, 사용되지 않은, 임시적으로 손실된 할당량이 다시 이용가능하게 되는 방법이다. 이 기계(이후, 할당량 점검기라 칭하여지는)는 디스크 공간 및 이노드의 할당 및 재할당을 중단시키지 않고 활성화 파일 시스템에서 작업한다.

할당량 점검기는 할당량 서버에서 모든 할당량 기록의 섀도 복사(shadow copy)를 생성하고, 파일 이노드 정보에서 발견된 할당량 사용을 거기에 축적한다. 할당량 점검기가 이노드를 스캔하고 있는 동안, 할당 및 재할당에서의 모든 변화는 원래 할당량 기록과 할당량 서버에서의 섀도 기록에서 주목된다. 현재 할당량 점검기 위치(즉, 현재 판독되는 이노드) 전후에서의 할당량 사용 갱신은 다르게 다루어져야 한다. 현재 할당량 점검기 위치 이후(이미 점검된 이노드)에서의 할당 변화는 원래 할당량 기록과 섀도 기록에서 갱신되고; 현재 할당량 점검기 위치 이전(아직 점검되지 않은 이노드)에서의 할당 변화는 원래 할당량 기록에서만 갱신된다. 두 기록에서의 "의심적인 값"은 똑같이 갱신되므로, 할당량 클라이언트에서 국부적인 몫의 합은 할당량 점검이 종료된 이후에 정확하다.

할당량 클라이언트에게는 현재 할당량 점검기 위치가 알려지므로, 각각의 현재 할당량 점검기 위치의 범위를 넘어서 할당 또는 재할당되는 모든 할당량은 섀도 엔트리(shadow entry)에 수집될 수 있다. 할당량 클라이언트는 할당량 점검기가 이노드의 스캔을 종료하고 원래 할당량 및 섀도 할당량 엔트리를 병합하기 시작할 때 섀도 할당량 기록에 대해 수집된 변화를 할당량 서버에 전달한다.

섀도 기록의 "의심적인" 값은 모든 섀도 기록이 생성되고 모든 국부적인 몫이 클라이언트로부터 취소된 이후이지만, 할당량 점검기가 할당량 사용 정보를 위해 이노드의 스캔을 시작하기 이전에 서버에서 원래 할당량 기록의 "의심적인" 값과 함께 갱신된다(즉, 섀도 "의심적인" 값은 0으로 시작되고 정규의 "의심적인" 값은 손실된 할당량을 디스플레이한다). 할당량 점검의 종료시 섀도 할당량 기록과 정규 할당량 기록을 병합할 때, 섀도 기록의 "의심적인" 값은 정규 할당량 기록에 복사된다.

병렬 시스템의 모든 노드에서 독립적으로 디스크 블록을 할당하는 병렬 파일 시스템을 알지 못한다. 이는 네트워크에 부착된 저장 시스템을 시도할 때까지 아무도 문제에 직면하지 않음을 의미한다.

본 발명은 성능을 이유로 저장을 평행하게 할당하여 병목 현상 및 회복 문제를 갖는 단일 서버 해결법을 피한다. 사용자는 전체 병렬 처리 시스템에 걸쳐 디스크 저장 사용을 제어하기 원하기 때문에, 할당량을 가져야 한다. 해결법은 병렬 할당을 허용하고, 느려지게 되는 전체 할당량의 연속적인 로킹(locking)을 강요하지 않고, 또한 시기 적절한 형태로 처리 고장의 회복을 제공한다.

본 발명의 시스템에서, 토큰(token)은 메타데이터 노드 선택 및 식별하고 본 발명은 파일 크기를 제어할뿐만 아니라, 파일 억세스 패턴및 바이트 범위 토큰 인터페이스를 사용한 바이트 범위 로크(lock) 알고리즘을 사용하여 바이트 범위 토큰을 스마트 캐싱(smart caching)하기 위해 토큰 모드를 개선하였다. 로킹(locking) 기술은 공유 디스크의 관리에 참여하는 컴퓨터가 이용가능하지 않거나 고장날때 파일 시스템 회복에서 또한 사용되는 토큰 관리자의 오버헤드(overhead)를 줄인다. 메타데이터 노드의 동기화 및 비동기화 전환은 수정되었던 메타데이터의 정정과 그 파일에 대한 메타데이타 노드가될 새로운 노드를 위해 발생한다. 로크(lock)는 사용자 대신에 새로운 블록을 할당하기 위해 항상 요구되지는 않는다. 본 발명은 할당량 관리(quota management)를 위해 회복가능한 국부적인 몫을 제공한다. 각 파일 시스템에는 할당량 서버(quota server)와 할당량 클라이언트(quota client)이 제공되고, 할당량 점검 유틸리티(quotacheck utility)는 할당량의 사용을 요구하는 다른 애플리케이션(application)에 최소의 간섭을 갖는 병렬 환경을 허용한다.

Claims (110)

1. 다수의 컴퓨터 노드(node) - 각각의 노드는 자체의 운영 체계 인스턴스를 갖추고 네트워크에 부착된 공유 디스크에 상주하는 파일에 병렬 데이터 공유 억세스하도록 연결됨-에서 실행되는 다수의 파일을 위한 공유 디스크 파일 시스템(shared disk file system)을 갖는 컴퓨터 시스템에서,

   파일을 억세스하기 위해 노드에 의해 요구되는 토큰을 동작에 대해 부여하기 위해 토큰 관리자(token manager)를 제공하고,

   토큰을 수신한 후에, 노드는 상기 토큰을 로킹(locking)하고, 상기 동작을 수행한 후에 상기 토큰을 로킹 해제(unlocking)하도록 진행하며, 상기 노드의 로킹 및 로킹 해제는 애플리케이션 프로그램 인터페이스(Application Program Interface, API)를 통해 실행되고, 제1 로킹 API는 바이트 범위를 로킹하기 위한 것이고, 제2 로킹 해제 API는 바이트 범위를 로킹 해제하기 위한 것이며,

   제3 콜백(callback) API 함수는 토큰 관리자에 의해 호출되는 방법.
2. 제1항에 있어서,

   상기 토큰 관리자는 3개의 API, 즉 바이트 범위 토큰을 획득하기 위해 호출되는 제1 획득 API, 호출된 노드에서의 토큰을 또다른 노드가 필요로 할 때마다 토큰 관리자가 호출하는 바이트 범위의 콜백 함수를 위한 제2 취소 API, 및 또 다른 노드의 요구에 따라 바이트 범위가 토큰 관리자에 해제될 때의 제3 API를 제공하는 방법.
3. 제2항에 있어서,

   테스트 바이트 범위 함수(test byte range function)는 요구된 토큰이 국부적인 노드에 존재하는지를 토큰 관리자에게 묻는 방법.
4. 제1항에 있어서,

   전체 다중노드 시스템에서 현존하는 충돌 범위와 상기 요구를 비교하고 또 다른 컴퓨터로부터의 토큰 취소를 요구하지 않을 가능성이 가장 큰 바이트 범위를 부여하기 위해 지정된 바이트 범위에 대해 토큰 요구가 검사되는 방법.
5. 제1항에 있어서,

   다수의 토큰 획득 및 취소는 로킹(locking)과 병행하여 처리되는 방법.
6. 제1항에 있어서,

   순차 번호는 동일한 바이트 범위에 대한 획득 및 취소를 처리하기 위해 소정의 바이트 범위에 사용되는 방법.
7. 제1항에 있어서,

   카운터와 비-블로킹(non-blocking) 로크 호출은 다른 로크를 유지하고 있는 동안 토큰을 얻기 위해 사용되는 방법.
8. 다수의 컴퓨터 노드(node) - 각각의 노드는 자체의 운영 체계 인스턴스(instance of an operating system)를 갖추고 네트워크에 부착된 공유 디스크에 상주하는 파일에 병렬 데이터 공유 억세스하기 위해 연결됨 - 에서 실행되는 다수의 파일을 위한 공유 디스크 파일 시스템(shared disk file system)을 갖는 컴퓨터 시스템에서,

   상기 시스템이 파일 억세스 패턴에 대한 토큰(token)을 캐시(cache)하고, 한 파일 내의 다른 영역에 대한 억세스를 직렬화함으로써, 한 파일 내의 같은 영역이 상기 시스템의 다수의 컴퓨터 노드에 의해 억세스될 수 있는 방법.
9. 제8항에 있어서,

   요구는 동작(operataion)에 의해 요구되는 최소 범위인 바이트 범위를 조사(probe)함으로써 호환가능한(compatible) 토큰이 노드상에 존재하는지를 판단하는 토큰 관리자에게 먼저 질의하는 방법.
10. 제9항에 있어서,

    필요시되는 토큰이 요구하는 노드에서 국부적으로 이용가능하면, 이것은 로크(lock)되고 토큰 작용(token activity)은 더 이상 발생하지 않는 방법.
11. 제9항에 있어서,

    필요시되는 토큰이 요구하는 노드에서 국부적으로 이용가능하지 않으면, 토큰은 상기 토큰 관리자로부터 요구되고, 요구되는 범위는 파일 동작의 길이 및 오프셋(offset)을 근거로 계산되는 방법.
12. 제11항에 있어서,

    상기 파일 억세스 패턴이 랜덤할 때, 승인되는 소정의 범위(the desired range granted)는 상기 요구되는 범위와 동일해지지만, 파일이 순차적으로 억세스될 때, 소정의 범위는 상기 요구되는 범위로부터 시작되어 무한대를 나타내는 값에서 끝나는 방법.
13. 제9항에 있어서,

    상기 요구는 노드가 또 다른 노드에서의 토큰에 대한 요구와 충돌하는 토큰을 갖고 있는지를 판단하는 상기 토큰 관리자에게 먼저 질의하고, 대답이 긍정인 경우에, 상기 토큰 관리자는 다른 노드에 의해 유지되는 토큰의 취소를 요구하는 방법.
14. 제13항에 있어서,

    상기 취소 요구는 토큰을 요구한 노드의 요구된 소정의 범위를 포함하는 방법.
15. 제13항에 있어서,

    요구가 순차적인 억세스에 적절한 소정의 범위를 가지면, 토큰을 유지하는 노드는 그 파일로의 억세스를 조사하여 최소 오프셋을 계산하고, 상기 계산된 최소 오프셋이 요구된 범위보다 더 크면, 승인되는 범위는 상기 계산된 최소 오프셋으로 늘여지는(stretch) 방법.
16. 다수의 컴퓨터 - 각각의 컴퓨터는 자체의 운영 체계 인스턴스(instance of an operating system)를 갖추고 네트워크에 부착된 공유 디스크에 상주하는 파일에 병렬 데이터 공유 억세스하기 위해 연결됨- 에서 실행되는 공유 디스크 파일 시스템(shared disk file system)을 갖는 컴퓨터 시스템에서,

    부착된 공유 디스크에 독립적인 억세스를 제공하면서,

    분산형 토큰 관리자 및 록킹 메커니즘(distributed token manager and locking mechanism)을 이용함으로써 각 파일에 대한 일관성을 유지하는 단계와

    메타데이터(metadata) 내의 파일에 대한 메타데이터를 제공하면서,

    노드가 고장나면 파일 시스템 스캔(scan)의 필요성을 방지하기 위해 각 컴퓨터 노드에 의해 독립적으로 메타데이터 업데이트를 로깅(logging)하는 단계

    를 포함하는 방법.
17. 제16항에 있어서,

    상기 메타데이터는 토큰 상태 및 메타데이터 로그(log)를 포함하고,

    그룹 모니터링 서비스(group monitoring service)는 노드들의 프로세스 그룹 (a process group of nodes)을 모니터하고, 상기 노드들의 프로세스 그룹 모두에 대해, 노드 및 노드간의 통신에서 고장을 검출하고 프로세스가 실패하거나 새로운 프로세스가 상기 노드들의 프로세스 그룹에 참가하고자 할 때 상기 노드들의 프로세스 그룹 구성원에게 알리기 위한 처리를 수행하는 방법.
18. 제17항에 있어서,

    그룹 구성원간의 디스크 억세스를 분산형 록킹 - 구성원은 공유 디스크상의 데이터 또는 메타데이터의 특정 부분을 판독하거나 변경시키기 이전에 로크(lock)를 얻어야 함 -을 통해 조정하는 단계와,

    어느 로크가 어느 노드에 대해 유지되고 있는지를 판단하기 위해 하나의 그룹 구성원을 지정된 로크 조정자로 지정하는 단계

    를 포함하는 방법.
19. 제18항에 있어서,

    디스크를 억세스할 수 있는 프로세서 중 과반수 이하가 프로세스 그룹의 구성원일 때, 파일 시스템 동작을 중지하고 또한 부정하는 방법.
20. 제19항에 있어서,

    각 컴퓨터 노드에서 메타데이터 업데이트를 로깅(logging)하는 단계와

    고장이 발생한 경우에 모든 노드에서 억세스가능하도록 로그(log)를 공유 디스크상에 저장하는 단계

    를 포함하는 방법.
21. 제16항에 있어서,

    고장 이벤트(failure event)가 발생하면 파일 시스템 조정자가 소정의 노드로부터 소정의 디스크로의 억세스를 저지하기 위해 인에이블(enable)되는 단계를 포함하는 방법.
22. 제21항에 있어서,

    고장 이벤트 이후 회복을 개시한 이후에, 회복 단계는 파일 시스템 내의 어디에서든 다음 단계가 인에이블되기 이전에 모든 노드에서 실행되는 방법.
23. 제21항에 있어서,

    고장난 프로세서로의 통신을 종료하는 단계와

    파일 시스템 조정기로써 상기 고장난 프로세서를 둘러막는(fencing) 단계를 포함하여, 고장난 노드가 통신 고장을 검출하지 않았더라도 고장 노드로부터의 디스크 요구를 상기 공유 디스크 시스템이 받아들이는 것을 중단하여 공유 디스크로의 액세스를 거절하는 방법.
24. 제23항에 있어서,

    상기 파일 시스템 조정기가 토큰 관리자 및 로킹 메커니즘의 로크 조정자에게 알림으로써 상기 로크 조정자는 고장시 고장난 노드에 의해 유지되는 로크를 승인하는 것을 중지하여 필요한 경우에 로크 상태를 회복하는 단계를 포함하는 방법.
25. 제24항에 있어서,

    상기 파일 시스템 조정기에 의해 상기 고장난 노드의 메타데이터 로그를 재생하는 방법.
26. 제16항에 있어서,

    상기 컴퓨터 시스템의 각 파일 시스템에 대해 회복 기능을 반복함으로써, 상기 컴퓨터 시스템의 각 파일 시스템에 대한 노드의 고장으로부터 회복하는 단계를 포함하는 방법.
27. 제16항에 있어서,

    상기 컴퓨터 시스템의 각 파일 시스템에 대한 노드의 고장으로부터 회복하는 단계를 포함하는 방법.
28. 다수의 컴퓨터 노드 - 각각의 노드는 자체의 운영 시스템 인스턴스(instance)를 갖추고 네트워크에 부착된 공유 디스크에 상주하는 파일에 병렬 데이터 공유 억세스(parallel data sharing access)하도록 연결됨 - 상에 실행되는 공유 디스크 파일 시스템(shared disk file system)을 갖는 컴퓨터 시스템에서, 다수의 디스크 상의 파일에 활발히 기록하고 판독하는 다수의 프로세서에 의해 파일이 독립적으로 억세스될 수 있는 경우에 사용하는 방법에 있어서,

    파일 시스템의 모든 노드상에서 독립적으로 디스크 블록(disk block)을 할당하는 단계와,

    상기 다수의 컴퓨터 노드에 의해 다양한 디스크 상에서 활발히 기록되고 판독되는 파일을 생성하는 각 노드 상의 파일에 디스크 섹터(sectors of disk)를 할당하는 단계와,

    다수의 노드들이 할당량(quotas) - 상기 할당량은 상기 파일 시스템을 위해 사용자에게 할당된 이노드(inodes)의 수와 공간량을 제공함 -공유할 수 있도록 노드들에 할당량의 몫을 할당하는 단계와,

    할당량(quota)이 파일 시스템에서 사용자에게 할당된 공간량과 이노드(inode)의 수를 제공하는 것일 때, 할당량의 몫을 노드에 할당하여, 그에 의해 다수의 노드가 할당량을 공유하고, 또한

    상기 다수의 컴퓨터 노드 중에 노드 고장이 있을 때 할당량 파일을 고정시키기 위한 할당량 점검 유틸리티(quota check utility)를 제공하는 단계

    를 포함하는 방법.
29. 제28항에 있어서,

    상기 할당량 점검 유틸리티는 사용자가 상기 파일 시스템 내의 디스크 공간을 할당 또는 할당 해제하는 것을 방해하지 않고 고장 이후에 디스크 공간몫이 사용/할당되어 있는지 또는 아직까지 이용가능지의 여부를 알지 못할 때, 상기 디스크 공간몫을 회복하는 방법.
30. 제28항에 있어서,

    계산 환경에서 파일 시스템에 대한 디스크 블록 할당량과 이노드의 관리를 파일 시스템당 하나의 할당 서버와 상기 파일 시스템 내의 데이터에 대해 활발히 작업하고 있는 파일 시스템에 대한 노드당 할당 클라이언트(quota client)의 작업으로 나누는 단계를 포함하는 방법.
31. 제30항에 있어서,

    이노드나 파일 시스템 공간을 할당하는 것을 사용자에게 최대한 허용되는 한계값 제한치로 할당량을 제한하는 단계를 포함하며, 디스크 공간의 국부적인 몫(local share)은 상기 할당 클라이언트에 대한 할당 서버의 상호작용 없이 할당 클라이언트 상에서 사용자를 위해 할당될 수 있는 공간량인 방법.
32. 제31항에 있어서,

    전체적인 계산 환경에서 모든 사용자에 대해, 할당량 제한치, 축적된 사용도, 및 "의심적인 값(in-doubt value)"을 포함하는 디스크 상주 파일을 할당량 서버에 제공하는 단계를 포함하고, 상기 "의심적인 값"은 서버가 정확한 정보를 갖고 있지 않고 사용자가 그의 제한치를 넘도록 허용할 위험성 없이는 재할당될 수 없는 할당량 공간량을 나타내는 방법.
33. 제28항에 있어서,

    상기 할당량 점검 유틸리티로 할당량 서버상에서 모든 할당량 기록의 섀도 복사(shadow copy)를 생성하는 단계와, 파일 이노드 정보에서 발견된 할당량 사용을 섀도 복사에 축적하는 단계를 포함하는 방법.
34. 제33항에 있어서,

    상기 할당량 점검 유틸리티로 이노드를 스캔(scan)하여 원래 할당량 기록과 할당량 서버에서의 섀도 기록에서 할당 및 할당 해제의 모든 변화를 알아차리는 단계를 포함하는 방법.
35. 제33항에 있어서,

    상기 할당량 점검 유틸리티로 이노드를 스캔하여 할당의 모든 변화를 알아차리고 이노드 할당량 점검 위치 이후에 다르게 이루어진 할당 변화를 갱신 처리하는 단계를 포함하며, 현재 할당량 점검 위치 이후의 할당 변화는 원래 할당량 기록과 섀도 기록에서 갱신되고, 현재 할당량 점검 위치 이전의 할당 변화는 원래 할당량 기록에서만 갱신되는 반면, 전체적인 계산 환경에서의 모든 사용자에 대해 서버가 정확한 정보를 갖고 있지 않고 사용자가 그의 제한치를 넘도록 허용할 위험성 없이는 재할당될 수 없는 할당량 공간량을 나타내는 "의심적인 값"은 두 기록 모두에서 똑같이 갱신되므로, 할당량 클라이언트상에서의 국부적인 몫의 합은 할당량 점검이 종료된 이후에 정확해지는 방법.
36. 제35항에 있어서,

    상기 할당 클라이언트에게 현재 할당량 점검 위치를 알리고, 상기 할당 클라이언트가 각각의 현재 할당량 점검 위치의 범위를 넘어서 할당되거나 할당 해제되는 모든 할당량을 섀도 엔트리(shadow entry)에 수집할 수 있도록 하는 단계를 포함하는 방법.
37. 제36항에 있어서,

    할당량 점검이 이노드의 스캔을 종료하고 원래 할당량 및 섀도 할당량 엔트리를 병합하기 시작할 때 상기 할당량 클라이언트가 섀도 할당량 기록에 대해 수집된 변화를 할당량 서버에 전달하도록 하는 방법.
38. 제35항에 있어서,

    모든 섀도 기록이 생성되고 모든 국부적인 몫이 클라이언트로부터 취소된 이후이지만 할당량 점검이 할당량 사용 정보를 위해 이노드의 스캔을 시작하기 이전에 서버에서 원래 할당량 기록의 "의심적인" 값과 함께 섀도 기록의 "의심적인" 값을 갱신하는 단계와, 할당량 점검의 종료시 섀도 할당량 기록과 정규 할당량 기록을 병합할 때, 섀도 기록의 "의심적인" 값이 정규 할당량 기록에 복사되도록 하는 단계를 포함하는 방법.
39. 다수의 컴퓨터 노드가 동일한 데이터 객체를 갱신하거나 확대하는 파일 시스템을 위한 공유 디스크(shared disk) 환경을 갖는 컴퓨터 시스템에서,

    상기 공유 디스크 환경에서의 병렬 판독 및 기록을 위해 파일 메타데이터(metadata)를 관리하기 위한 메타데이터 노드(metadata node)를 공유 디스크 파일 시스템의 동작에 제공하는 단계를 포함하는 방법.
40. 제39항에 있어서,

    상기 메타데이터는 파일 크기, 파일 액세스와 수정 시간, 및 파일 데이터 블록(block)의 어드레스를 포함하는 방법.
41. 제39항에 있어서,

    상기 공유 디스크 환경 파일 시스템에서 한 파일에 대한 메타데이터 정보를 관리하기 위해 단일 노드가 그 파일에 대한 메타데이터 노드로 선택되는 방법.
42. 제41항에 있어서,

    파일에 대한 상기 메타데이터 노드는 메타데이터가 상주하는 하나 이상의 디스크에서 메타데이터의 모든 입출력 작용 처리를 담당하는 방법.
43. 제41항에 있어서,

    상기 다수의 컴퓨터 시스템의 다른 노드는 메타데이터 정보를 인출 또는 갱신하기 위해 상기 단일 메타데이터 노드를 통해 통신하는 방법.
44. 제41항에 있어서,

    상기 단일 메타데이터 노드는 상기 메타데이터에 의해 식별되는 연관된 파일 시스템을 액세스하는 제1 노드로서 선택되어, 상기 파일 시스템을 구성하는 모든 디스크가 다수의 프로세서에 의해 액세스되도록 허용하는 방법.
45. 제41항에 있어서,

    메타데이터의 사본을 메타데이터 노드에 캐시 저장(keeping cashed)함으로써 디스크상에 메타데이터를 반영하는 단계를 포함하는 방법.
46. 제45항에 있어서,

    다른 모든 노드는 그들이 메타노드(metanode)로부터 판독하고, 필요한 경우에 증가하는 메타데이터의 사본을 또한 캐시 저장하는 방법.
47. 제45항에 있어서,

    메타데이터의 각 원소는 주기적으로 갱신되도록 상기 메타데이터 노드에 의해 판단되는 자체 사용 패턴과 특수한 특성을 갖는 방법.
48. 제45항에 있어서,

    각 노드는 주기적으로 디스크에 직접 더티 데이터(dirty data)를 플러쉬(flush)하고 메타노드에 더티 데이터를 플러쉬하는 지연 싱크(deferred sync)에 대한 데몬(daemon)을 포함하는 운영 시스템 인스턴스(operating system instance)를 갖고, 상기 메타노드는 상기 싱크 데몬으로부터 신호를 받을 때 디스크에 더티 메타데이터를 플러쉬하는 방법.
49. 다수의 컴퓨터 노드 - 각각의 노드는 자체의 운영 시스템 인스턴스(instance)를 갖추고 네트워크에 부착된 공유 디스크에 상주하는 파일에 병렬 데이터 공유 억세스(parallel data sharing access)하도록 연결됨 - 상에 실행되는 공유 디스크 파일 시스템(shared disk file system)을 갖는 컴퓨터 시스템에서, 다수의 디스크 상의 파일에 활발히 기록하고 판독하는 다수의 프로세서에 의해 파일이 독립적으로 억세스될 수 있는 경우에 사용하는 방법에 있어서,

    파일을 생성하는 각 노드상의 파일에 디스크의 섹터(sector)를 지정하는 단계와,

    할당량(quota)을 보유하는 사용자를 위해 파일 시스템에 활발히 기록하고 있는 노드에 할당량의 몫을 할당하는 단계를 포함하며, 특정한 사용자에 의해 소유되는 파일에 할당된 섹터는 이 사용자 또는 사용자 그룹이 얼마나 많은 디스크 공간을 사용하도록 허용되는지를 지정하는 할당량에 의해 제한되는 방법.
50. 제49항에 있어서,

    할당량은 사용자에게 허용된 이노드(inode)의 수와 공간량인 방법.
51. 제49항에 있어서,

    상기 파일 시스템은 병렬 시스템의 모든 노드상에 디스크 블록(block) 및 이노드를 독립적으로 할당하는 방법.
52. 제49항에 있어서,

    상기 컴퓨터 시스템은 전체적인 파일 시스템 내의 모든 사용에 대해 할당량 제한치 및 축적된 사용도(accumulated usage)를 포함하는 디스크 상주 파일을 유지하는 할당량 서버(quota server)를 포함하고, 상기 서버는 상기 시스템의 모든 노드에 대해 할당량 제한치를 모두 판독하고 갱신하며, 파일 시스템당 하나의 할당량 서버와 파일 시스템에 대한 노드당 하나의 할당량 클라이언트(one quota client per node per file system) - 상기 클라이언트는 상기 파일 시스템으로 데이터에 대해 활발히 작업함 - 가 제공되는 방법.
53. 제52항에 있어서,

    전반적인 할당량 관리에 관련된 모든 작용은 상기 할당량 서버상에서 실행되고, 제한치에서의 변화, 국부적인 몫(local share)의 할당, 및 현재 상태의 디스플레이는 상기 할당량 서버와의 상호작용을 필요로 하는 방법.
54. 제53항에 있어서,

    할당량 클라이언트는 상기 파일 시스템에서 국부적인 몫에 의해 허용되는 할당량을 변화시키고, 이 몫의 사용을 근거로 하여 서버를 주기적으로 갱신하는 반면, 상기 할당량 서버는 또 다른 클라이언트로부터의 몫에 대한 요구를 만족시키도록 상기 클라이언트로부터의 몫을 취소할 수 있는 방법.
55. 제54항에 있어서,

    할당량 클라이언트는 국부적인 몫을 0으로 시작하고, 프로세서상의 애플리케이션(application)이 새로운 파일 시스템 데이터를 생성하는 것을 시도하는 경우에만, 사용자에 대한 국부적인 몫이 상기 할당량 서버로부터 요구되고, 또한 상기 클라이언트가 충분한 국부적인 몫을 수신하는 경우에만, 애플리케이션 요구가 만족되며, 그렇지 않으면 애플리케이션 요구는 무시되는 방법.
56. 제55항에 있어서,

    상기 할당량 클라이언트는 국부적인 몫과 그 몫 중 얼마나 많은 양이 사용되었는지에 대한 기록을 유지하고, 디스크 공간을 해제하는 애플리케이션은 사용자에 대한 국부적인 몫을 증가시키고, 상기 할당량 클라이언트는 사용시 할당량 서버를 주기적으로 갱신하여, 애플리케이션 사용 패턴을 근거로 하여 과도한 할당량 몫을 해제하는 방법.
57. 제56항에 있어서,

    상기 할당량 서버는 아직까지 이용가능한 할당량을 갖는 한, 국부적인 몫을 할당하고, 모든 할당량 제한치가 국부적인 몫으로서 주어지면, 상기 할당량 서버는 상기 국부적인 몫의 일부를 취소함으로써 새로운 요구를 만족시키기 위해 국부적인 몫을 취소하여서 애플리케이션 요구가 거절되게 하는 요구를 만족시키기 위한 할당량이 이용가능하지 않을 때까지 클라이언트가 남아있는 몫을 계속 사용하는 것을 허용하는 방법.
58. 제52항에 있어서,

    상기 할당량 서버가 국부적인 몫을 할당할 때마다, 서버가 정확한 정보를 갖고 있지 않고 사용자가 그의 제한치를 넘도록 허용할 위험성 없이는 재할당될 수 없는 할당량의 공간량을 나타내는 의심적인 값(in-doubt value)의 기록은 국부적인 몫의 합의 회복가능한 디스크상에 배치되는 방법.
59. 제58항에 있어서,

    클라이언트가 고장나면 의심적인 저장량은 사용자에 의한 실제 저장공간 사용을 유효하게 하는 유틸리티 프로그램(utility program)이 실행될 때까지 그 사용자에게 이용가능하지 않은 방법.
60. 제59항에 있어서,

    할당량 서버가 고장날 때, 디스크에 아직 기록되지 않은 변화 정보는 갖고 있지 않은 새로운 할당량 서버가 선택되고, 상기 새로운 할당량 서버는 모든 국부적인 몫을 취소하고 응답(replies)을 근거로 하여 의심적인 값을 갱신함으로써 이 정보를 발생시키는 방법.
61. 파일 데이터를 저장하고 메타데이터(metadata)를 포함하는 파일 구조를 갖는 파일 시스템을 갖춘 시스템에서,

    다수의 개별적인 컴퓨터 노드(node)에 의해 액세스될수 있는 하나 이상의 디스크에 상주하는 파일 구조를 파일 시스템 - 상기 파일 시스템은 개별적인 컴퓨터 노드에서 병렬로 실행될 수 있도록 다수의 부분으로 분산되기 위해 상기 파일 구조를 사용하는 계산을 허용함-에 제공하는 단계와,

    상기 파일 구조의 일부이고 상기 파일 구조에 대한 메타데이터의 일부로서 저장된 할당맵(allocation map) 내에 다수의 개별적인 컴퓨터 노드를 할당하는 단계를 포함하며, 상기 할당맵은 다수의 영역으로 세분되어 있어서, 상기 다수의 개별적인 컴퓨터 노드들이 서로 간섭하지 않고 스트라이프 파일(striped files)을 동시에 할당할 수 있게 되는 방법.
62. 제61항에 있어서,

    상기 파일 시스템은 상기 할당 맵으로의 액세스를 동기화시키기 위해 영역을 로크(lock)시키는 방법.
63. 제61항에 있어서,

    상기 시스템에는 상기 할당 맵을 여러 영역으로 세부분할하기 위한 디스크 할당이 제공되고, 상기 맵이 K개의 영역으로 분할될 때, 각 영역은 상기 파일 시스템의 N개 디스크 각각에서 1/K 블록(block)을 제어하는 방법.
64. 제63항에 있어서,

    상기 할당 맵은 정규 파일과 같은 블록 크기를 사용하고, 상기 영역은 하나 이상의 디스크 세그먼트(segment)로 구성되고, 각 세그먼트는 기껏해야 할당 블록의 크기이며, 상기 N개 디스크의 서브세트상에서의 블록 할당을 제어하고, 영역이 맵 블록 크기의 반보다 작으면, 다수의 영역이 각 맵 블록으로 모아지는 방법.
65. 제61항에 있어서,

    맵 영역의 할당에서, 영역의 수는 적어도 파일 시스템 노드수 만큼의 크기로 선택되므로, 각 노드는 다른 영역으로부터 할당될 수 있는 방법.
66. 제61항에 있어서,

    각 영역의 제1 세그먼트는 할당 맵의 시작부에 저장되고, 계속하여 각 영역의 제2 세그먼트로 이어져, 파일 시스템은 할당 맵을 재구성하지 않고 디스크를 더 추가시킴으로써 확장될 수 있고, 추가되는 세그먼트는 현존하는 할당 맵의 끝부분에 텃붙여지는 방법.
67. 제61항에 있어서,

    상기 파일 시스템은 토큰 자원(token resource)를 제공하고, 스트라이프된 파일의 연속적인 블록을 할당하기 위해, 노드는 영역에 대한 토큰을 구하고, 상기 노드가 토큰을 구한 영역에서 할당 맵 성분이 자유로운 상태를 나타내는 자유로운 블록을 사용해 스트라이핑(striping) 순열에 따라 연속적인 블록을 할당하는 방법.
68. 제61항에 있어서,

    할당 영역을 사용해 노드를 추적하고 각 영역에 남아있는 자유 공간을 추적하기 위한 할당 관리자 프로그램이 포함되는 방법.
69. 제68항에 있어서,

    상기 할당 관리자로 할당된 블록을 제어하는 영역을 사용하고 있는 각 노드와 파일 시스템에 블록 재할당(deallocation)을 지시하는 단계를 더 포함하는 방법.
70. 파일 데이터를 저장하고 컴퓨터 시스템의 다수의 노드(node)가 파일 데이터를 공유 디스크 파일 시스템(shared disk file system)에 동시에 저장하기 위한 공간을 할당하도록 허용하는 파일 시스템을 갖춘 컴퓨터 시스템에서,

    동일한 파일에 대한 데이터가 다수의 디스크 장치에 걸쳐 분산되는 파일 시스템을 제공하는 단계와,

    메모리에 대해 경쟁하는 서로 다른 시스템 구성요소간의 메모리 자원 사용을 구성요소에 대한 버퍼 정보를 이용하여 중재하는, 파일 시스템 버퍼 풀에 대한 버퍼 관리자(buffer manager) - 상기 버퍼 관리자는 상기 시스템의 구성요소들에 할당하는 메모리량을 판단하기 위해 필요하며, 상기 버퍼 정보는 소정의 메모리 크기와 현재 작용 레벨을 포함함 - 를 제공하는 단계와, 그런 후에

    상기 시스템의 상기 구성요소에 의해 사용되기 위해 얼마나 많은 메모리가 지정되었는지에 대한 데이터를 상기 버퍼 관리자로부터 상기 구성요소에 제공하는 단계를 포함하는 방법.
71. 제70항에 있어서,

    사용하기 위한 메모리 자원의 지정을 요구하는 시스템 구성요소 중 하나는 순차적인 판독기로 프리페치(prefetch)된 데이터 및 최근에 액세스된 파일 데이터를 캐싱(caching)하기 위해 제공되는 파일 시스템 버퍼 풀이고, 상기 구성요소로부터의 정보를 제공하는 상기 단계는

    파일 시스템 처리량을 최대화하기 위해 상기 버퍼 관리자에 의해 지정된 상기 자원을 프리패칭(preferching)하고 스케쥴링(scheduling)하기 위해 자원을 고려하도록 적절한 정보를 상기 버퍼 관리자에 제공하는 단계를 포함하는 방법.
72. 제70항에 있어서,

    상기 파일 시스템 버퍼 풀은 프리페칭을 위해 사용되는 풀 부분과 최근에 액세스된 파일 블록(block)을 캐싱하는데 필요한 범용 풀(general pool) 부분으로 논리적으로 분할되는 방법.
73. 제72항에 있어서,

    상기 풀 부분은 상기 파일 시스템이 풀 부분에 대해 개별적인 소정의 메모리 크기와 작용 레벨를 계산할 수 있도록 상기 버퍼 관리자에 2개의 개별적인 구성요소로서 제공되는 방법.
74. 제73항에 있어서,

    상기 풀 부분에 대한 상기 작용 레벨은 각 풀에 대한 데이터 액세스 비율을 측정하는 카운트(count)에 의해 계산되고, 각 버퍼 액세스에서, 적절한 카운트는 버퍼가 순차적인 또는 무작위의(random) I/O에 의해 액세스되고 있는지에 따라 갱신되는 방법.
75. 제72항에 있어서,

    상기 범용 풀은 일정 시간 주기에 걸쳐 액세스된 별개의 파일 데이터의 총량을 결정하기 위해 침조 비트와 카운터를 사용해 작업 세트(working sets)를 측정함으로써 계산되는 방법.
76. 제72항에 있어서,

    상기 프리페치 풀의 크기는 상기 파일 시스템에 속하는 디스크 드라이브의 용량과 수를 판단할 뿐만 아니라 순차적으로 액세스되는 파일의 수를 판단하고, 또한 데이터가 판독되는 비율을 판단함으로써 계산되는 방법.
77. 제72항에 있어서,

    파일 시스템에 대한 다수의 디스크 및 다수의 애플리케이션(application) 프로그램에 대한 상기 프리페치 풀을 계산하는 방법은, (a) 모든 애플리케이션 프로그램이 데이터를 판독하는 것을 시도하는 시점에서의 결합된 데이터 비율이 이용가능한 총 디스크 대역폭보다 작으면, 데이터는 I/O 대기 없이 데이터를 판독하는 것 만큼 신속하게 각 애플리케이션에 공급되고, (b) 상기 애플리케이션 프로그램의 결합된 데이터 비율이 이용가능한 총 디스크 대역폭보다 크면, 데이터는 디스크로부터 판독될 수 있는 것 만큼 신속하게 판독되도록, 요구되는 프리페치 버퍼의 수를 계산하는 방법.
78. 제72항에 있어서,

    상기 버퍼 관리자에 의해 지정된 실제 프리페치 버퍼의 수를 사용해 프리페치 I/O를 스케쥴링하는 단계와,

    현재 진행중인 프리페치 I/O의 수를 나타내는 제1 수와 판독될 블록을 보유하고 있는 버퍼의 수를 나타내는 제2 수를 대한 2개의 광역 카운터를 유지하는 단계와, 프리페칭에 현재 사용중인 버퍼의 수를 판단하기 위해 상기 제1 수와 상기 제2 수를 합산하는 단계와, 상기 수의 진행을 추적하여 상기 버퍼 관리자에 의한 풀 지정을 갱신하는 단계를 포함하는 방법.
79. 많은 세트의 데이터 기록(data record)을 저장하고 인덱싱(indexing)하는데 사용되고, 신속한 삽입, 삭제, 및 룩업(lookup) 동작과, 또한 상기 세트의 모든 데이터 기록의 순차적인 검색을 지원하는 시스템에서,

    데이터 기록을 식별하는 키(key)를 지정함으로써 데이터를 저장하고 검색할 수 있는 상기 시스템에 파일 시스템을 제공하는 단계,

    한 세트의 데이터 기록에 초기의 단일 해시 버킷(hash bucket)을 갖는 인덱스(index)나 디렉토리(directory)를 제공하고, 상기 초기 해시 버킷에 들어갈 때까지 저장되어질 데이터 기록 세트의 모든 기록을 해시 함수(hash function)을 사용해 상기 초기 해시에 저장하고, 초기 해시 버킷이 가득 찰 때, 제2 해시 버킷을 추가하고 기록을 배치하는데 사용된 상기 해시 함수에 하나의 비트를 추가함으로서 분리하고, 그에 의해 상기 하나의 비트가 없는 기록이 상기 초기 해시 버킷으로 이동되는 동안 상기 하나의 비트를 갖는 기록은 상기 제2 해시 버킷으로 이동되고, 새로운 기록은 상기 해시 함수에 대한 비트 값에 따라 초기 버킷이나 상기 제2 버킷에 추가되고, 해시 버킷이 다시 가득 차면, 상기 버킷은 분리되어 해시 함수에 대한 두 비트가 제2 버킷으로부터의 기록이 배치될 위치를 결정하는 반면, 초기 버킷내의 기록은 상기 새롭게 분리되는 상기 제2 버킷에 의해 영향을 받지 않지만, 또한 분리될 수 있는 단계를 포함하는 방법.
80. 제79항에 있어서,

    수회의 분리 이후에, 수개의 분리 버킷은 이진수 해시 트리(binary hash tree)로서 다루어지고, 기록은 상기 이진수 트리의 각 내부 노드에서 어느 가지가 이어지는가를 결정하는 키로서 해시 버킷 비트를 사용해 초기의 뿌리(root) 버킷 노드로부터 잎부분(lead) 해시 버킷 노드로 트리를 횡단(traverse)함으로써 발견되는 방법.
81. 제79항에 있어서,

    순차적인 디렉토리 조사(sequential directory scan)는 깊이 우선의 트리 횡단(depth-first tree traversal)에 의해 이루어지는 방법.
82. 제79항에 있어서,

    수개의 버킷은 디스크상의 희소 파일(sparse file)로 표현되는 이진수 해시 트리로 처리되고, 해시 버킷이 분리될 때 기록들은 재배치되고, 순차적인 디렉토리 조사는 현존하는 모든 엔트리(entry)가 정확히 한 번 리턴(return)되도록 상기 해시 트리를 횡단하는 방법.
83. 제79항에 있어서,

    i는 해시 버킷 번호이고 s는 해시 버킷 크기일 때, 각 해시 버킷은 i*s로 주어지는 오프셋(offset)으로 희소 파일내에 저장되고, 디렉토리는 빈 파일로 시작되고, 파일 크기는 기록을 삽입함으로써 분리될 필요가 있는 크기까지 증가되고, 분리되면, 추가 버킷은 제1 분리시에 파일 크기를 s에서 2*s로 증가시켜 기록되는 방법.
84. 제79항에 있어서,

    룩업(lookup) 동작은 룩업되는 키의 해시값과, 해시 버킷 크기로 나누어지는 파일 크기에 밑을 2로 하는 log 값을 취한 해시 트리 깊이를 계산하는 단계로 실행되고, 상기 계산 단계는 삽입 동작을 위해서도 또한 계산되는 방법.
85. 제79항에 있어서,

    희박한 파일에서, 파일 시스템 블록 장벽(block barrier)상에 홀(hole)이 정렬되고 파일의 디스크 블록 위치를 포함하는 파일 메타데이터가 캐시(cache)되므로, 버킷 크기는 파일 시스템 블록 크기와 같아지는 방법.
86. 제79항에 있어서,

    순차적인 디렉토리 주사로서 해시 트리의 내용을 반복적으로 리턴시키도록 호출될 수 있는 조사 동작이 제공되고, 각 호출은 하나 이상의 기록, 및 다음세트의 기록을 검색하기 위해 다음 조사 호출로 전해지는 내용 정보값을 리턴시키는 방법.
87. 제79항에 있어서,

    해시 버킷 병합은 순차적인 조사 동안에 처리되는 방법.
88. 제79항에 있어서,

    상기 시스템은 병렬 파일 시스템(parallel file system)인 방법.
89. 제79항에 있어서,

    상기 시스템은 디스크가 각 파일 시스템에 국부적으로 부착된 것처럼 보이게하는 프로토콜(protocol)을 가지고 통신 네트워크에 걸쳐 상호연결된 다수의 컴퓨터에 대해 실행되는 하나 이상의 공유 디스크 파일 시스템에서 사용되는 방법.
90. 예측가능하지않은 형태로 파일 시스템에 주어지는 가변 크기의 캐시 공간 요구(cache space request)를 갖는 컴퓨터 시스템에서 파일 시스템의 캐시 사용도를 개선하는 방법에 있어서,

    상기 캐시를 각각이 캐시 상태의 일부를 제어하는 다른 작업 캐시 유닛으로 분리하는 단계,

    들어오는 요구의 성질을 예측하고 들어오는 각 요구가 그 요구를 만족시킬 가능성이 가장 높은 캐시 유닛으로 전해지도록 요구를 제시하기 위한 현재 캐시 사용 패턴을 분석함으로써 캐시 사용도를 최적화하도록 캐시 관리자(cache manager)와 주기적으로 상의하는 단계, 및

    각 작업 유닛내의 각 작업 부하(workload)에 전용될 수 있는 공간을 결정하고, 각 작업 유닛내의 각 작업 부하에 전용될 수 있도록 결정된 상기 공간에 응답해 다른 시스템 작용을 조정하는 단계를 포함하는 파일 시스템의 캐시 사용도 개선 방법.
91. 제90항에 있어서,

    상기 다른 시스템 작용은 프리페칭 비율(prefetching rate)을 포함하는 파일 시스템의 캐시 사용도 개선 방법.
92. 제90항에 있어서,

    작업 부하의 주기적인 식별에서, 두 종류의 작업 부하, 즉 순차적인 작업부하와 랜덤 작업 부하는 시스템내의 현재 사용 패턴이 설정된 이후에 검출되어 응답되고, 비교적 안정된 것으로 가정되고, 그에 따라 상기 캐시에 대한 상기 캐시 관리자가 응답하는 파일 시스템의 캐시 사용도 개선 방법.
93. 제92항에 있어서,

    완전한 캐시는 각각이 완전한 캐시 공간의 일부를 제어하는 다른 작업 유닛으로 분할되고, 시스템이 동작되는 두 종류의 작업 부하를 모니터하는 2개의 서브-유닛(sub-unit)으로 구성된 각 작업 유닛으로 소정의 미리 정의된 크기의 버퍼를 책임지므로, 책임지는 버퍼 크기와 다른 작업 유닛의 양은 동적으로 변하는 파일 시스템의 캐시 사용도 개선 방법.
94. 제93항에 있어서,

    캐시 관리자는 매 순간 시간에 맞게 많은 요구가 있을 가능성이 높은 버퍼 크기를 인식하고, 그에 따라 작업 유닛을 설정하는 파일 시스템의 캐시 사용도 개선 방법.
95. 제92항에 있어서,

    들어오는 요구(incoming request)를 원하는 크기의 버퍼를 담당하는 캐시 부분에 직접 지시함으로써 캐시 응답 시간을 증진시키기 위해, 고정된 크기의 다른 모든 작업 유닛과 다른 버퍼 크기에 대해 들어오는 요구를 관리하는 작업 유닛이 시스템에 존재하는 파일 시스템의 캐시 사용도 개선 방법.
96. 제92항에 있어서,

    합쳐진 사용 통계량(gathered usage statistics)이 주기적으로 조사되므로, 상기 캐시 관리자는 다른 작업 유닛간에 재분할된 캐시 공간에 대해 제어하는 옵션을 갖고, 현재 패턴을 분석함으로써 미래 사용 패턴을 예측하므로, 새로운 공간 재분할이 즉시 수행되지 않고, 요구가 있을 때 효과를 나타내는 파일 시스템의 캐시 사용도 개선 방법.
97. 제92항에 있어서,

    각 작업 유닛은 두 종류의 공간 제한, 즉 내부적인 제한과 외부적인 제한을 포함하고, 상기 내부 공간 제한은 2개의 서브-작업 유닛간을 분할하고, 각 작업 유닛의 상기 외부 공간 제한은 두 종류의 제한, 즉 물리적인 제한과 가상적인 제한으로 더 분할되고, 상기 물리적인 제한은 각각의 작업 유닛에 속하는 사용 패턴 구조 분포의 제어하에서 실제 공간량을 나타내고, 상기 가상적인 제한 - 상기 가상적인 제한은 특정한 작업 유닛의 물리적인 제한이 커지는 것이 허용되었는지, 또는 커지는 것이 허용된 작업 유닛으로부터의 요구에 따라 그의 제어하에서 공간의 일부를 포기하도록 하여 실질적으로 축소되도록 허용되었는지를 추론하는데 사용됨 - 은 상기 작업 유닛이 달성하려고 하는 물리적인 제한으로서 사용 패턴 예측 처리에 의해 반영되는 파일 시스템의 캐시 사용도 개선 방법.
98. 제97항에 있어서,

    최적으로 필요로 되는 공간을 결정하는 작용 레벨 및 사용 패턴을 추론하기 위해 서브-작업 유닛의 통계량을 분석함으로써 새로운 가상 유닛을 설정하는 단계를 더 포함하고, 서브-작업 유닛이 그가 필요에 대한 최적의 작업 세트 크지로 결정된 공간량을 구하려고 할 때, 상기 서브-작업 유닛의 상대적인 작용 레벨은 최적으로 필요시 되는 공간 상에 캡(cap)을 나타내는 파일 시스템의 캐시 사용도 개선 방법.
99. 제98항에 있어서,

    새로운 공간 획득을 위해, 새로운 버퍼 공간에 대한 요구가 도착될 때, 이는 요구된 크기를 제어하는 작업 유닛에 의해 다루어지고, 상기 작업 유닛에서 버퍼를 얻는 것이 자유롭거나 매우 쉽고 신속하다면, 이는 들어오는 요구를 만족시기 위해 사용되고, 상기 작업 유닛은 그의 물리적인 제한과 가상적인 제한을 비교하여 물리적인 제한이 가상적인 제한보다 더 작지 않으면, 작업 유닛은 그의 제어하에서 구해지기 가장 쉬운 공간을 찾기 위해 진행하지만, 그렇지 않으면 현재 작업 유닛은 가장 많이 축소하는 것이 허용된 작업 유닛을 찾아 그 유닛에 공간 획득 요구를 전달하며, 그에 의해 수신한 작업 유닛은 그의 제어하에서 구해지기 가장 쉬운 공간을 찾아, 이에 대한 제어를 포기하고, 이어서 원래 작업 유닛은 새로운 공간에 대한 제어를 맡도록 진행하고, 상기 들어오는 요구를 만족시키도록 이를 사용하는 파일 시스템의 캐시 사용도 개선 방법.
100. 제98항에 있어서,

     주기적인 사용 검출 동안, 상기 캐시 관리자는 모든 작업 유닛이 그의 제어하에서 모든 공간을 억세스하는 예측 시간을 근거로 계산하여 상기 주기적인 사용검출이 다음에 실행되어야 할 때를 판단하고, 상기 예측시간 기간은 선정된 상한 및 하한 경계값에 한정되며, 상기 상한 및 하한 경계값은 사용 패턴 프로세스가 하나의 변형 사건(straining event)에 의해 영향받지 않고 현재 작업 부하 분포를 추론할 수 있도록 해주며, 랜덤한 직업부하 클라이언트의 작업 세트뿐만 아니라 순차적인 작업부하 클라이언트에 요구되는 공간까지 추론될 수 있는 파일 시스템의 캐시 사용도 개선 방법.
101. 다수의 컴퓨터가 동일한 데이터 객체를 갱신하거나 확대하는 파일 시스템을 위한 공유 디스크(shared disk) 환경을 갖는 컴퓨터 시스템에서,

     상기 공유 디스크 환경에서의 병렬 판독 및 기록을 위해 파일 메타데이터(metadata)를 관리하도록 메타데이터 노드(metadata node)를 상기 공유 디스크 파일 시스템의 동작에 제공하는 단계와,

     상기 파일 시스템을 구성하는 모든 디스크가 메타데이터 노드 선택 및 식별을 사용함으로써 상기 컴퓨터 시스템의 다수의 프로세서에 의한 공유 액세스를 독립적으로 가질 수 있도록 파일의 메타데이터와 연관된 데이터를 관리하는 메타노드(metanode)를 찾기 위해 로크 모드(lock mode)를 사용하는 토큰(token)을 사용하는 단계를 포함하는 방법.
102. 제101항에 있어서,

     노드는 특정한 파일의 메타데이터를 액세스하고 갱신하는 것을 담당하는 각 파일에 대한 메타데이터 노드로서 지명되고 요구에 따라, 상기 메타데이터 노드는 이 정보를 다른 노드와 공유하는 방법.
103. 제102항에 있어서,

     메타데이터 노드가 메타데이터 노드 기능을 수행하는 것을 중단할 때, 새로운 메타데이터 노드가 선택되고, 선택되면, 새로운 메타데이터 노드 정보는 모든 노드에 이용가능해지는 방법.
104. 제103항에 있어서,

     메타데이터 노드가 메타데이터 노드 기능을 수행하는 것을 중단할 때, 새로운 메타데이터 노드가 선택되고, 선택되면, 새로운 메타데이터 노드 정보는 모든 노드에 이용가능해지고, 새로운 메타노드의 선택 처리는 이전의 메타노드와 연관된 파일의 액세스 패턴을 고려하는 방법.
105. 제103항에 있어서,

     토큰 관리자(token manager)는 토큰을 노드에 부여하기 위해 제공되고,

     요구 모드가 다른 노드에 부여되었던 같은 이름의 토큰과 충돌하지 않으면 요구하는 노드에 토큰을 부여하는 단계를 포함하는 방법.
106. 제105항에 있어서,

     메타데이터 토큰의 모드는 메타노드 토큰을 포함하는 3가지 모드, 즉 "ro" (read-only), "ww" (weak-write), 및 "xw" (exclusive-write) 중 하나인 방법.
107. 제105항에 있어서,

     각 토큰에 대해 가능한 모드와 충돌 테이블의 리스트가 있고, 상기 요구된 토큰이 또 다른 노드에 부여되었던 토큰과 충돌하면, 취소가 행해지고, 충돌 모드는 그 토큰 모드를 상기 요구된 모드와 충돌하지 않는 모드로 다운그레이드(downgrade)하는 방법.
108. 제107항에 있어서,

     메타데이터 노드는 파일을 액세스하는 제1 노드가 되도록 하나의 파일에 대해 선택되고, 단 하나의 노드가 파일을 액세스할 필요가 있으면, 상기 하나의 노드가 메타데이터를 직접 액세스할 수 있으므로 추가 오버헤드(overhead)인 메시지는 필요로 하지 않지만, 부가적인 노드가 메타데이터를 위해 메타노드를 액세스하게 되는 방법.
109. 제107항에 있어서,

     각 파일에 대해, 메타노드 토큰은 3가지 모드로 정의되어, "xw" 토큰은 모든 모드와 충돌하고, "ww"는 "xw" 및 그 자신과 충돌하고, 또한 "ro"는 "xw"하고만 충돌하는 방법.
110. 제109항에 있어서,

     0 또는 그이상의 노드는 "ro"에서 토큰을 유지하고, 최대한 하나의 노드가 "ww"에서 토큰을 유지할 수 있거나, 단일 노드가 "xw"에서 토큰을 유지하고, 토큰 관리자 서브시스템은 하나의 노드에 대한 토큰을 관리하는 방법.