KR20050001304A

KR20050001304A - 파일 시스템 백업 방법, 컴퓨터 판독 가능 기록 매체 및 데이터 처리 시스템

Info

Publication number: KR20050001304A
Application number: KR1020040036200A
Authority: KR
Inventors: 커랜로버트제이; 맥납다니엘엘; 미칼라로스디메트리오스케이; 소돈웨인에이; 슈머크프랭크비; 윌리제임스씨
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2003-06-24
Filing date: 2004-05-21
Publication date: 2005-01-06
Also published as: US20040267838A1; KR100600933B1; US7092976B2; JP4157858B2; JP2005018758A

Abstract

파일 시스템 백업은 먼저 최종 백업 동작 이후에 아이노드 번호(inode number)의 순서대로 변경되는 연관된 아이노드 번호를 포함하는 아이노드의 리스트를 작성하는 것에 의해 실행된다. 파일 시스템 내에 현재 존재하는 모든 파일에 대한 파일 네임 및 아이노드 번호를 갖는 테이블을 또한 작성한다. 이 리스트는 아이노드 번호에 의해 분류되고, 테이블 및 리스트는 통합되어 어떤 파일이 백업되어야 하는지를 결정하기 위한 구조를 제공한다. 이는 이것으로 관련된 아이노드 및 파일 네임이 단일 개체 내에 제공된다는 것을 의미한다. 또한, 통합 동작에 의해 생성된 구조는 블록에서의 판독에 특히 적합하여, 백업 동작이 병렬 방식으로 수행될 수 있게 한다는 것을 주지하라. 또한 파일의 백업 작업은 할당된 파일 번호에 의해서 단순히 구획되어 분산형 또는 병렬 데이터 처리 시스템 내의 어느 하나의 프로세서에 의해서 백업되는 것과는 반대로 파일 크기 또는 다른 기준에 의해 구획되는 것이 바람직하다.

Description

파일 시스템 백업 방법, 컴퓨터 프로그램 제품 및 데이터 처리 시스템{PARALLEL HIGH SPEED BACKUP FOR A STORAGE AREA NETWORK(SAN) FILE SYSTEM}

본 발명은 일반적으로 파일 시스템을 백업(backing up)하는 방법 및 시스템에 관한 것이다. 보다 구체적으로, 본 발명은 그 구조가 백업 프로세스를 복수의 독립적인 장치로 구획할 수 있게 하기 때문에 분산형 또는 병렬 데이터 처리 시스템에서 특히 유용한 것으로 보인다. 보다 더 구체적으로, 본 발명은 분산형 또는 병렬 데이터 처리 시스템 내의 SAN(Storage Area Networks)에 있어서 특히 적합하다.

디스크 저장 장치의 개발로 단일 파일 시스템 내에서 대량의 데이터 및 많은 수의 파일을 처리하는 기능이 가능하게 되었다. 그러나 이는 충분한 양의 데이터를 이동시키는 것과 연관된 문제점 및 어떤 파일이 백업되어야 하는지 식별하는 것과 연관된 문제점에 기인하여 네트워크 내의 파일의 정상 백업 복제본을 생성하는 데에 있어서 문제점을 유발한다.

파일을 백업하는 종래의 기술은 전체 모드(full mode) 또는 증분 모드(incremental mode)로 작동될 수 있는 백업 애플리케이션의 실행을 포함한다. 전체 백업(즉, 전체 모드로 실행되는 백업, 베이스 백업(base backup)으로도 알려져 있음)은 전체 네임 트리(name tree)(이하에서 보다 세부적으로 논의되는 용어인 "네임 트리" 및 "네임 스페이스" 참조)를 판독하고, 각 파일의 복제본을 전송함으로써 전체 파일 시스템을 단일 데이터 싱크(data sink)로 백업한다. 증분 백업은생성되었거나 변경된 임의의 파일에 대한 파일의 새로운 복제본을 전송하고, 또한 삭제되는 파일의 주석(note)을 생성한다. 삭제된 파일의 백업 복제본은 동일한 기법 메커니즘에 따라서 최종적으로는 삭제된다(예를 들면, 1달의 기간동안 백업 복제본을 유지함).

상술된 상황에는 본 발명에 의해서 해결될 수 있는 2개의 문제점이 존재하는데, (1) 첫 번째 문제점은 데이터 및 파일 전송의 직렬 특성에 의해 발생되는 백업 애플리케이션의 직렬 특성으로서, 이는 직렬 방식이 아닌 경우 가능할 수 있는 데이터 레이트(data rates)를 과도하게 제한하고, (2) 두 번째 문제점은 실제로 백업을 필요로 하는 파일을 빠르게 판정하는 기능이 부족하다는 것이다. 파일 백업 동작을 위한 현행 기법은 전형적으로 파일 시스템 계층(file system hierarchy) 내의 전체 네임 스페이스를 판독하고 각 파일에 대한 소정의 파일 정보를 추출한다. 이는 파일 시스템 호출(file system call)이 파일 시스템 내의 모든 파일에 대해 실행되는 것을 필요로 한다(이하의 Posix 파일 시스템 표준에 따른 데이터 처리 시스템에서, 이 호출은 "stat()" 커맨드에 의해서 실행됨). 이들 호출은 디스크에 저장된 정보를 필요로 하고, 파일 네임의 순서대로 수행되기 때문에, 이들은 전형적으로 디스크 동작이 각각 수 밀리초(ms)의 시간적 "비용"을 갖게 한다. 예를 들면, 1억개의 파일을 갖는 파일 시스템 및 5ms 내에 파일 정보를 판독할 수 있는 디스크에 경우에 각 파일을 검사하는데 133시간이 소요될 것이다. UNIX 운영 시스템(Unix는 Open Group의 등록된 상표명임)의 초기 개발 이후에 "아이노드"(소정의 파일 시스템 구조를 설명하기 위해서 널리 사용되는 이 용어에 대한 아래의설명을 참조하라)에 의한 백업 기법이 존재하지만, 이 기법은 일반적으로 파일 시스템 사용자인 사람에 의해서 인식 가능한 파일 네임 그 자체와는 반대로 사람이 사용할 수 없는 식별자인 아이노드 번호에 의해서 파일을 식별하는 것에 의한 문제점을 갖고 있다.

이들 파일 백업 문제점에 대해 알려진 유일한 다른 해결책은 변경되는 파일의 계속적인 저널링(journaling)에 기초하는 파일 시스템 내에 존재한다. 그러나, 이 해결책은 파일이 수정, 삭제 또는 리네임(renamed)되는 매 순간마다 프로그램 종료를 유발하여 백업되어야 할 필요가 있는 파일을 나타내는 소정 형태의 로그(log)를 생성하게 한다. 이 해결책은 백업 시간에 모든 필요한 정보를 즉시 입수할 수 있다는 장점을 갖지만, 로그에 정보를 계속적으로 추가해야하는 비용적인 단점을 갖는다. 또한, 1회 이상 수정되는 파일에 대해서 추가된 기록은 중복될 수 있는데, 이러한 상황은 매우 자주 발생된다.

본 발명이 사용하고 있는 환경을 보다 잘 이해하기 위해서, 본 기술 분야에서는 이하의 용어를 사용하여 일반적으로 잘 알려진 개념을 나타낸다. 이하에 제공된 정의는 편의상 본 기술에 포함된 문제점 및 그에 대해 제공된 해결책에 대한 향상된 이해를 위해서 제공된 것이며, 파일 시스템 기술 분야의 당업자들이 인식하는 바와 같은 일반적으로 이해되는 의미에 대한 변경을 의미하도록 의도된 것이 아니다. 본 발명은 파일 및 파일 시스템을 둘러싼 개념들과 밀접하게 관련되므로, 독자에게 보다 적절한 용어의 적어도 일부분에 대한 짧은 설명이라도 제공하는 것이 유용할 것이다. 보다 더 완전한 리스트는 본 발명과 동일한 양수인에 의해 허여된 미국 특허 제 6,032,216 호에서 확인할 수 있다. 이 특허는 본 명세서에서 참조 문헌으로 인용되었다. 이 특허로부터 선택된 용어들은 본 발명에 대한 보다 나은 인식 및 이해를 위한 가장 적절한 용어들이므로, 그에 대한 이하의 용어 설명을 다음과 같이 제공하였다.

데이터/파일 시스템 데이터 : 임의적인 비트의 스트링(strings)으로서, 오직 특정 애플리케이션에서만 의미를 갖는다.

파일 : 네임을 갖는 비트의 스트링으로서, 컴퓨터 애플리케이션에 의해 액세스될 수 있다. 임의의 파일은 길이, 수정 시각 및 최종 액세스 시각 등과 같은 소정의 표준 속성을 갖는다.

메타데이터(metadata) : 파일 시스템 소프트웨어에 의해 생성된 제어 구조로서, 파일의 구조 및 파일 시스템을 포함하는 디스크의 사용에 대해서 나타낸다. 이러한 타입의 파일 시스템에 적합한 특정 타입의 메타데이터는 이하에서 보다 구체적으로 설명되어 있으며, 디렉토리, 아이노드(inodes), 할당 맵(allocation maps) 및 로그(logs)를 포함한다.

디렉토리 : 네임과 아이노드에 의해 표현된 데이터의 세트를 연관시키는 제어 구조이다.

아이노드 : 파일의 속성에 추가하여 디스크(다른 저장 매체)의 영역에 대한 일련의 포인터-파일을 이루는 데이터를 포함함-를 포함하는 데이터 구조이다. 파일의 크기가 크다면, 추가적인 포인터를 갖는 아이노드를 보충하는 간접 블록을 이용하여 아이노드를 보충할 수 있다.

할당 맵 : 디스크(또는 아이노드 등과 같은 다른 제어 구조)의 특정 영역이 사용 중이거나 사용가능한지 여부를 나타내는 제어 구조이다. 이는 소프트웨어가 새로운 파일에 이용 가능한 블록 및 아이노드를 효과적으로 할당할 수 있게 한다. 이 용어는 파일 시스템 동작의 일반적인 이해를 위해서는 유용하지만, 본 발명의 파일 시스템 동작에는 단지 부분적으로만 연관된다.

로그 : 다른 타입의 메타데이터와의 동기화(다시 말해, 일치되는 상태)를 유지하여 장애 상황에서 손실(loss)을 방지하기 위해서 사용되는 레코드의 세트이다. 로그는 다중 구조에 관련된 업데이트를 나타내는 단일 레코드를 포함한다. 또한, 이 용어는 단지 부분적으로 사용될 뿐이지만 위에서 설명된 대안적인 해결책과 관련하여 제공되었다.

파일 시스템 : 디스크(또는 다른 매체)의 정의된 세트를 관리하는 소프트웨어 구성 요소이고, 데이터 및 데이터 파일의 일관적인 추가, 수정 및 삭제를 활성화하는 방식으로 데이터로의 액세스를 제공한다. 또한 이 용어는 디스크(또는 다른 매체)의 특정 세트 내에 포함되는 데이터 및 메타데이터의 세트를 표현하는 데에도 사용된다. 본 발명은 전형적으로 회전식 자기 디스크 저장 시스템과 관련하여 대체적으로 사용되지만, 네임을 가지고 인접하지 않은 블록 내에 위치되는 데이터를 액세스할 수 있는 임의의 데이터 저장 매체에서도 사용될 수 있고, 그에 따라서, "디스크" 또는 "디스크 저장 장치" 등의 용어가 사용되는 본 명세서에서는 저장 매체의 보다 일반적인 특성화를 의도하였다.

스냅샷(snapshot) : 주어진 시점에서 파일 시스템의 상태를 포착하는 파일또는 파일의 세트이다.

메타데이터 제어기 : 네트워크형 컴퓨터 시스템(본 발명의 양수인에 의해 제공된 스케일링 가능한 병렬 시스템을 갖는 pSeries 등) 내의 노드 또는 프로세서로서, 이것을 이용하여 파일에 대한 모든 액세스 요청을 처리한다. 이 용어는 완전한 이해를 위해서 제공되었을 뿐이고, 본 발명의 동작에 대한 이해를 위한 것은 아니다.

본 발명의 실시예에 따르면, 파일 시스템을 백업하는 단계는 아이노드 번호 순서-특정 시간 이후에 변경됨-대로 아이노드의 리스트를 작성하는 단계를 포함한다. 이 리스트는 아이노드 번호와, 파일의 크기, 최종 파일 수정 시각(일자를 포함함) 등과 같은 소정의 파일 속성을 포함한다. 파일 시스템 내에 현재 존재하는 모든 파일의 네임 및 아이노드 번호/생성 번호를 갖는 테이블을 또한 작성한다. 이 리스트는 아이노드 번호에 의해 분류된다. 리스트 및 테이블은 아이노드 번호에 의해 통합된다. 다음으로 어느 파일을 백업할 것인지 결정하는 통합된 리스트 및 테이블의 컨텐츠를 이용하여 파일을 백업한다. 통합된 개체 내에 나타나는 순서대로 파일을 백업할 수도 있지만, 그 특정한 순서는 중요하지 않다. 본 명세서에서 사용된 바와 같이, "리스트" 및 "테이블"이라는 용어는 본질적으로 동일한 선형 구조를 포함하도록 의도된 것이고, "제 1 리스트" 및 "제 2 리스트" 등과 같이 더 이해하기 어려운 개념을 참조하는 것을 회피하기 위해 별도의 용어를 사용하였다.

본 발명의 바람직한 실시예에서, 아이노드 번호는 또한 생성 번호를 포함한다. 생성 번호를 사용하면 파일의 삭제 이후에 동일한 아이노드를 사용할 수 있다. 이전의 파일은 "아이노드(X), 생성(N)"이고 새로운 파일은 "아이노드(X), 생성(N+1)"이다. 또 다른 특성에서, 통합된 리스트 및 테이블은 섀도우 네임 스페이스 파일(shadow name space file)로 지칭되는 자체의 파일 내에 저장된다. 본 발명은 또한 섀도우 네임 스페이스 파일의 형식 및 구조를 이용하여 비교적 큰 블록 내의 파일을 액세스한다. 이 방법으로 블록은 구획되고 시스템 내의 여러 처리 노드에 공급되어 적어도 2개의 독립적인 프로세서에 의해서 병렬 방식으로 복수의 백업 동작이 수행되게 한다. 이 방식에 의한 백업 동작의 구획은 백업되는 섀도우 네임 스페이스 파일의 단순한 선형 분할에 제한되지 않는다. 여기에서 구획은 구획 내에서 표시된 파일에 대한 파일 백업의 완료 추정 시간 등과 같은 다양한 파일 파라미터에 용이하게 기초할 수 있으나, 이것으로 한정되지 않는다.

따라서, 본 발명의 목적은 대형 파일 시스템의 백업 방법을 제공하는 것이다.

또한 본 발명의 목적은 SAN(storage area networks) 내의 데이터에 대한 백업의 성능을 향상시키는 것이다.

본 발명의 또 다른 목적은 백업 프로세스를 구획하여 복수의 데이터 처리 노드에서 병렬 방식으로 수행될 수 있게 하는 메커니즘을 제공하는 것이다.

본 발명의 다른 목적은 아이노드 번호를 참조하는 것이 아닌 사람이 판독 가능한 파일 네임에 의한 파일 지정이 보다 더 용이한 파일 백업 시스템을 제공하는 것이다.

본 발명의 또 다른 목적은 전체 모드 및 증분 모드에서 파일 백업 절차의 작동을 강화하는 것이다.

본 발명의 다른 목적은 파일을 단일 데이터 싱크 또는 복수의 데이터 싱크로 백업하는 메커니즘을 제공하는 것이다.

본 발명의 또 다른 목적은 파일 삭제 기법, 특히 보다 장기간의 삭제 기법과 부합되는 파일 백업 절차를 제공하는 것이다.

또한 본 발명의 목적은 파일 백업 절차의 통상적인 직렬 특성을 회피하는 것이다.

본 발명의 또 다른 목적은 어떤 파일이 백업되는지 빠르게 결정하고, 파일 네임에 따라 백업을 수행하며, 그것으로 파일 네임에 따라 개별 파일을 선택적으로 복원하는 기능을 유지하는 것이다.

본 발명의 또 다른 목적은 저널링에 기초한 파일 백업 절차를 회피하는 것이다.

또한 본 발명의 목적은 특히 대형의 분산형 데이터 처리 시스템에서 파일 시스템 백업에 요구되는 시간을 상당히 감소시키는 것이다.

최종적인 본 발명의 목적은, (그러나 여기에 한정되지 않음) 파일의 개수가 클 때, 즉, 예를 들어 파일의 개수가 억 단위일 때 파일 시스템 내에서 백업을 위해서 어느 파일이 변경되는지 신속하게 식별할 수 있게 하는 것이다.

본 명세서에서 상술된 본 발명의 여러 실시예에 의해 충족될 수 있는 바람직한 목적의 리스트는 이들 목적의 일부 또는 전부가, 개별적으로 또는 집합적으로 본 발명의 가장 일반적인 실시예 또는 본 발명의 보다 구체적인 실시예의 본질적인 피처를 의미하거나 제시하는 것을 의미하지 않는다.

본 발명에서 고려되는 대상물은 본 명세서의 결말 부분에서 특정하게 지시되고 명확하게 청구되었다. 그러나, 본 발명은 추가적인 목적 및 그 장점과 함께 구성 및 실행 방법으로서 첨부된 도면과 관련되는 이하의 설명을 참조함으로써 최대로 이해될 수 있을 것이다.

도 1은 본 발명에서 활용되는 파일 시스템 구조를 도시하는 블록도,

도 2는 데이터 구조 설명에서 큰 블록들의 검색을 가능하게 하고, 백업 작업을 복수의 독립적인 동작으로 구획할 수 있게 하는 형태로 사용되며, 빠르고 효율적인 백업 동작과 연관되어 사용될 수 있는 2개의 추가적인 구조를 포함한 구조를 도시하는 블록도,

도 3은 파일 및 디렉토리 또는 서브 디렉토리 개체를 구별하기 위해 파일 시스템 디렉토리 내에서 사용 가능한 구조를 도시하는 블록도.

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

100 : 디렉토리 트리 111 : 네임 엔트리

200 : 아이노드 파일 300 : 데이터

400 : 아이노드 리스트

도 1은 파일 시스템 내의 기본 요소를 도시한다. 도시된 바와 같은 전형적인 파일 시스템은 디렉토리 트리(directory tree)(100), 아이노드 파일(200) 및 데이터(300)를 포함한다. 이 3개의 요소는 전형적으로 파일 그 자체로서 파일 시스템 내에 존재한다. 예를 들면 도 1에 도시된 바와 같이, 아이노드 파일(200)은 개별 레코드의 집합체 또는 엔트리(220)를 포함한다. 파일 시스템마다 오직 하나의 아이노드 파일만이 존재한다. 이는 특히, 도 1의 하단에 도시되어 있고 참조 번호 200으로 표시된다. 디렉토리 트리(100) 내의 엔트리는 필드(112) 등과 같은 포인터를 포함하는데, 이는 아이노드 파일(200) 내부로의 단순 인덱스로서 작동되는 일정 크기의 정수를 포함하는 것이 바람직하다. 예를 들어, 필드(112)가 말하자면 "10876" 등을 나타내는 이진 정수를 포함하면, 이는 아이노드 파일(200) 내의10876번째 엔트리를 지칭한다. 특정 엔트리(아래에서 설명되는 참조 부호(216) 참조)를 사용하여 파일을 디렉토리로서 나타낸다. 그러므로 디렉토리는 전형적으로 저장된 파일의 네임이 임의의 깊이를 갖는 디렉토리 트리 내에 유지되어 있는 파일이다. 디렉토리(100)에 관하여, 본 발명의 보다 나은 이해를 위해서 그 의미가 이해되어야 하는 3개의 용어가 존재한다.디렉토리 트리는 파일 시스템 내의 모든 디렉토리를 포함하는 디렉토리의 집합체이다.디렉토리는 특정 타입의 파일로서, 디렉토리 트리의 요소이다. 디렉토리는 아이노드에 대한 포인터의 집합체이고, 여기에서 아이노드는 디렉토리 트리 내의 하부 위치를 점유하는 파일 또는 디렉토리이다.디렉토리 엔트리는 파일 또는 디렉토리를 지시하는 디렉토리 내의 단일 레코드이다. 도 1에서, 기능 블록(100) 내에 전형적인 디렉토리 트리를 도시하였다. 전형적인 디렉토리 엔트리는 도시된 바와 같이 참조 부호(120)의 형태를 갖는 요소를 포함하지만, 도 3을 참조하면 본 발명의 목적을 위한 디렉토리 엔트리 컨텐츠가 도시되어 있다. 도 1은 (편의상) 2개의 레벨만을 갖는 계층을 도시하였으나, 디렉토리의 계층적 트리 구조의 깊이는 2개의 레벨로 한정되지 않는다는 것을 이해해야 한다. 사실상, 임의의 디렉토리 트리 내에 수십개의 레벨이 존재할 수 있다. 그럼에도, 디렉토리 트리의 깊이는 오직 하나의 파일만을 식별하고 액세스할 필요가 있는 경우에도 다수의 디렉토리를 참조할 필요성을 발생시킨다. 그러나, 대부분의 경우에, 디렉토리 트리의 "레벨"은 파일 네임(참조 번호(111))을 아이노드 파일(200) 내의 엔트리(220)와 연관시키는 데 사용된다. 아이노드 파일(200) 내부의 포인터를 제공하는 "아이노드 번호"(참조 번호(112))에 의해 참조가 이뤄진다.본 명세서에서 고려되는 타입의 파일 시스템 내에는 하나의 아이노드 어레이가 존재한다. 본 발명의 바람직한 실시예에서, 아이노드 어레이는 아이노드 파일(200)이고, 어레이 소자로의 인덱스 포인트이다. 그러므로 아이노드 #10876은 아이노드 파일(200) 내의 10876번째 어레이 소자이다. 전형적으로, 또한 바람직하게는, 이 포인터는 아이노드 파일(200) 내의 단순 인덱스이므로, 본질적으로 선형 방식으로 액세스된다. 그러므로, 인덱스가 10876이면, 이는 10876번째 레코드 또는 아이노드 파일(200)의 어레이 소자를 가리킨다. 네임 엔트리(111)는 트리 내에서 한 레벨 아래로 이동할 수 있게 한다. 전형적인 파일 시스템에서, 네임 엔트리(111)는 말하자면 아이노드 #10876을 가리키고, 이것은 디렉토리 또는 데이터 파일이다. 네임 엔트리(111)가 디렉토리일 경우, 다음 레벨의 네임에 대한 해당 디렉토리 파일의 내부를 반복적으로 검색한다. 예를 들어, 도 1에 도시된 바와 같이 엔트리(111)가 "a"라고 가정한다. 그러면 "a2"에 대한 아이노드로 네임 엔트리에 대한 아이노드 #10876의 데이터를 검색할 것이다. 네임 엔트리(111)가 데이터를 가리키면, 네임 검색은 종료점에 도달된 것이다. 본 발명에서, 디렉토리 엔트리(120)는 추가적인 필드(113)(도 3 참조)를 포함하고, 이 추가적인 필드는 네임 엔트리(111)가 디렉토리인지 여부를 나타낸다. 디렉토리 트리 구조는 별도로 포함되는데, 이는 POSIX가 본 발명의 이해 또는 동작과 관련되지 않는 방식으로 동일 파일에 대해 다수의 네임을 가능하게 하기 때문이다.

디렉토리 트리(100)는 아이노드 번호에 의한 참조와는 반대로 파일 네임에 의한 개별 파일 엔트리의 참조를 가능하게 하기 때문에 파일 시스템에 대한 계층적네임 스페이스를 제공한다. 디렉토리 내의 각각의 엔트리는 아이노드를 가리킨다. 그 아이노드는 디렉토리 또는 파일일 수 있다. 아이노드(220)는 필드(112) 내의 엔트리에 의해 결정되는데, 이 엔트리는 아이노드 파일(200)(상술된 바와 같이) 내의 위치에 대한 표시인 것이 바람직하다. 아이노드 파일(200) 내의 아이노드 파일 엔트리(220)는 전형적으로 또한 바람직하게는 선형 리스트로서 구현된다. 리스트 내의 각 엔트리는 복수의 필드, 즉 아이노드 번호(212), 생성 번호(213), 개별 파일 속성(214), 데이터 포인터(215), 최종 수정일(216) 및 표시기 필드(217)를 포함하여 파일이 디렉토리인지 여부를 나타내는 것이 바람직하다. 관심 대상이 아닌 다른 필드 또는 본 발명에 관련된 다른 필드도 또한 전형적으로 아이노드 엔트리(220) 내에 존재한다. 그러나, 출원 번호 제 10/602156 호에 수반된 발명과 관련하여 사용하기에 가장 적절한 필드는 최종 수정일을 나타내는 필드(216)이다. 파일 시스템 내에서 아이노드 번호는 고유 번호이다. 파일 시스템은 또한 더 이상 존재하지는 않지만 존재했을 때에는 동일한 아이노드 번호를 가졌던 파일과 해당 파일을 구분하기 위해서 전형적으로 사용되는 생성 번호(213)를 포함하는 것이 바람직하다. 아이노드 필드(214)는 파일과 연관된 소정의 속성을 식별한다. 이들 속성은 최종 수정일, 생성일, 파일 크기, 파일 타입, 판독 또는 기록 액세스를 나타내는 파라미터, 여러 액세스 허가 및 액세스 레벨, 압축 상태, 암호화된 상태, 은닉 상태(hidden status) 및 네트워크 내부의 상태를 포함하지만 여기에 한정되지 않는다. 아이노드 엔트리(220)는 또한 파일이 사실상 디렉토리임을 가리킨다는 것을 나타내는 엔트리(216)를 포함한다. 이는 이러한 파일이 잘 알려진 파일 시스템자체를 위한 네임 스페이스를 포함한다는 사실에 따라서 파일 시스템 자체가 서로 다르게 이 파일을 처리하게 한다. 그러나, 가장 중요한 것은, 전형적인 아이노드 엔트리(220)는 파일 시스템의 데이터 부분(300) 내에 잔류된 실제 데이터(310)에 대한 물리적 위치를 식별하기에 충분한 정보를 포함하는 데이터 포인터(215)를 포함한다는 것이다.

본 발명은 앞서 언급된 것과 같이 오늘날 사용되는 기법에 비해 상당히 빠른 백업 기능을 제공하는 수 개의 기능의 조합을 사용한다. 보다 구체적으로, 본 발명은 다음의 기능을 제공한다.

(1) 개별 아이노드 대신에 블록에 의해 아이노드 파일을 빠르게 판독하는 기능. 이는 디스크 저장 장치를 보다 효율적으로 사용할 수 있게 하고 다수의 디스크에 걸쳐 아이노드 엔트리의 판독을 중복시킬 수 있게 한다. 예를 들어, 본 발명에서는 40밀리초 동안에 512개의 아이노드 엔트리의 블록을 판독할 수 있고, 이것을 100개의 디스크에 걸쳐 병렬 방식으로 수행하여, 1억개의 아이노드 엔트리가 존재하는 경우에 133시간이 소요되었던 것과는 다르게 대략 8초를 필요로 한다. 2002.09.05일 공개된 특허 출원 제 US 2002/0124013 호(2001.06.25일 출원된 제 09/887,533 호, 대리인 서류 제출 번호 제 IL920000067US2 호), 2002.10.03일 공개된 제 US 2002/0143734 호(2001.06.25일 출원된 제 09/887,520 호, 대리인 서류 제출 번호 제 IL920000067US3 호로서, 09/887,533의 분할 출원이며, 이 두 특허는 2000.06.26일 출원된 가출원 번호 제 60/214,127 호, 대리인 서류 제출 번호 제 IL920000067US1 호에 기초하여 출원됨) 및 2002.09.05일 공개된 제 US2002/0123997 호(2001.06.25일 출원된 제 09/887550 호, 대리인 서류 제출 번호 제 IL920000068US2 호로서, 2000.06.26일 출원된 가출원 번호 제 60/214,127 호, 대리인 서류 제출 번호 제 IL920000068US1 호에 기초하여 출원됨)는 병렬 시스템으로부터 계층적 저장 관리자(hierarchical storage manager)로 이벤트를 제공하는 기능을 제공하는 수단에 대해 설명한다. 이러한 수단은 저장 관리자에 제공되는 복수의 복귀된 이벤트를 처리하는 데 유용하다. 상술된 특허는 본 발명의 특허와 동시에 출원된 연관된 발명과 보다 더 관련이 깊은데, 그 발명은 미국 특허 출원 제 10/602157 호에 설명되어 있고, 본 명세서에서는 완전한 이해를 위해서 언급하였다.

(2) 파일 시스템의 네임 스페이스를 빠르게 판독하고, 요컨대 네임 스페이스의 섀도우 복제본을 빠르게 생성하는 기능. 본 발명은 또한 타입을 결정하기 위해 아이노드를 판독할 필요없이, 각 디렉토리 엔트리 내에 네임이 설정된 대상의 타입을 지정하는 기능을 포함한다. 이는 단지 디렉토리 엔트리를 판독하는 것만으로도 네임 스페이스를 생성할 수 있게 한다.

(3) 디렉토리 엔트리가 아이노드 번호에 의해서 순서가 정해져서 아이노드 번호를 파일 네임으로 빠르게 변환할 수 있게 하기 위해서 디렉토리 엔트리를 분류하는 기능. 이 기능은 또한 파일 시스템 네임 스페이스(섀도우 네임 스페이스 파일)의 이전의 복제본을 현재의 복제본과 비교하여 적절한 방식으로 리네임되거나 삭제된 파일을 검출하게 한다.

(4) 작업량(workload)을 여러 부분으로 분할하여 백업 타겟에 대해서 대략동일한 부하가 걸리게 하는 기능. 이는 작업량이 파일의 크기에 따라서 분할되게 하고 파일의 개수에 따라서 분할되게 하며, "워커 스레드(worker threads)"의 스케쥴링(scheduling)이 백업 타겟 또는 타겟으로의 실제적인 데이터 이동을 실행하는 것을 가능하게 한다.

(5) 항상 파일 네임 스페이스의 동일 부분으로부터 동일 백업 타겟으로 데이터를 백업하거나 다른 백업 타겟으로 데이터를 전달하여 백업 작업량의 균형을 더 잘 이루는 기능.

본 명세서에서는 데이터의 백업 복제본을 수용하고 저장하는 백업 수단이 존재하는 것으로 가정한다. 이러한 수단의 테이프 관리 및 분류 특징은 본 발명의 동작에 있어서 확실히 중요하지만, 오늘날의 시장에는 이러한 상품의 여러 예가 존재한다. IBM의 Tivoli 저장 관리자는 이러한 상품 중 하나의 예이다. IBM은 또한 본 발명의 양수인이다.

다음으로 본 발명의 더 나은 이해를 제공하기 위해서, 파일 시스템에 대한 X-open 표준에 부합되는 임의의 파일 시스템과 여러 방면에서 유사한 IBM의 GPFS(General Parallel File System)의 구조 중에서 관련된 부분을 간략하게 고찰한다.

파일 시스템에 대한 시작 지점은 슈퍼블록(superblock)으로 지칭되는 파일 시스템 기술자 데이터 구조(file system descriptor data structure)로서, 파일 시스템을 포함하는 디스크 상의 알려진 고정점(fixed point)에 위치한다. 이 구조는파일 시스템에 대한 임의의 작업을 수행하기 위해서 요구된다. 이 구조는 본 발명의 이해에 있어서 중요한 2개의 데이터 구조의 디스크 위치에 대한 포인터를 갖는다. 이 데이터 구조의 첫 번째는 아이노드 파일(200)이다. 아이노드 파일은 파일의 주요 특성을 나타내는 데이터 구조를 구성하는 개별 아이노드의 집합체이다. 본 발명에 있어서 특히 중요한 것은, 아이노드 파일 내의 엔트리가 파일 또는 그 속성이 변경된 최종 시각을 나타내고, 파일의 크기를 나타내는 타임 스탬프(time stamps)를 포함한다는 것이다. 파일에 대한 아이노드는 파일의 네임을 포함하지 않는다는 것을 주지하라. 파일 네임은 파일 시스템의 디렉토리 구조(100) 내에 저장된다. 파일 시스템을 위한 루트 디렉토리(100)는 파일 시스템의 슈퍼블록에 의해서 지정된 제 2의 주요 데이터 구조이다. 루트 디렉토리는네임으로파일을 검색하기 위한 시작 지점이다. 루트 디렉토리는 구조적으로 다른 디렉토리와 동일하며, 파일 또는 다른 디렉토리에 대한 네임, 파일의 특성을 포함하는 아이노드를 가리키는 아이노드 번호 및 (GPFS에서) 디렉토리 엔트리의 타겟이 파일인지 다른 디렉토리인지를 나타내는 타겟-타입 필드로 이뤄지는 일련의 레코드를 포함한다. rootdir/username/file로 네임이 지정된 파일은 rootdir로 지칭되는 디렉토리를 검색하는 것에 의해 위치를 확인할 수 있고, 이 네임은 username으로 지칭되는 디렉토리로 표시되는 아이노드를 가리킨다. username으로 지칭되는 디렉토리는 파일의 아이노드 번호를 포함한다. 정상 액세스 동작에서, 경로(path) 내의 각 디렉토리 및 그 대응되는 아이노드를 액세스하여 데이터를 찾는다.

본 발명을 더 정확하게 이해하기 위해서는 이러한 동작의 성능 특성을 보다완전하게 이해하는 것이 유용하다. 디렉토리는 대부분 UNIX 또는 UNIX 유사 시스템 내의 파일이다. 그러므로 디렉토리에 대한 판독 동작은 디렉토리의 아이노드에 대한 판독에 더하여 적절한 디렉토리 블록의 판독을 포함한다. 액세스 패턴 및/또는 이용 가능한 캐싱(caching)의 크기로 요구되는 데이터를 캐싱하지 못하면, 이들 각 동작은 디스크 동작과 연관된다. 본 발명은 파일 시스템의 크기 및 메타데이터가 다수의 시스템에서 이용 가능해야 한다는 조건에 의해 요구되는 데이터가 사전에 캐싱되지 않았을 경우에 대해서 고찰한다. 또한, 디렉토리 스캔(directory scan)은 아이노드 파일로의 랜덤 액세스(random access)와 매우 유사하다. 이는 향후의 액세스를 예측하고 사전 인출(prefetch)하는 것을 어렵게 한다. 디렉토리를 스캔하고 아이노드를 판독하기 위해 요구되는 디스크 동작이 성능을 지배한다.

백업을 위해 사용되는 2개의 표준 기법이 존재한다. 이들 중의 하나는 "아이노드에 의한 백업"이다. 이 기법에서, 아이노드 파일로부터 벌크 형태로 아이노드를 판독하고 각 아이노드 파일 엔트리와 연관된 파일을 백업한다. 파일은 아이노드 번호에 의해 식별된다. 이는 네임으로 개별 파일을 복원하려는 어떠한 시도도, 일반적으로 수행되지 않는 중요한 주문형 프로그래밍(custom programing)을 포함한다는 것을 의미한다. 이와 다른 보다 보편적인 기법은 파일 시스템 네임 스페이스를 스캐닝(scan)하여 백업 기준(예를 들면 지정된 일자 이후에 수정된 것 등)을 만족시키는 파일을 검색하는 것이다. 네임 스페이스를 이용하는 것에 의해, 프로그램은 전체 네임 스페이스 내의 각 파일에 문의한다. 이를 수행하는 표준 인터페이스는 디렉토리 엔트리 및 파일에 대한 아이노드를 판독하는 것을 필요로 하며,이 프로세스는 별도의 디스크 동작을 필요로 한다. 이것을 전체 네임 스페이스에서 수행하는 것은 대형 파일 시스템에 있어서 매우 시간 소모적이다.

상술한 바와 같이, 본 발명은 수 개의 수정된 프로세스를 사용하여 앞서 설명된 백업 방법의 한계를 극복한다. 특히, 본 발명은 다음의 방법을 이용한다.

(1) 본 발명에서, 아이노드 파일(200)은 아이노드에 의한 백업에서 변경된 아이노드의 리스트(400)(도 2 참조)를 작성하는 것과 거의 동일한 방식으로 판독된다. 이는 아이노드의 리스트가 백업 기준을 만족시키게 한다. 그러나, 아이노드에 의한 백업과는 다르게, 본 특허에 수반되는 발명은 아이노드 번호를 키(key)로서 사용하여 백업을 수행하지는 않는다.

(2) 본 발명에서, 디렉토리 네임 스페이스(100)를 판독하여 파일 시스템 내의 모든 파일에 대한 네임과 그에 대응되는 아이노드 번호를 포함하는 파일 네임의 리스트(500)(도 2 참조)를 작성하는 추가적인 단계를 이용한다. 디렉토리를 판독할 때, 본 발명은 도 3에 도시된 바와 같은 디렉토리 엔트리의 새롭게 제공된 타겟-타입 필드(113)를 사용한다. 종래의 파일 시스템은 디렉토리 엔트리 내에 타겟이 디렉토리인지 파일인지 여부를 나타내는 표시를 보유하지 않는다. 그 정보는 일반적으로 아이노드 파일 내에서만 유지되고, 그에 따라 아이노드를 판독하기 위한 조건이 된다. 그러므로 본 발명의 동작에서, 필드(113)는 모든 활성 아이노드를 판독하지 않으면서 서브 디렉토리를 식별하기 위해 제공되고, 그에 따라 본 방법의 주요한 장점 중의 하나를 제공한다. 디렉토리 스캔(directory scan)의 결과로 일반적으로 파일 시스템 내에 모든 파일에 대한 네임 및 아이노드 번호를 갖는테이블(500)이 작성된다. 이 스캔은 현재 활성화된 파일 시스템 또는 파일 시스템의 스냅샷에 대해서 수행된다.

(3) 본 발명은 아이노드 번호로 결과적인 네임 스페이스 테이블(500)을 분류한다. 이는 용이하게 네임 스페이스 테이블(500)을 아이노드 리스트(400)와 통합시킬 수 있게 하고, 그것으로 인해 테이블은 백업되는 파일을 가리키는 파일 네임의 리스트를 생성한다.

(4) 결과적으로 통합되는 테이블의 구조 및 컨텐츠는 통합된 테이블을 파일의 개수 및 각 파일의 크기에 따라 동등한 부분으로 분할하고, 다음에 파일 시스템(예를 들면 GPFS 등)의 다수의 노드에 걸쳐 동시에 백업을 수행하는 다수의 병렬 백업 작업인 "워커 스레드(worker threads)"를 발생시키는 추가적인 기능을 본 발명에 제공한다. 테이블을 "동등한" 부분으로 분할하는 작업은 각 파일마다 요구되는 시간을 추정하는 것에 의해서 이뤄진다. 시간 추정은 아래의 계산에 기초하는 것이 바람직하다(그러나 이 계산의 정확한 형태는 중요하지 않다는 것을 주지하라).

time=base_time+(time/byte)*(바이트의 수)

여기에서, base_time은 1바이트 파일을 백업하는 데 요구되는 추정 시간이고, time/byte는 추가적인 바이트를 백업하는 데 요구되는 증분 시간의 추정치이다. 본 발명의 이러한 특성은 바람직하지만 선택적이다.

(5) 백업이 다수의 백업 리포지터리(repositories)들에 걸쳐 분산되면, 각 파일이 매번 동일 리포지터리에 전달되도록 요구된다. 베이스 백업에서, 파일 네임 스페이스는 각 리포지터리에 대해 거의 동일한 부분으로 분할되고, 파일은 다음 베이스 백업 때까지 해당 리포지터리와 연관된 상태로 유지된다. 이 매핑(mapping)은 원래의 네임 스페이스 테이블을 추가하는 것이 바람직하다. 본 출원에 수반된 발명의 이러한 특징은 바람직하기는 하지만 또한 선택적이다. 지정된 베이스 백업에 대한 구획은 임의로 수행된다. n개의 리포지터리가 존재한다면, 섀도우 파일은 위의 (4)번 항목에서 상술된 바와 같이 대략 동일한 로드(load)를 갖는 n개의 조각으로 분리된다. 그러면 n개의 리포지터리에 데이터를 전달하는 m개의 워커 스레드를 사용할 수 있는데, 여기에서 각 리포지터리가 원하는 양의 시간 내에 백업을 완료시킬 수 있도록 m은 n의 배수인 것이 이상적이다.

(6) 파일 네임으로부터 백업 리포지터리로의 매핑을 변경하여 백업 작업량이 다시 균형을 이루게 하는 것이 바람직하다. 매핑이 변경되면, 존재하는 파일의 백업 버전은 그의 새로운 리포지터리로 이동되는 것이 바람직하지만, 이는 필수적이지 않다. 본 발명의 이 특징은 바람직하지만 또한 선택적이다.

(7) 다음의 백업에서 사용하기 위해 네임 스페이스 테이블을 저장한다. 현재 백업의 네임 스페이스와 이전 백업의 네임 스페이스를 비교함으로써, 삭제되고 리네임된(renamed) 파일을 용이하게 검출하고, 표준 백업 방법에 따라서 정확한 백업 동작을 취할 수 있다. 본 특허에 수반된 발명의 이러한 특징은, 특히 본 발명을 그의 가장 넓은 범주로 가정할 때 바람직하지만 또한 선택적이다.

지금까지 설명된 프로세스 수정의 결과는 네임에 의한 백업의 유동성을 여전히 허용하면서도 대형 파일 시스템의 백업을 더 빠르게 한다는 것이다. 본 발명의시스템 및 방법의 이점에 대한 보다 완전한 이해를 위해서, 이하에 특정한 예시에 대해 고찰하였다. 이들 각 예시에 있어서 디스크 검색 시간을 5밀리초로 가정하였으며, 이는 오늘날의 디스크 드라이브에 있어서 일반적인 검색 시간이다.

예를 들어, 100,000바이트의 크기를 갖는 천만개의 파일 및 10,000개의 디렉토리를 포함하는 10개의 디스크로 이루어지고 이전의 백업 이후에 오직 5%의 파일만이 변경된 파일 시스템에서 다음의 성능 차이가 발견되었다.

네임에 의한 백업을 사용하는 종래 기술의 백업 기법

천만개의 아이노드를 각각 5밀리초 동안 "판독"하고, 이는 어떤 파일이 변경되었는지 판정하는데 13시간 이상이 소요되게 하며, 네임을 획득하기 위해서는 10,000개의 디렉토리를 판독해야 한다.

본 발명을 사용하는 백업 기법

더 큰 단위로 아이노드 파일을 판독한다. 또한, 아이노드 파일에 대한 액세스는 순차적이어서, 아이노드를 미리, 동시에 판독할 수 있게 한다. 이 예에서, 총 10개의 디스크로부터 512개의 단위로 동시에 아이노드를 판독한다. 512개의 아이노드에 대한 각 판독은 10개씩 병행하여 수행되어 대략 50밀리초 동안 실행되었다. 이는 대략 100,000 아이노드/초의 판독 레이트로서 2초 내에 천만개의 아이노드를 판독할 수 있게 한다. 디렉토리 판독 성능도 앞의 경우와 동일하다. 백업 데이터를 다수의 리포지터리에 전송하는 다수의 워커 스레드를 병렬 방식으로 사용하는 백업 기능에 의해서 성능 이득은 더욱 향상된다.

본 명세서에서는 본 발명을 소정의 바람직한 실시예에 따라서 설명하였으나, 당업자라면 그에 대한 여러 수정 및 변경을 수행할 수 있을 것이다. 따라서, 첨부된 청구항은 이러한 수정 및 변경이 본 발명의 진정한 정신 및 범주에 포함되도록 의도된 것이다.

본 발명은 백업 프로세스를 복수의 독립적인 장치로 구획할 수 있는 구조를 사용하여 분산형 또는 병렬 데이터 처리 시스템에서 특히 유용한 파일 시스템의 백업 방법 및 시스템을 제공한다.

Claims

파일 시스템 백업 방법으로서,

아이노드 번호(inode number)의 순서대로 변경되는 아이노드의 리스트를 작성하는 단계-상기 리스트는 상기 아이노드 번호를 포함함-와,

상기 파일 시스템 내에 현재 존재하는 모든 파일에 대한 네임(name) 및 상기 아이노드 번호를 갖는 테이블을 작성하는 단계와,

상기 아이노드 번호에 의해 상기 리스트를 분류하는 단계와,

상기 아이노드 번호에 의해 상기 리스트 및 상기 테이블을 통합하여 단일 개체 내에 관련된 아이노드 및 파일 네임을 제공하는 단계와,

상기 통합된 리스트 및 테이블에 기초하여 파일을 백업하는 단계

를 포함하는 파일 시스템 백업 방법.
제 1 항에 있어서,

상기 아이노드 번호는 생성 번호를 더 포함하는 파일 시스템 백업 방법.
제 1 항에 있어서,

상기 통합된 리스트 및 테이블을 섀도우 네임 스페이스 파일(shadow namespace file)로 지칭되는 자체의 파일 내에 저장하는 단계를 더 포함하는 파일 시스템 백업 방법.
제 3 항에 있어서,

블록 내의 상기 섀도우 네임 스페이스 파일을 액세스하는 단계를 더 포함하는 파일 시스템 백업 방법.
제 4 항에 있어서,

상기 블록은 구획되어 있고, 상기 백업은 적어도 2개의 독립적인 프로세서에 의해 수행되며, 각각의 프로세서는 상기 구획 내에 표시된 파일을 백업하는 파일 시스템 백업 방법.
제 5 항에 있어서,

상기 구획은 상기 구획 내에 표시된 파일에 대한 파일 백업의 완료에 소요되는 추정 시간에 기반하는 파일 시스템 백업 방법.
제 1 항에 있어서,

상기 백업은 상기 통합된 리스트 및 테이블에서 표시된 것과 동일한 순서로 수행되는 파일 시스템 백업 방법.
머신 판독 가능 기록 매체에 저장된 파일 시스템 백업용 컴퓨터 프로그램 제품으로서,

(1) 아이노드 번호의 순서대로 변경되는 아이노드의 리스트를 작성하는 프로그램 수단-상기 리스트는 상기 아이노드 번호를 포함함-과,

(2) 상기 파일 시스템 내에 현재 존재하는 모든 파일에 대한 네임 및 상기 아이노드 번호를 갖는 테이블을 작성하는 프로그램 수단과,

(3) 상기 아이노드 번호에 의해 상기 리스트를 분류하는 프로그램 수단과,

(4) 상기 아이노드 번호에 의해 상기 리스트 및 상기 테이블을 통합하여 단일 개체 내에 관련된 아이노드 및 파일 네임을 제공하는 프로그램 수단과,

(5) 상기 통합된 리스트 및 테이블에 기초하여 파일을 백업하는 프로그램 수단

을 포함하는 컴퓨터 프로그램 제품.
데이터 처리 시스템에 있어서,

중앙 처리 장치와,

상기 중앙 처리 장치에 의해 실행되는 데이터 및 프로그램을 저장하기 위한 랜덤 액세스 메모리(random access memory)와,

비휘발성 저장 장치와

상기 메모리 내에 저장된 파일 시스템 백업용 프로그램 수단

을 포함하되,

상기 프로그램 수단은,

(1) 아이노드 번호의 순서대로 변경되는 아이노드의 리스트를 작성하는 수단-상기 리스트는 상기 아이노드 번호를 포함함-과,

(2) 상기 파일 시스템 내에 현재 존재하는 모든 파일에 대한 네임 및 상기 아이노드 번호를 갖는 테이블을 작성하는 수단과,

(3) 상기 아이노드 번호에 의해 상기 리스트를 분류하는 수단과,

(4) 상기 아이노드 번호에 의해 상기 리스트 및 상기 테이블을 통합하여 단일 개체 내에 관련된 아이노드 및 파일 네임을 제공하는 수단과,

(5) 상기 통합된 리스트 및 테이블에 기초하여 파일을 백업하는 수단

을 포함하는 데이터 처리 시스템.