KR20050030883A

KR20050030883A - 이송 및 소거 후보들에 대한 효율적인 탐색

Info

Publication number: KR20050030883A
Application number: KR1020047004500A
Authority: KR
Inventors: 사케마크; 루에프리차드; 에버손커트
Original assignee: 이엠씨 코포레이션
Priority date: 2001-09-26
Filing date: 2002-09-26
Publication date: 2005-03-31
Also published as: JP2005512171A; JP2005510780A; EP1430400A2; WO2003027909A1; JP2005505829A; US8442957B2; WO2003032171A3; CN1307580C; ATE555445T1; EP1433086A1; EP1433086A4; CN1559041A; US20040143563A1; CN1311358C; KR100962055B1; US20040133540A1; US8484172B2; CN1559035A; US20040133608A1; WO2003027882A1

Abstract

컴퓨터 시스템은 복수의 파일들, 및 파일들과 관련된 아이노드 이송 또는 소거 정보를 포함하는 데이터 파일을 저장하도록 구성된다. 컴퓨터 시스템은 이송 또는 소거에 대한 후보인 파일들을 식별하기 위해 데이터 파일을 탐색한다. 파일들과 관련된 복수의 경로명들이 데이터 파일 또는 개별 데이터 파일에 저장되고, 컴퓨터 시스템은 데이터 파일(또는 개별 데이터 파일)로부터 후보의 경로명들을 얻는다. 후보 파일들이 식별될 때, 후보 파일들의 아이노드들은 복수의 경로명들에서 그들의 경로명을 룩업하기 위해 사용된다. 데이터 파일은 파일이 변형되었는지 여부 및 최종 액세스의 시간에 관한 정보를 포함할 수도 있다. 파일이 이송에 대한 후보인지를 결정하기 위해, 데이터 파일의 엔트리가 변형되었는지 여부를 결정하기 위해 데이터 파일의 엔트리가 검사된다. 변형된 경우에, 이송 후보로서 결정된다. 변형되지 않았고 최종 액세스의 시간이 소정의 값보다 오래된 경우에 파일은 소거 후보로 결정된다.

Description

이송 및 소거 후보들에 대한 효율적인 탐색{Efficient search for migration and purge candidates}

관련 출원에 대한 상호 참조

본 출원은 모든 목적들을 위해 여기에 참고 문헌으로서 포함되는 2001년 9월 26일 출원되고 발명의 명칭이 SYSTEMS & METHOD FOR MANAGING TABLESPACES AND DATABASES인 공동 계류중인 미국 특허 출원 60/324,578 호(대리인 관리 번호 제 OTG-001PROV)에 대한 우선권을 주장한다.

본 발명은 일반적으로 이송(migration) 및 소거(purge) 후보들을 효율적으로 탐색하기 위한 방법, 제조품(article of manufacture), 및 장치에 관한 것이다. 특히, 본 발명은 이송 및 소거 후보들의 컴퓨터 시스템의 파일을 효율적으로 탐색하고 후보들의 경로명을 얻는 것에 관한 것이다.

본 발명은 객체 관리 시스템에서 대용량의 파일들의 관리에 관한 것이다. 오라클(Oracle) 데이터베이스들과 사용되는 시스템과 같은 기존의 시스템들은 매우 큰 테이블공간(tablespace)을 처리하도록 설계된다. 테이블공간은 운영 체제에 의해 액세스 또는 처리될 수도 있는 파일들인 복수의 데이터 파일들로 이루어질 수도 있다. "데이터 파일"은, 데이터가 물리적으로 저장 매체에 연속적으로 저장되는지의 여부에 관계없이, 연속적인 정보로서 카피, 이동, 또는 처리될 수 있는 파일을 말한다.

로컬 기억 용량은 하나 이상의 데이터베이스와 연관된 전체 테이블 공간을 저장하기에 충분하지 않을 수도 있다. 특히, 데이터 모두를 반드시 비교적 고속으로 액세스할 필요가 없을 때, 전체 데이터베이스를 저장하기 위하여 충분한 용량을 제공하기 위해 (하드 디스크 또는 광학 매체와 같은) 충분한 고속 액세스 저장 매체를 구입하는 것은 비경제적일 수도 있다. 데이터가 저가의 매체로 "이송(migrated)" 되고 필요할 때만 매체로부터 검색될 수 있는 종래의 데이터베이스 시스템이 구현되어 왔다. 그러나, 기존의 시스템들과 방법들은 이송 및 검색 이후에, 이송될 데이터를 효율적으로 관리하지 못한다. 이들 시스템들은 대기 시간을 가지며, 높은 대역폭 요건을 가지며, 긴 백업 시간을 필요로 하고, 고비용을 가지며, "포인트 인 타임(point in time)" 스냅샷(snapshots)을 할 수 없을 수도 있다.

이들 문제점들은 데이터베이스 및 테이블 공간에 한정되지 않는다. 오히려, 이들 문제점들은 멀티미디어와 같은 큰 파일을 저장하는 시스템들에 적용될 수 있다.

여기서 공개되는 보다 효과적인 접근 방식은 대기시간 및 대역폭 요건을 감소시키고, 비용을 감소시키고, 보다 작은 백업 윈도우를 필요로 하며, 따라서 데이터가 보다 효율적으로 관리된다. 본 명세서의 개시물이 데이터베이스 및 테이블공간에 관한 문제점과 발명을 설명할 수도 있지만, 본 발명은, 특히, 시스템이 오디오 또는 비디오와 같은 큰 데이터 파일을 관리할 때, 이송을 사용하는 임의의 데이터 관리 시스템에 적용될 수도 있다.

본 발명은 첨부한 도면과 함께 이하의 상세한 설명에 의해 쉽게 이해될 것이고, 유사한 참조 번호는 유사한 구조적 소자를 나타낸다.

도 1은 프런트 엔드 및 백 엔드를 갖는 객체 관리 시스템의 개략도이다.

도 2는 부착된 대용량 기억 장치를 갖는 컴퓨터 시스템의 개략도이다.

도 3은 아이노드들(inode)과 DMAPI 정보가 저장된 파일 사이의 논리 관계의 블록도이다.

도 4는 아이노드와 DMAPI 정보가 저장된 확장 블록 사이의 논리 관계의 블록도이다.

도 5는 파일, DMAPI 확장 데이터 파일, 컨테이너 파일들, 및 백 엔드에 저장된 파티션들의 블록도이다.

도 6은 객체 관리 시스템에 사용되는 데몬(daemon)들을 나타내는 블록도이다.

도 7은 파티션들의 버전을 나타내는 블록도이다.

도 8은 이송 프로세스를 나타내는 흐름도이다.

도 9는 일관성을 보장하기 위한 파일 상태의 갱신을 나타내는 흐름도이다.

도 10은 소거 프로세스를 나타내는 흐름도이다.

도 11은 데이터의 재배치(restaging)와 이벤트 처리를 나타내는 흐름도이다.

도 12는 파티션의 재배치를 나타내는 블록도이다.

도 13은 이송 또는 소거 후보들의 효율적 탐색을 나타내고 후보 경로명들을 얻는 흐름도이다.

도 14는 이송 또는 소거 후보들을 탐색하기 위한 여러 접근방법들을 나타내는 블록도이다.

도 15는 다른 컴퓨터에 대해 사용 가능한 하나의 컴퓨터로부터 데이터를 생성하기 위해 컨테이너 파일들의 사용을 나타내는 흐름도이다.

도 16은 도 15의 컴퓨터들의 블록도이다.

따라서, 요약하면, 본 발명은 객체 관리 시스템에서 객체들을 공유하기 위한 방법, 제조품, 및 장치를 제공한다. 본 발명의 일실시예에서, 컴퓨터 시스템은 복수의 파일들, 및 이 파일들과 관련된 아이노드(inode) 및 이송 또는 소거 정보를 포함하는 데이터 파일을 저장하도록 구성된다. 컴퓨터 시스템은 이송 또는 소거의 후보들인 파일들을 식별하기 위해 데이터 파일을 탐색한다.

파일들과 관련된 복수의 경로명들은 데이터 파일 또는 개별 데이터 파일에 저장되고, 컴퓨터 시스템은 데이터 파일(또는 개별 데이터 파일)로부터 후보 파일들의 경로명들을 얻는다. 후보 파일들이 식별될 때, 그 아이노드들은 복수의 경로명들에서 자신들의 경로명을 룩업하기 위해 사용된다.

데이터 파일은 파일이 변형되었지는지 여부 및 최종 액세스 시간에 관한 정보를 포함할 수도 있다. 파일이 이송의 후보인지를 결정하기 위해, 데이터 파일의 엔트리가 변형되었는지 여부를 결정하기 위해, 데이터 파일의 엔트리가 검사된다. 변형되지 않았고 최종 액세스의 시간이 소정의 값보다 오래된 경우에 파일은 소거 후보로 결정된다.

본 발명의 이점 및 더욱 상세한 설명은 첨부한 도면을 참조하여 이하의 상세한 설명으로부터 명백할 것이다.

이하, 실시예의 상세한 설명을 제공한다. 본 발명을 실시예와 관련하여 설명하지만, 본 발명은 임의의 실시예에 한정되지 않는다. 반대로, 발명의 범위는 첨부하는 청구범위에 의해서만 한정되고, 본 발명은 다수의 변경물, 변형물, 및 동등물을 포함한다. 예시하기 위한 목적으로, 본 발명의 전반적인 이해를 제공하기 위해 이하의 설명에서 다수의 특정한 상세한 설명을 설명한다. 본 발명은 이들 상세한 설명중의 일부 또는 모두를 사용하지 않고 청구범위에 따라 실시될 수도 있다. 명확하게 하기 위해, 발명과 관련된 기술 분야에 공지되지 않은 기술 재료는, 본 발명을 불필요하게 불명료하게 하지 않기 위해 설명하지 않는다.

프로세스, 장치, 시스템, 디바이스, 방법, 또는 컴퓨터 판독 가능한 저장 매체와 같은 컴퓨터 판독 가능한 매체 또는 프로그램 지시가 광학 또는 전자 통신 링크를 통해 전송되는 컴퓨터 네트워크를 포함하는 다수의 방법으로 본 발명을 구현할 수 있다는 것을 이해할 것이다.

개관

일실시예에서, 객체 관리 시스템(10)은, 도 1에 도시한 바와 같이, 제 1 또는 로컬 컴퓨터 시스템(12)과 제 2 또는 원격 컴퓨터 시스템일 수 있는 저장 시스템(14)을 구비한다. 프런트 엔드라 칭할 수도 있는 제 1 컴퓨터 시스템(12)은 사용자(도시되지 않음)에게 제 1 애플리케이션 및 데이터 저장 서비스를 제공한다. 통상의 동작 동안, 제 1 컴퓨터 시스템(12)은 CPU(20)상에서 애플리케이션을 구동하고, RAID 어레이 또는 다른 구성에서, 단독으로 하드 디스크 드라이브(18)와 같은 고속 장치를 구비하는 로컬 파일시스템(16)상의 로컬 데이터로의 액세스를 제공한다. 백 엔드(14)라 칭하는 저장 시스템(14)은 파일시스템(26)으로 구성될 수도 있거나 특별한 기억 장치일 수도 있는 다양한 대량 기억 장치와 접속된 범용 CPU(22)일 수도 있다. 백 엔드(14)에서 사용된 대량 기억 장치는 하드 디스크 드라이브(24), 또는 더 싸고, 더 느리거나 기록 목적용인 다른 장치일 수도 있다. 예를 들어, 광학 디스크(28), 테이프 드라이브(30), 및 자기-광학 드라이브가 사용될 수도 있다. 백 엔드(14)는 셀덤-액세스 데이터(seldom-accessed data)의 저가의 니어-라인(near-line)저장장치로서 사용될 수도 있고, 프런트 엔드(12)에 데이터를 백업하기 위해 사용될 수도 있다.

백 엔드(14)는 프런트 엔드(12)와 동일한 위치에 위치되거나, 관련이 없이 위치될 수도 있다. 데이터 전송은 NFS, AFS, FTP, 또는 다른 방법을 통해 달성된다. 프런트 엔드(12) 및 백 엔드(14)는 일 대 일(one-to-one), 다 대 일(many-to-one), 또는 다 대 다(many-to-many)관계로 접속될 수 있다. 일반적으로, 프런트 엔드(12)에 대한 파일시스템들(16)은 백 엔드(14)와 일 대 일 관계이지만, 상이한 백 엔드(14)로 각각 매핑하는 프런트 엔드(12)에 대한 여러 파일시스템들(16)이 있을 수도 있다. 이 구성은, 예를 들어, 각 파일시스템(16)이 회사내의 상이한 그룹에 속하는 상이한 애플리케이션에 대해 사용될 때 사용될 수 있다. 따라서, 회계부서에 대한 데이터는 하나의 백 엔드(14)시스템으로 갈 수도 있지만, 임금대장(payroll)용 데이터는 다른 백 엔드(14)로 갈 수도 있다. 이들 백 엔드 시스템들(14)은 상이한 원격 위치에 있을 수도 있다.

동작중에, 이송 데몬은 프런트 엔드(12)로부터 백 엔드(14)로 데이터를 이송(카피)하고, 즉, 프런트 엔드(12)로부터 백 엔드(14)로 데이터를 카피한다. 데이터는 백 엔드(14)에 기록되는 파티션들로 분할된다. 파일이 이송되면, 프런트 엔드(12)상으로 이송된 것으로서 표시된다. 이것은 파일이 이송되었다는 것을 나타내는 비트 또는 다른 플래그를 설정함으로써 행해진다. 소거 데몬은 데이터가 프런트 엔드(12)에 더 이상 필요치 않는 이송된 파일을 찾고 불필요한 데이터를 소거한다. 이벤트 데몬은 데이터 액세스 이벤트들을 트랩하고, 데이터가 프런트 엔드(12)에 필요한 경우에, 백 엔드(14)로부터 프런트 엔드(12)로 데이터를 재배치한다. 이벤트 데몬은, 필요한 파일의 일부분을 이동시키도록 구성되어, 파일의 일부분만이 재배치될 수도 있다. 이것은, 전송될 데이터의 양을 감소시키는 장점을 갖기 때문에, 대역폭 요구 및 대기시간을 감소시킨다.

주기적으로, 이송 데몬은 이송될 필요가 있는 파일들 (또는, 파일들의 일부분)을 검사한다. 더티(dirty)로 표시된(즉, 백 엔드(14)로의 최종 이송 때 기록된)재배치된 파일을 찾는 경우에, 백 엔드(14)로 이송한다. 이송 데몬은 변형된 파티션들만 기록하도록 구성된다. 변형되지 않은 파티션들은 기록될 필요가 없기 때문에, 전송될 데이터의 양을 감소시킨다. 백 엔드(14)에서, 변형된 파티션들이 버전되고 대량 기억 장치에 기록된다. 또한, 이들은 기존의 파티션들을 통해 기록될 수도 있지만, 이전의 버전을 보존하는 것은 포인트-인-타임 스냅샷을 생성할 수 있게 하여, 어떠한 소정의 시간에서 시스템의 상태가 보존될 수도 있다. 파티션들 및 다른 메타데이터에 관한 정보는 백 엔드(14)의 고속 저장장치에 위치될 수도 있는 컨테이너 파일들에 기록된다. 이 구성에서, 시스템의 동작에 의해 백업이 생성되고, 컨테이너 파일들이 프런트 엔드(12)에 데이터를 저장하기 위해 필요한 모든 정보를 포함하기 때문에 개별 백업은 필요하지 않다.

이들 동작은, 파티션 크기 및 다른 구성 및 환경 정보를 설정하는 것은 제외하고 애플리케이션 사용자의 일부에 대한 특별한 개입을 필요로 하지 않고 투과적으로 수행된다.

이러한 시스템은 모든 데이터를 카피할 필요없이 하나의 컴퓨터 시스템으로부터 또 다른 컴퓨터 시스템으로 데이터를 사용 가능하게 하기 위해 사용될 수도 있다. 이것을 달성하기 위해, 제 2 컴퓨터 시스템은 로컬 파일시스템에 대한 자체 파일들을 생성하기 위해 백 엔드(14)에 대해 제 1 컴퓨터의 컨테이너 파일들을 사용하도록 구성된다. 제 2 컴퓨터 시스템은, 셋업 또는 필요한 경우에 자체 데이터를 백 엔드(14)에 기록할 때, 자체 컨테이너 파일들을 생성한다. 제 2 컴퓨터의 동작 동안, 데이터 액세스들은, 프런트 엔드(12)에 존재하지 않는 경우에 백 엔드(14)로부터 파일들의 필요한 파티션의 재배치를 발생시킨다. 컴퓨터 시스템이 데이터를 변경하는 경우에, 컴퓨터 시스템은 데이터를 이송할 때 자체 파티션들을 백 엔드(14)에 기록하고, 자체 컨테이너 파일들을 갱신한다. 따라서, 각 컴퓨터 시스템은 파일의 자체 버전을 갖는다.

또한, 시스템은 단일 파일내에 파일명칭, 아이노드, 및 확장된 속성을 저장함으로써, 이송 및 소거 후보들을 효율적으로 탐색하도록 구성될 수도 있다. 시스템은, 아이노드 및 명칭공간에서 모든 파일에 대한 확장 블록을 검사하지 않고 이송 또는 소거 후보들을 빠르게 식별하기 위해 이러한 파일을 탐색할 수 있다. 아이노드 번호를 사용하는 리버스 룩업이 경로명을 결정하기 위해 사용된다. 이러한 접근방법은 시스템이 이송 및 소거 후보들에 대한 아이노드만을 룩업할 수 있게 하여, 필요한 시간을 감소시킨다.

시스템은 데이터베이스에 의해 사용된 큰 테이블공간을 관리하도록 사용될 수도 있지만, 특히, 데이터 액세스가 파일의 일부분인 큰 파일들의 관리에 응용력을 갖는다.

일실시예에서, 제 1 및 제 2 컴퓨터시스템 각각은 워크스테이션 구동 유닉스와 같은 범용 컴퓨터상에서 실행되는 소프트웨어 프로그램을 포함하지만, 윈도우즈 또는 리눅스 운영 체제을 구동하는 인텔 펜티엄-기반 PC와 같은 컴퓨터 시스템이 사용될 수도 있다. 응용 주문형 집적 회로(ASIC)또는 필드-프로그램 가능한 게이트 어레이(FPGA)와 같은 칩에 내장된 명령을 갖는 특별 목적 배선 시스템과 같은 컴퓨터 시스템을 구현하는 다른 수단이 사용될 수도 있다. 저장 시스템으로서 사용되는 제 2 컴퓨터 시스템은 EMC, 네트워크 장치, 스토리지텍(StorageTek), 및 네트워크 부착 저장장치(NAS) 및 저장 영역 네트워크(SAN)구성에 접속된 ADIC에 의해 이루어지는 것과 같은 특별한 기억 장치의 형태로 구현될 수도 있다. 컴퓨터 시스템(40)은 도 2에 도시한 바와 같은, 다음과 같은, 중앙 처리 유닛(41), 메모리(42), 디스플레이(44), 키보드(46), 대량 기억 장치(48), 네트워크 인터페이스(50), 및 다른 입력 또는 출력 장치(52)와 같은 임의의 번호를 가질 수 있다. 공통적인 실시에 따라, 메모리(42) 및 대량 기억 장치(48)는 프로그램 명령 및 데이터를 저장하기 위해 사용될 수 있다. 컴퓨터 시스템(40)은 멀티프로세서 펜티엄-기반 시스템 또는 Sun SPARCstation과 같은 하나 이상의 중앙 처리 유닛(41)을 더 가질 수도 있다. 대량 기억 장치(48)는 하나 이상의 하드 디스크 드라이브들, 광학 드라이브들, 테이프 드라이브들, 자기-광학 드라이브들, DATs, CD 드라이브들, DVD 드라이브들, 또는 RAID, 섬유 채널, 또는 다른 인터페이스를 사용하여 데이터를 저장하는 다른 장치를 구비할 수도 있다. 대량 기억 장치(18)는 파일시스템들로 구성될 수도 있고, 하나 이상의 대량 기억 장치(18)의 세트가 사용될 수도 있다.

객체 저장형인 파일시스템은(객체의 ID가 경로명인 경우에)파일들 또는(객체가 파일시스템 명칭 이외의 어떤 ID로 칭해지는 경우에)객체들을 저장할 수도 있다. 객체 저장은 다음의 구성요소들 : 객체들을 식별하기 위한 방법; 객체들(API, 원시 파일시스템 등)의 처리를 허용하는 인터페이스; 및 객체용 저장장치를 갖는다. 파일은 객체형으로 간주될 수도 있다. 본 명세서에 개시한 원리는 객체들 및 객체 저장 뿐만 아니라 파일들 및 파일시스템들에 동일하게 적용한다. 객체 저장에 있어서, 백 엔드에서 객체들을 어디서 찾는지를 설명하는 확장된 속성은 파일 명칭 대신에 객체 ID이다.

일반적으로, 프런트 엔드(12)로서 작용하는 제 1 컴퓨터 시스템은 데이터에 빠르게 액세스하기 위한 하드 디스크 드라이브(18)형태의 고속 저장장치를 갖는다. 백 엔드(14)로서 작용하는 저장 시스템은 고속 저장장치 뿐만 아니라 테이프 백업(30) 및 광학 드라이브들(28)과 같은 저속이지만 더욱 경제적인 장치를 갖는다. 다른 기록 장치들이 저장 시스템(14)에 부착될 수도 있다. 백 엔드(14)는 덜 빈번하게 액세스되는 데이터의 저장을 위해 사용되어서, 고가의 고속 저장 공간에 대한 필요성을 감소시킨다.

또한, 백 엔드(14)가 제 1 컴퓨터 시스템(12)의 일부분으로서 구현될 수도 있어서, 백 엔드(14)의 기억 장치는 제 1 컴퓨터 시스템(12)에 부착된다. 개시한 실시예가 프런트 엔드(12) 및 백 엔드(14)용의 개별적인 제 1 및 제 2 컴퓨터 시스템을 각각 설명하지만, 개별적인 제 2 컴퓨터 시스템은 본 발명을 구현하는데 필요하지 않다.

나타낸 제 1 컴퓨터 시스템은 시스템 관리의 사양 : 본 명세서에 참조되는, UK ISBN 1-85912-190-X로서 Open Group(이전에는 X/Open)에 의해 공표된 문헌 번호 C429인, 데이터 저장 관리(XDSM) API를 따른다. 이 문헌은 http://www.opengroup.org에서 온라인으로 입수 가능하고, 데이터 관리 API(DMAPI) 컴플라이언트 애플리케이션들에 대한 사양들을 설계한다. 본 명세서에 설명하는 데이터 관리 기능에 대한 지원을 제공하는 경우에, 다른 운영 체제들이 사용될 수도 있다.

유닉스 또는 리눅스 시스템에서, 운영 체제은 크기, 소유권, 날짜, 및 허가와 같은 표준 파일시스템 정보를 저장하기 위해 아이노드들을 사용한다. 또한, 아이노드는XDSM 사양에 의해 특정될 때, 확장된 속성/메타데이터 및 영역 정보를 포함하는 DMAPI 확장 데이터에 링크를 저장하기 위해 사용될 수도 있다. 바람직하게는, DMAPI 확장 데이터는 일 실시예에서 .DMATTR이라 칭하는 DMAPI 확장 데이터 파일(60)에 저장된다. DMAPI 확장 데이터(60)는 프런트 엔드(12) 및 가능하면 백 엔드(14)에 저장된, 단일 파일 또는 스팬 여러 파일들일 수도 있다. 프런트 엔드(12)의 저장은 메모리에 캐시할 때 더 빠른 액세스를 제공한다. 도 3은 파일 시스템(16)에서 아이노드들(62)과 DMAPI 확장 데이터 파일(60)사이의 논리 관계를 도시한다. 소자들이 그룹으로 함께 도시되었지만, 이것은 디스크상의 물리적 위치에 반드시 영향을 미치지 않는다는 것을 이해할 것이다. DMAPI 확장 데이터 파일(60)은 도 3에 도시한 바와 같이, 아이노드 번호로 인덱스된 확장된 속성들과 영역들의 테이블로서 구현될 수도 있다. 또 다른 장치가 도 4에 도시한 바와 같이, 자체 확장 블록(64)에 대한 각 아이노드(62)포인트를 갖는다. DMATTR 파일(60)에 DMAPI 정보를 저장하는 것은 파일에 대한 DMAPI 정보가 아이노드(62) 및 DMAPI 확장 블록(64)을 판독하지 않고 판독될 수 있게 하고, 이것은 많은 파일들을 정밀 조사할 때 유리하다. 이러한 정보는 파일 시스템(16)의 일부분으로서 저장될 수도 있고, 아이노드 정보가 어떻게 저장되는지와 유사하다.

확장된 속성들은 파일이 이송되었는지 여부, 소거되었는지 여부, 및 디렉토리 경로, 객체 ID 등의 형태로 백 엔드(14)상의 컨테이너 파일(76)로의 링크와 같은 정보의 트랙을 유지하도록 사용된다. 영역 정보는 파티션의 데이터가 로컬적으로 존재하는지 여부, 데이터가 더티이고 이송이 필요한지 여부, 및 대응하는 로컬 파일에서의 데이터의 위치와 같은 파일의 파티션들에 관한 정보를 포함한다. 플래그들이 사용될 수도 있고, 로컬 파일에서의 데이터의 위치가 오프셋과 길이에 관한 정보에 의해 표시될 수도 있다. 영역 정보는 파일의 매핑된 영역, 예를 들어, dm_영역_판독, dm_영역_기록, dm_영역_절단에서 데이터가 액세스되거나 변경될 때, 생성되는 이벤트의 세트를 특정하는 필드를 포함할 수도 있다. 플래그들은 데이터가 내재하거나, 더티이고 재-이송이 필요한지를 나타내도록 설정될 수도 있다. 파티션들이 동적으로 사이즈되는 경우에, 파티션의 사이즈에 관한 정보 또한 유지될 수도 있다. 파일을 매핑하는 영역의 번호는, 영역 정보가 데이터 위치의 트랙을 유지하기 위해 사용되기 때문에 데이터가 액세스될 때 증가할 수도 있다.

파일(72)이 백 엔드(14)로 이송될 때, 도 5에 도시한 바와 같이, 파티션(70)으로 분할된다. 파티션(70)의 사이즈는 고정될 수도 있거나 동적으로 변화할 수도 있다. 고정된 파티션들은 시스템 파일에 저장된 구성 또는 환경 변수에 의해 정의되는 파티션 사이즈를 가질 수도 있다. 파티션 사이즈는 파일시스템 특성, 파일들의 사이즈, 및 데이터 액세스의 패턴에 따라 선택될 수 있다. 더 큰 파티션 사이즈가 더 많은 대기시간, 대역폭 사용, 및 버전닝을 위해 백 엔드(14)에서 사용되는 더 많은 공간을 발생시킬 수도 있기 때문에 파티션 사이즈는 너무 커서는 안된다. 한편, 너무 작은 파티션 사이즈는, 더 많은 파티션을 관리해야 할 때, 하우스키핑 요청을 증가시킨다. 큰 데이터베이스에 있어서, 100 메가바이트(MB)의 파티션 사이즈가 사용될 수도 있다. 따라서, 예를 들어, 2GB 파일은 백 엔드(14)에 대해 20개의 100MB 파티션들로 분할된다. 일 구현에서, 오라클 데이터베이스용으로, 백 엔드(14)에 대해 9840 테이프들, 및 사이즈 128MB의 16개 파티션들을 갖는 시스템이 사용된다. 파티션 사이즈에 영향을 미치는 어떠한 인자들은 데이터를 필요로 하는 애플리케이션의 액세스 패턴, 백 엔드(14)와 프런트 엔드(12)사이의 데이터 전송 속도, 데이터 전송을 위한 백 엔드(14)에서의 기록 매체의 속도, 및 백 엔드(14)매체의 대기시간이다.(테이프 30과 같은)더 느린 포지셔닝 시간을 갖는 백 엔드 매체는 더 큰 파티션 사이즈에 유리한 영향을 준다.

파일(72)을 파티션함으로써, 시스템은 더 작은 부분(70)으로 이동할 수 있다. 애플리케이션이 2GB 파일로부터 데이터의 작은 부분으로의 데이터 액세스를 요청하는 경우에, 상기 데이터를 포함하는 특정한 100MB 파티션만이 로컬 파일시스템상에 존재하지 않는 경우에 액세스를 위해 검색될 필요가 있다. 이것은, 데이터를 이동하기 위해 필요한 시간이 매우 작을 때 대기시간을 감소시키고, 이동되는 데이터 양이 작기 때문에 대역폭 사용을 감소시킨다. 유사하게는, 데이터 파일(72)의 작은 부분만이 연속적으로 변형되는 경우에, 데이터의 변형된 부분들을 포함하는 파티션들(70)만이 백 엔드(14)로 이송될 필요가 있다.

도 6에 도시한 바와 같이, 제 1 컴퓨터 시스템은 3개의 데몬 : 이벤트 데몬 dxdbmigd(80), 이송 데몬 dxdbmigwatch(82), 및 소거 데몬 dxdbpurgewatch(84)에서 동작하도록 구성된다. 스레드되는 하나의 데몬만을 포함하는 임의의 수의 데몬들이 사용될 수도 있고, 데몬들 이외의 다른 접근방법이 사용될 수도 있다. 예를 들어, 윈도우즈 시스템은 시스템 에이전트 및 서비스를 사용할 수도 있다. 이벤트 데몬(80)은 파일 데이터가 액세스될 때를 트랩한다. 요청된 데이터가 프런트 엔드(12)상의 로컬 파일시스템(16)에 존재하지 않는 경우에, 이벤트 데몬(80)은 백 엔드(14)로부터 로컬 파일시스템(16)으로 데이터를 카피하고, 그 후, 데이터 액세스가 발생한다. 이송 데몬(82)은 데이터가 프런트 엔드(12)로부터 백 엔드(14)로 이송될 필요가 있는 파일들을 찾는다. 데이터 이송을 필요로 하는 파일을 식별하면, 프런트 엔드(12)로부터 백 엔드(14)로 데이터를 카피한다. 소거 데몬(84)은 데이터가 로컬 파일시스템(16)상에 더 이상 필요하지 않는 파일들을 찾고, 불필요한 데이터를 제거한다. 이송 및 소거 데몬(82 및 84)모두는, 본 명세서에 설명하는 이송 및 소거 후보들의 효율적 탐색이 거의 비용을 들이지 않고 이송 및 소거를 룩킹 업하는 것을 허용하기 때문에, 5 분 간격과 같이 주기적으로 구동하도록 구성될 수도 있다.

도 8의 단계 100을 참조하면, 이송 데몬(82)(또는 스레드되는 단일 데몬)은, 본 명세서에 설명하는 바와 같이, 파일들이 이송될 필요가 있는지의 여부를 결정하기 위해 .DMATTR 파일(60)에 저장된 속성 정보를 사용하거나, 확장 블록(64)에 저장된 속성 정보를 사용할 수도 있다. 파일(72)이 사전에 이송되지 않은 경우에, 파일은 고정된 사이즈이거나 동적으로 결정되는 파티션들(70)로 분할된다. 파티션 사이즈는, 데이터 액세스의 주파수, 얼마나 많은 연속 데이터가 액세스 마다 판독되는지, 및 다른 액세스 패턴 정보와 같은 인자들에 기초하여 동적으로 결정될 수도 있다. 이송 데몬(82)은 다양한 작업들을 처리하기 위해 다른 프로세스들을 포크(fork)할 수도 있다. 세마포어들(semaphores), 파일 락들, 및 다른 방법들이 사전-이송 프로세싱, 데이터 이송, 또는 파일이 이송 동안 변화하는지 여부(그러한 경우, 현재 이송을 실패하고 다음의 이송을 시도)를 검사하는 동안 파일을 보호하도록 사용될 수도 있다.

이송 프로세스는 파일을 전적으로 락하고(단계 102), 속성 및 영역 정보를 판독하고(단계 104), 파일이 이송될 필요가 있는지 여부를 결정한다(단계 106). 이송이 필요없는 경우에, 락이 드롭된다(단계 108). 그렇지 않으면, 영역 정보, 파일 사이즈, 및 파티션 사이즈는 어떤 피스의 파일이 이송될 필요가 있는지를 결정하기 위해 사용된다(단계 110). 파일이 이전에 이송된 경우에(단계 112), 이전 이송들을 나타내는 정보를 포함하는 컨테이너 파일(76)이 있고, 이 파일은 파일에 대한 새로운 버전 번호를 결정하기 위해 판독된다. 파일이 이송되지 않은 경우에, 이 버전 번호는 1로 가정된다. 새로운 데이터 또는 최종 이송으로 인한 변경된 데이터만이 백 엔드(14)로 이송된다. 데이터는 고정 또는 동적일 수도 있는 파티션 사이즈에 따라 파티션된다(단계 114). 락이 드롭되어서, 파일을 사용하는 다른 프로세싱은 이송이 발생하는 동안 계속될 수 있다(단계 116).

단계 120에서, 이송을 필요로 하는 파티션들(70)은 프런트 엔드(12)에 대한 파일 액세스 시간을 변경시키지 않고 백 엔드(14)로 카피된다. 에러가 이러한 이송 동안 발생하는 경우에, 이송 시도는 다음의 이송 구동 동안 재시도된다.(단계 124). 이송이 성공인 경우에, 파일은 단계 126에서 다시 락되고, 파일 속성 및 영역 정보는 파일이 데이터 이동 동안 변경되었는지 여부를 결정하기 위해 다시 판독 및 사용된다(단계 128). 파일이 변경된 경우에, 락이 드롭되고(단계 132), 데이터가 일치하지 않기 때문에, 이송은 실패하고, 다음에 재시도된다(단계 124). 파일에 대한 변경들이 데이터 이동 동안 이루어지지 않는 경우에, 파일 정보는 파일이 성공적으로 이송되었다는 것을 나타내기 위해 갱신된다(단계 134). (DMAPI/XDSM과 같은)확장된 속성 및 영역 정보가 갱신되고, 경로명, 사이즈, 소유자, 허가, 및 다른 파일 속성을 포함하는 파일에 관한 정보가 데이터 파일과 관련된 *.cont 파일이라 칭하는 컨테이너 파이(76)에 기록된다. 또한, 버저닝 정보를 포함하는, 백 엔드(14)에 저장된 파티션들에 관한 정보가 컨테이너 파일(76)에 기록된다.

파일 상태는 일관성을 보장하기 위해 소정의 순서로 갱신되어야 한다. 도 9의 단계 140에서, 파일이 소거되지 않았는지, 파일의 파티션 사이즈가 설정(필요한 경우에)되었는지, 백 엔드(14)파일들의 위치가 설정되었는지를 나타내도록 속성이 설정되고, 정보는 파일시스템(16)을 통해 기록된다(단계 142). 이것은, 크래쉬(crash)의 경우에, 새로운 상태로 포워드 또는 이전의 상태로 백 롤링함으로써 파일이 액세스되는 것을 가능하게 하도록 충분한 정보가 파일에 제공되는 것을 보장한다. 새로운 버전의 *.cont 파일(76)은, *.cont 파일(76)이 파일의 구(old)상태 또는 새로운 상태를 포함한다는 것을 보장하는 것과 같은 방법으로 기록된다(단계 144). 단계 146에서, 모든 파일 데이터가 백 엔드(14)로 성공적으로 이송되었다는 것을 나타내기 위해 DMAPI/XDSM 인터페이스를 통해 기록되고, 다음으로, 단계 148에서, .DMATTR 파일(60)이 동기화된다(현저한 정보가 디스크에 기록된다). 이것이 실패하는 경우에, 구 영역 정보는 여전히 유효하고, 장래의 이송이 장래의 이송 시도 동안 계속될 수 있다. DMAPI/XDSM 속성은 이송될 때 파일을 표시하기 위해 갱신된다(단계 150). 이것은 데이터가 백 엔드(14)의 어디에 저장되는지, 이송의 시간을 나타내고, 이송될 때 파일을 표시하도록 메타데이터를 설정하는 것을 포함한다. 메타데이터는 임의의 시간에서의 실패는 일관된 상태의 파일을 항상 제거한다는 방법으로 기록된다.

이것은 실패의 경우에 데이터 손상을 보호하고, 파일이 유효하지 못한 파일 데이터로의 액세스를 허용하는 상태가 되는 것을 방지한다. 영역 정보에 저장된 상태, 파일 메타데이터, 및 백 엔드 버전 파일(*.cont 파일)은 필요한 경우에 소거 이후에 파일을 재저장하거나 국부적으로 관리된 디스크들이 분실되거나 파일이 부주의하게 제거된 경우에 복구하는데 충분하다.

각 데이터 파일(72)은 그와 관련된 *.cont 파일(76)을 가질 수도 있지만, 데이터 파일의 명칭 또는 객체 ID와 같은 다른 식별자에 의해 인덱스될 수 있는 단일 컨테이너 파일에 다중 데이터 파일들에 대한 *,cont 정보를 저장할 수 있다. 파일이 사전에 이송된 경우에, .DMATTR 파일(60)의 영역 정보는 어떤 파티션들이 더티; 즉, 최종 이송으로 인해 변형되었는지를 결정하기 위해 검사된다. 변형된 파티션들은 백 엔드(14)로 카피되고, 파티션들의 기존의 카피들을 오버라이트(overwrite)하지 않기 위해 버전될 수도 있다. *.cont 파일(76)은 도 7에 도시한 바와 같이 버전의 트랙을 유지한다.

예를 들어, *.cont 파일(76)이, 파티션의 버전(54)이 백 엔드(14)에 이미 존재한다는 것을 나타내는 경우에, 변형된 파티션은 버전(54)을 변경 또는 오버라이팅하지 않고 버전(55)으로서 기록되고, *.cont 파일(76)은 동작을 반영하기 위해 갱신된다. 사실, *.cont 파일은 파일 델타들의 트랙을 유지한다. *.cont 파일(76)이 스냅샷을 유효하게 유지; 즉, 임의의 날짜 및 시간에서, 데이터 파일(72)이 어떻게 보이는지를 결정할 수 있기 때문에, 임의의 포인트 인 타임에서 존재할 때 관련된 파일을 복구할 필요가 있는 정보를 갖는다. 이송이 완료된(예를 들어, 이송된 데이터가 테이프에 성공적으로 기록된) 이후에, 새롭게 이송된 파티션들에 관한 정보는 컨테이너 파일(76)에 저장된다. .DMATTR 파일(60)은, 파일이 제 1 시간동안 이송되는 경우에 백 엔드(14)의 컨테이너 파일에 대한 링크를 따라 파일이 이송되었다는 것을 나타내도록 갱신된다. 변경된 파티션들이 이송되는 경우에, 영역 정보는, 파티션들이 더 이상 더티가 아니고 따라서 더 이상 이송의 필요성이 없다는 것을 나타내도록 갱신된다. 따라서, 프런트 엔드(12)상의 파일과 백 엔드(14)상의 파티션들 사이에 링크들이 있고, .DMATTR 파일(60)과 *.cont 파일(76)에 저장된다.

이송을 예시하기 위해, 사전에 이송되지 않은 ABC라 불리는 프런트 엔드(12)상에 데이터 파일이 있는 경우에, 유일한 경로명, 즉, 123이 백 엔드(14)에서 데이터 파일에 대해 선택된다. ABC 파일은 객체 관리 시스템 구성에 의해 결정된 파티션 사이즈를 갖는 파티션들로 분할된다. 이들 파티션들은 유일한 경로명, 파티션 번호, 및 버전 번호, 예를 들어, 123.파티션1.버전1, 123.파티션2.버전1 내지 123.파티션N.버전1을 나타내는 개별 파일들로서 백 엔드(14)로 카피된다. 그 후, 123.cont 파일이 기록되는데, 이것은 로컬 파일시스템(16)상의 파일명칭, 파티션들의 명칭들, 및 파티션들의 버전들을 포함하는, 이송 동안 무엇이 행해졌는지를 설명한다. 추가의 정보가 .DMATTR 파일(60)의 로컬 파일시스템(16)또는 파일시스템의 다른 위치에 기록된다. 다른 위치에 위치될 수도 있지만, 로컬 파일시스템(16)상의 배치는 액세스의 속도를 빠르게 한다. 또한, .DMATTR 파일(60)은, 크래시의 경우에 일관성을 보장하기 위해 주로 디스크상의 파일과 캐시된 파일을 동기화하는 것을 필요로 하지만, 프런트 엔드(12)상의 메모리에서 캐시될 수 있다. 기록된 속성은, ABC가 파일 123으로 이송되었는지의 표시, 이송이 언제 발생하고 파일이 어디로 이송되었는지를 나타내는 타임스탬프, 및 파일이 백 엔드(14)로 성공적으로 이송되었다는 표시를 포함한다.

도 10을 참조하면, 소거 데몬(84)(또는 스레드된 데몬)은 .DMATTR 파일(60)에 저장된 속성 정보를 사용하여, (이송이 필요없는) 이송되었지만 소거되지 않은 파일을 식별한다(단계 200). 소거 데몬(84)은, 자유 공간(free space)이 로컬 파일시스템(16)에 대해 필요하다는 것을 결정한 이후에 상기 식별을 행할 수도 있고, 충분한 자유 공간이 사용 가능할 때 소거를 중지한다. 단계 202에서, 소거 후보들은 사용자가 구성할 수도 있는 실제 소거 정책(policy)에 따라 분류된다. 다른 정책들이 파일시스템(16)상에 저장된 데이터의 특성들, 파일시스템(16)상의 데이터를 사용하는 애플리케이션들, 및 데이터 액세스 패턴들에 기초하여 선택될 수도 있지만, LRU(가장 최근 사용 시스템)가 소거 정책로서 사용될 수도 있다. 정책들은 파일 레벨 또는 파티션 레벨에 적용될 수도 있다. 소거 데몬(84)은 파일의 파티션들내의 최종 액세스의 시간, 액세스의 주파수등을 결정하기 위해 확장된 속성들내의 정보를 사용할 수도 있다. 소거 정책에 기초하여, 소거 데몬(84)은 소거될 파티션들을 식별한다. 예를 들어, 소거 데몬(84)은 LRU 알고리즘을 사용하여 파일들을 분류하고, 소거를 위해 선택된 파일들내에서, 특정 날짜 보다 오래된 최종 액세스 날짜를 갖는 파티션들을 선택한다.

파일 락들, 세마포어들, 또는 다른 방법들이 데이터 손실 또는 손상을 방지하기 위해 사용된다. 소거 프로세스가 소거 후보들의 리스트를 컴파일하고, 파일이 소거를 위해 선택된 이후에, 파일은 락된다(단계 204). 속성 및 영역 정보가 판독되고(단계 206), 리스트가 컴파일되었기 때문에 파일이 액세스되었는지, 즉, 여전히 소거 후보인지를 알아보기 위해 검사된다(단계 208). 그렇지 않은 경우에, 파일은 소거되지 않고, 락이 드롭된다(단계 210). 파일이 여전히 소거 후보인 경우에, 파일 영역 정보는 전체 파일이 소거되었다는 것을 나타내도록 설정된다(단계 212). 소거 데몬(84)은 선택된 파티션들에 대응하는 파일로부터 로컬 데이터를 제거한다(단계 214). DMAPI-컴플라이언트 시스템에서, 소거 데몬(84)은 로컬 데이터를 제거하기 위해 dm_punch_hole()을 사용한다. 운영 체제의 능력에 따라, 로컬 파일(72)은, 대부분의 운영 체제들과 공통일 때 오프셋으로부터 파일의 엔드로 절단될 수도 있거나, 홀이 AIX에 의해 제공되는 경우에, 파일의 중간으로 펀치될 수도 있다. 제거될 데이터는 파일의 시작부일 수도 있고, 이러한 경우에, 스터브(74)는 (도 5에 도시한 바와 같이) 좌측이다.

로컬 데이터가 제거된 이후에, 속성 및 영역 정보는 데이터의 소거를 반영하도록 갱신된다(단계 216). 영역 정보는, 실제로 소거된 데이터가 로컬 파일시스템(16)에 더 이상 존재하지 않는다는 것을 나타내고, (스터브(74)를 제외한)전체 파일이 소거된 경우에, 속성은, 파일이 소거되었다는 것을 나타낸다. 파일의 어떠한 일부분이 남아 있는 경우에, 파일은 계속 소거 후보이다. 파일 메타데이터가 갱신된 이후에, 락이 파일로부터 제거된다(단계 218). 이것은 시스템 크래시 또는 다른 고장의 경우에 파일을 보호한다. 파일이 아직 소거된 것으로서 표시되지 않기 때문에 파일은 여전히 소거 후보로서 보이지만, 파티션들이 소거 동작 이전에 소거된 것으로서 표시되기 때문에 액세스될 때 파일내의 모든 파티션들은 재배를 초래한다. 어떤 데이터가 여전히 로컬일 수도 있지만, 에러가 소거 동작 동안 발생되는 경우에, 어떤 것이 소거되었는지를 알 수 없을 수도 있다. 따라서, 소거 프로세스는 소거될 때의 모든 파티션들을 표시하고, 소거가 완료된 이후에, 어떤 파티션들이 여전히 존재하는지를 나타내도록 영역 정보를 갱신한다. 메타데이터가 실패를 갱신하는 경우에, 파일 데이터의 일부 또는 전부가 로컬 파일로부터 이미 소거되었더라도, 파일은 여전히 소거 후보를 나타낸다. 설명한 시퀀스는 데이터 손상을 방지하려는 의도이지만, 영역 정보, 파일 데이터 제거, 및 파일 메타데이터 갱신이 일관성을 보장하도록 동기화되는 한은 다른 접근방법들이 가능하다. 이것은 구식 데이터가 액세스될 수 있는 상반되는 상태에서 파일을 남기는 것을 피한다.

통상적으로, 파일(72)은 애플리케이션들에 의해 스캔되는 파일의 시작부에서 헤더 및 다른 빈번하게 사용된 정보를 포함하고, 파일을 소거할 때, 그 자리에 스터브(74)를 남기는 것은 데이터 액세스 시간의 속도를 빠르게 할 수도 있다. 사용자는, 빈번하게 액세스되는 파일(72)의 시작부에 정보가 있는지의 여부, 및 파일(72)의 시작부에 얼마나 많은 데이터가 액세스되는지와 같은 정보에 기초하여 스터브(74)의 길이를 정의할 수도 있다. 예를 들어, 오라클은 시작 시간과 같이, 오라클이 모든 오라클 데이터 파일에 액세스할 때, 데이터 파일의 데이터에 빈번하게 액세스하기 때문에, 오라클 데이터베이스는 최소 128KB의 스터브 사이즈를 요청할 수도 있다. 스터브 데이터가 내장되어 있지 않는 경우에, 오라클은 백 엔드(14)로부터 데이터가 복구될 때 까지 스톨(stall)하고, 이것은 많은 테이프 장착(mounts)(또는 CD와 같은 다른 저장 매체의 장착)을 의미할 수도 있다. 스터브(74)는 백 엔드(14)에 파일들 또는 객체들로서 버전 및 저장될 수도 있다.

도 11에서, 이벤트 데몬(80)또는 스레드된 데몬은 액세스 이벤트들을 트랩하고, 데이터 액세스 액티비티의 트랙을 유지한다(단계 300). 데이터 액세스 요청이 송신될 때, 프로세싱은 데이터 액세스가(기록 또는 절단과 같이)파일을 변형시키는 판독 또는 액세스인지의 여부에 따른다(단계 302). 데이터 액세스가 판독인 경우에(단계 304), 요청된 데이터가 로컬 파일시스템(16)에 존재하는지, 즉, 액세스되는 파일의 일부분에 대응하는 파티션이 존재하는 것으로서 표시된다는 것을 영역 정보가 나타내는지를 결정하기 위해 .DMATTR 파일(60)의 영역 정보가 검사된다. 요청된 데이터가 존재하는 경우에(단계 306), 액세스 요청은 파일시스템으로 패스되고(단계 308), 파일 속성 및 영역 정보는 액세스를 반영하도록 갱신될 수도 있다(단계 324). 요청된 데이터가 존재하지 않는 경우에, 이벤트 데몬(80), 또는 이벤트 데몬(80)으로부터 이벤트를 수신하는 또 다른 프로세스는 파일을 락하고 영역 및 속성 정보를 검사하여(단계 310), 프로세싱이 필요한지 여부를 결정한다(단계 312). 단계 314에서, 이전의 이벤트 프로세싱으로 인하여 프로세싱이 요청되지 않는 경우에, 락이 드롭되고, 이벤트에 대한 응답이 생성되고, 이것은 I/O 요청을 완료하기 위해 대기하는 프로세스를 웨이크 업(wake up)한다. 프로세스가 요청될 때, 파일은 소거 가능한 것으로서 표시되고, 메타데이터는 동기화되고, 이벤트 프로세싱을 완료하기 위해 필요한 파일 데이터가 결정되고, 백 엔드(14)파일들의 위치가 결정되고, *.cont 파일이 판독되고, 파일에 대해 락이 드롭된다(단계 316).

파일은 데이터 이동 동안 락되지 않고, 이것은 로컬 파일시스템(16)상에 이미 내장된 데이터의 프로세싱을 허용한다. 필요한 파티션들이 백 엔드(14)로부터 판독되고 프런트 엔드(12)상의 로컬 파일시스템(16)에 기록된다(단계 318). 파일은 다시 독점적으로 락되고(단계 320), 영역 및 속성 정보가 일관된 방식으로 갱신되고(단계 322), 락이 드롭된다. 응답은 판독 요청을 완료하기 위해 프로세스를 웨이크 업하는, 대기하는 프로세스로 전송된다(단계 314). 이 데이터로의 장래의 액세스들은 데이터가 다시 소거되지 않는 경우에 재저장 이벤트를 생성하지 않는다.

데이터 액세스 패턴들에 기초하여, 예상 파티션 검색이 또한 사용될 수도 있고, 즉, 데이터 액세스 패턴들에 관한 정보가 기록될 수 있고, 특정한 파티션으로의 액세스가 또 다른 파티션으로의 액세스를 빈번하게 발생시킨다고 결정되는 경우에, 상기 파티션은 사전에 검색될 수도 있다.

단계 324에서, 이벤트 데몬(80)이 데이터 액세스 이벤트를 처리한 이후에, .DMATTR 파일(60)은, 소거 폴리스가 파티션 레벨에서 데이터 액세스 정보를 사용할 때와 같이, 액세스된 파일의 일부분에 대응하는 파티션(들)에 대한 액세스의 시간을 나타내도록 갱신될 수도 있다. 시스템은 파일 액세스의 시간을 나타내도록 파일 속성을 갱신한다.

액세스 요청이 기록인 경우에, 영역들은 액세스 시간을 갱신하도록 변형되고, 데이터에 대응하는 파티션들은 더티로서 표시(따라서, 이송될 필요가 있다)된다(단계 326). 이러한 경우에, 파일은 독점적으로 락되고, 이벤트는 프로세싱이 필요한지 여부를 결정하기 위해 검사된다(단계 328). 그렇지 않은 경우에, 락이 드롭되고, 이벤트는 프로세싱 종료에 응답한다(단계 330). 프로세싱이 필요한 경우에(단계 332), 메타데이터는 파일이 이송 후보이고, 또한 데이터가 막 변경되었기 때문에 이송 후보이다는 것을 나타내기 위해 갱신된다. 파일 메타데이터, 영역 정보, 및 *.cont 파일은 파일의 상태를 결정하기 위해 판독된다. 이벤트를 생성한 파일의 영역이 결정되고, 데이터가 국부적으로 존재하지 않는다는 것을 영역 정보가 나타내는 경우에(단계 336), 락이 드롭되고, 데이터는 전술한 판독 프로세스와 유사한 방식으로 이동된다(단계 338). 데이터가 이미 내장되어 있는 경우에, 데이터는 백 엔드(14)로부터 이동할 필요가 없다. 단계 340에서, 데이터가 재배치된 이후에, 파일은 다시 락되고, 메타데이터 및 영역 정보는, 파일내의 어떠한 데이터가 이송될 필요가 있는지, 및 파일의 일부가 변경되었는지를 나타내도록 갱신된다. 독점적인 락이 드롭되고 응답이 대기하는 프로세스로 전송된다(단계 342).

이벤트 처리를 예시하기 위해, 구성에 의해 정의된 길이를 갖는 스터브(74)를 제외하고 모두 이송 및 소거된 N개의 파티션들을 갖는 파일 ABC에 있어서, 파티션(77)의 데이터로의 데이터 액세스는 이벤트 데몬(80)에 의해 트랩된다. 이것을 도 12에 도시하였다. 데몬은, 파티션(77)의 데이터가 로컬 파일시스템(16)상에 존재하지 않는다는 것을 결정하고, .DMATTR 파일(60)를 검사하고, 대응하는 컨테이너 파일이 백 엔드(14)상의 123.cnt이다는 것을 결정한다. 대응하는 백 엔드 파일(123)의 파티션(77)에 대한 요청이 전송된다. 123.cont는 버전(55)이 파티션(77)의 최근 버전이다는 것을 나타내고, 따라서, 123.파티션77.버전55는 프런트 엔드(12)로 검색된다. 디스크에 파티션을 재저장한 이후에, 속성 및 영역 정보가 갱신된다.

전체 파일들보다는 파일들의 세그먼트들을 이송 및 검색함으로써, 시스템은 크고 시간을 소비하는 파일 전송을 피한다. 예를 들어, 데이터베이스 파일들은 매우 큰 경향이 있어서, 기가바이트로 측정된다. 이송 및 검색하는 동안, 특히, 오라클과 같은 데이터베이스 애플리케이션이 테이블의 매우 작은 부분(예를 들어, 로우들(rows))에만 액세스할 수도 있을 때 전체 파일을 앞뒤로 이동하는 것은 실행 불가능하다. 예를 들어, 오라클은 동시에 전체 파일을 스캔하지 못한다. 오히려, 제 1 파일로 최종적으로 컴백하고 더 많은 데이터를 스캔할 때 까지 하나의 데이터베이스를 통해 부분적으로 스캔하고, 또 다른 파일로 계속한다. 풀(full)파일 검색을 사용하는 것은 과다상태(thrashing)와 더 긴 검색 시간을 초래한다.

또한, 본 명세서에 설명하는 파티션들의 관리와 파일들의 파티셔닝을 구현하기 위해 요청되지는 않지만, 시스템은 이송 및 소거 후보들을 효율적으로 탐색하여 그들의 경로명을 얻도록 구성된다. 도 14에 도시한 바와 같이, 파일명칭들에 대한 명칭공간을 탐색하고 각 파일에 대한 아이노드 및 확장된 속성을 룩업하는 것이 하나의 접근방법이다. 어떠한 구성들에서, 아이노드는 확장된 속성을 포함하고, 제 2 룩업을 요청하고, 디스크 액세스에 대응하는 확장 블록에 대한 포인터를 포함한다. 도 13 및 14에 도시한 더욱 효율적인 접근방법에서, 시스템은 파일명칭들, 아이노드 번호들, 및 확장된 속성에 대한 DMAPI 확장 데이터 파일(60)(.DMATTR 파일)을 탐색한다(단계 350). 또한, 시스템은 상이한 파일 또는 여러 파일들을 사용하도록 구성될 수 있다. 이러한 방식으로, 시스템은, 아이노드, 및 명칭공간의 모든 파일에 대한 확장 블록을 룩업하지 않고 어떠한 파일들이 이송 또는 소거 후보인지를 빠르게 결정할 수 있다(단계 352). 후보에 대한 경로명을 생성하기 위해, 아이노드 번호가 경로명을 룩업하기 위해 사용된다(단계 354). 이것은 아이노드들 및 경로명들의 리스트에서 역 룩업을 사용하여 행해질 수 있다. 리스트는 동일한 파일, .DMATTR, 또는 개별 파일 또는 파일들의 그룹에 테이블로서 저장될 수도 있다. 이러한 구성을 사용하여, 시스템은, 이송 및 소거된 파일들을 포함하는 모든 파일에 대한 정보를 검사하는 것 대신에, 이송 및 소거 후보들로서 식별된 파일들에 대한 아이노드들만 룩업한다. 이것은, 이송 및 소거를 위해 요청되는 시스템 부하 및 실행 시간을 현저하게 감소시킨다. 예를 들어, 어떤 파일들이 이송을 요청하는지를 결정하는데 있어서, 본 명세서에 설명한 효율적인 탐색을 사용하는 시스템은 1 분 이하에서 이송 및 소거 후보들에 대한 100만개 파일들을 갖는 파일시스템을 검사할 수 있다. 하나의 이송 후보만을 갖는 100개 파일들을 갖는 솔라리스(Solaris)머신은 명칭공간 탐색으로는 이전에 20 분이 걸리던 것에 비하여, 하나의 파일을 찾기 위해 10 초가 걸린다. 이러한 접근방법은, 다른 운영 체제들과 파일 시스템들에 확장될 수도 있지만, 리눅스 및 솔라리스와 같은 유닉스-형 운영 체제들을 사용하는 NFS-형 파일 시스템들, XFS, UFS, 베리타스, 및 유사한 파일 시스템들과 사용될 수도 있다.

본 명세서에서 설명하는 컨테이너 파일들(76)의 사용은, 도 15 및 16에 도시한 바와 같이, (하나의 파일시스템의 컨텐츠를 또 다른 파일시스템의 컨텐츠에 복사하는 것은 종종 매우 시간을 소모하는 프로세스인)모든 데이터를 카피할 필요없이 하나의 컴퓨터 시스템으로부터의 데이터를 또 다른 컴퓨터 시스템(머신 B)에 사용 가능하게 한다. 머신 B는 백 엔드(14)상의 머신 A의 컨테이너 파일들을 사용하도록 구성될 수 있다(단계 400). 각 컨테이너 파일(76)은 머신 B가 로컬 파일시스템상에 새로운 파일을 생성하기 위해 사용할 수도 있는 사이즈, 소유자, 허가, 및 경로와 같은 파일 속성에 관한 정보를 포함한다. 머신 B가 *.cont 파일을 판독한 이후에(단계 402), 새로운 파일이 생성되고(단계 404), 새로운 파일의 사이즈가 *.cont 파일(76)에서 특정된 사이즈로 설정되고(단계 406), 단계 408에서, (파일이 소거되었더라도)할당된 공간이 사용되고 있지 않아서(freed), 머신 B의 파일시스템상에 스터브 파일을 생성한다. .DMATTR 파일(60)또는 다른 확장 데이터 블록 또는 파일이 생성되고, 속성 및 영역들이 설정된다(단계 410). 머신 B가 데이터를 변형시켜서 그것을 백 엔드(14)로 이송할 때, 필요에 기초하여 행해질 수 있지만, 머신 B에 유일한 컨테이너(*.cont)파일들은 백 엔드(14)에 기록된다(단계 412). 머신 B가 동작할 때, 데이터 액세스 요구들은 요청된 데이터가 머신 B의 로컬 파일시스템상에 존재하지 않고, 필요한 파티션들이 백 엔드(14)로부터 머신 B의 로컬 파일시스템으로 카피된다는 결정을 발생시킨다(단계 414). 파일 속성 및 영역 정보는 전술한 바와 동일한 방식으로 머신 B상에서 갱신된다. 머신 B가 데이터를 변형하는 경우에, (도 16에 B의 변형된 데이터로서 도시한 바와 같은)변형된 파티션들이 백 엔드(14)에 기록되고 변화에 관한 정보가 머신 B의 컨테이너 파일들(*.cont 파일로 도시함)에 저장된다(단계 416). 머신 A는 자체의 파티션들과 자체의 컨테이너 파일들(76)에 변화에 관한 정보를 저장한다(단계 418). 각 컴퓨터 시스템은 백 엔드(14)에 자체의 변형된 파티션을 기록한다. 각 컴퓨터 시스템은 자체의 컨테이너 파일들을 사용하고, 따라서, 데이터의 자체의 버전을 갖는다.

전술한 개시물 및 실시예들은, 본 발명이 많은 다른 사용에 유익하다는 것이 명백하지만, 컴퓨터 시스템들에서 객체 관리의 효율성을 증가시키는 본 발명의 유용성을 설명한다. 본 발명은, 파일의 일부가 액세스되고 파일의 모든 데이터를 액세스할 필요없이 검색될 수도 있는 데이터베이스, 비디오, 오디오, 및 임의의 애플리케이션에서 특별한 유용성을 갖는다.

명확함을 위해, 본 명세서의 프로세스들 및 방법들을 특정한 흐름을 사용하여 설명하였지만, 본 발명의 사상에서 벗어나지 않고 다른 시퀀스들이 사용될 수도 있고 어떠한 시퀀스들이 병렬로 수행될 수도 있다는 것을 이해할 것이다. 또한, 단계들은 재분할되거나 결합될 수도 있다. 본 명세서에 개시한 바와 같이, 본 발명에 따라 기록된 소프트웨어는 메모리 또는 CD-ROM과 같은 컴퓨터-판독 가능한 매체의 어떠한 형태에 저장되거나, 네트워크를 통해 송신되고, 프로세서에 의해 실행된다.

본 명세서에 인용한 모든 레퍼런스들은 참조를 위해 포함되는 것으로 의도된다. 본 발명을 특정한 실시예들과 관련하여 설명하였지만, 본 발명에 대한 변경들 및 변형들이 당업자에게 명백할 것이고 첨부한 청구범위의 범위와 동등물내에서 실시될 수도 있다는 것이 예상된다. 병렬 또는 부하-공유 장치에서 다중 컴퓨터를 사용하거나 다중 컴퓨터를 통해 작업들을 분배함으로써 하나 이상의 컴퓨터가 사용될 수도 있어서, 전체적으로, 객체 관리 시스템의 기능들을 수행하고, 즉, 단일 컴퓨터를 발생시킨다. 전술한 다양한 기능들은 단일 컴퓨터상에서 단일 프로세스 또는 프로세스들의 그룹에 의해 수행될 수도 있거나 여러 컴퓨터들을 통해 분배될 수도 있다. 프로세스들은 특정한 작업들을 처리하기 위해 다른 프로세스들을 인보크할 수도 있다. 개시한 원리들은 객체들 및 객체 저장장치 뿐만 아니라 파일시스템들에 적용한다. 본 실시예들은 예시적이고 한정하는 것이 아닌 것으로 간주하고, 본 발명은 본 명세서에 제공한 상세한 설명에 한정되지 않는다. 따라서, 개시물 및 이하의 청구범위는 본 발명의 사상 및 범위내에 있는 변경들 및 변형들을 모두 커버하는 것으로서 해석된다.

Claims

복수의 파일들, 및 상기 파일들과 관련된 아이노드(inode) 및 이송(migration) 또는 소거(purge) 정보를 포함하는 데이터 파일을 저장하도록 구성된 컴퓨터 시스템으로서,

상기 컴퓨터 시스템은 이송 또는 소거 후보들인 파일들을 식별하기 위해 상기 데이터 파일을 탐색하는 컴퓨터 시스템.
제 1 항에 있어서,

상기 데이터 파일은 상기 파일들과 관련된 복수의 경로명들을 더 포함하며,

상기 컴퓨터 시스템은 상기 복수의 경로명들로부터 후보 파일들의 경로명들을 얻도록 구성되는, 컴퓨터 시스템.
제 2 항에 있어서,

상기 컴퓨터 시스템은 상기 복수의 경로명들로부터 상기 경로명들을 얻기 위해 상기 후보 파일들과 관련된 아이노드들을 사용하여 상기 후보 파일들의 경로명들을 얻도록 구성되는, 컴퓨터 시스템.
제 3 항에 있어서,

상기 컴퓨터 시스템은 상기 아이노드들을 사용하여 상기 아이노드들과 관련된 경로명들을 찾기 위해 상기 복수의 경로명들로 인덱스하도록 구성되는, 컴퓨터 시스템.
제 4 항에 있어서,

상기 데이터 파일은 상기 컴퓨터 시스템 내의 파일이 변형되었는지 여부에 관한 정보를 포함하고, 상기 컴퓨터 시스템은 변형된 파일들을 식별함으로써 이송 후보들을 선택하도록 구성되는, 컴퓨터 시스템.
제 4 항에 있어서,

상기 데이터 파일은 상기 컴퓨터 시스템 내의 파일이 변형되었는지 여부, 및 최종 액세스의 시간에 관한 정보를 포함하고, 상기 컴퓨터 시스템은 소정의 값 보다 오래된 액세스 시간을 가진 변형되지 않은 파일들을 식별함으로써 소거 후보들을 선택하도록 구성되는, 컴퓨터 시스템.
제 1 항에 있어서,

상기 컴퓨터 시스템은 상기 파일들과 관련된 복수의 경로명들을 포함하는 제 2 데이터 파일을 저장하고, 상기 복수의 경로명들로부터 후보 파일들의 경로명들을 얻도록 구성되는, 컴퓨터 시스템.
제 7 항에 있어서,

상기 컴퓨터 시스템은 상기 후보 파일들과 관련된 아이노드들을 사용하여 상기 후보 파일들의 경로명들을 얻어서 상기 복수의 경로명들로 인덱스하도록 구성되는, 컴퓨터 시스템.
제 7 항에 있어서,

상기 제 2 데이터 파일은 상기 경로명들과 관련된 아이노드들을 포함하고, 상기 컴퓨터 시스템은 상기 제 2 데이터 파일에서 대응하는 아이노드들을 룩업함으로써 경로명들을 얻도록 구성되는, 컴퓨터 시스템.
제 9 항에 있어서,

상기 데이터 파일은 상기 컴퓨터 시스템내의 파일이 변형되었는지 여부 및 최종 액세스의 시간에 관한 정보를 포함하고, 상기 컴퓨터 시스템은 소정의 값보다 오래된 액세스 시간을 가진 변형되지 않은 파일들을 식별함으로써 후보들을 선택하도록 구성되는, 컴퓨터 시스템.
복수의 파일들 및 상기 파일들과 관련된 아이노드 및 이송 정보를 포함하는 데이터 파일을 저장하도록 구성된 컴퓨터 시스템에서 이송에 대한 후보들인 파일들을 식별하는 방법으로서,

상기 이송에 대한 후보들을 식별하기 위해 상기 데이터 파일을 탐색하는 단계를 포함하는, 파일 식별 방법.
제 11 항에 있어서,

상기 데이터 파일은 컴퓨터 시스템 내의 파일들이 변형되었는지 여부 및 최종 액세스의 시간에 관한 정보를 포함하고,

상기 데이터 파일을 탐색하는 단계는 소정의 값보다 오래된 최종 액세스의 시간을 가진 변형되지 않은 파일들을 찾는 단계를 포함하는, 파일 식별 방법.
제 12 항에 있어서,

상기 데이터 파일은 상기 파일들과 관련된 복수의 경로명들을 더 포함하고,

상기 복수의 경로명들로부터 후보 파일들의 경로명들을 얻는 단계를 포함하는 파일 식별 방법.
복수의 파일들 및 상기 파일들과 관련된 아이노드 및 이송 정보를 포함하는 데이터 파일을 저장하도록 구성되는 컴퓨터 시스템에서 이송 후보들인 파일들을 식별하는 컴퓨터 프로그램 제품으로서,

상기 이송 후보들을 식별하도록 상기 데이터 파일을 탐색하기 위해 내부에 포함된 머신 판독 가능한 코드를 가진 컴퓨터 사용 가능한 매체를 구비하는, 컴퓨터 프로그램 제품.
제 14 항에 있어서,

상기 데이터 파일은 상기 파일들과 관련된 복수의 경로명들을 더 포함하고,

상기 복수의 경로명들로부터 후보 파일들의 경로명을 얻는 단계를 더 포함하는, 컴퓨터 프로그램 제품.