KR101362561B1

KR101362561B1 - 파일 시스템 인식 블록 저장 시스템, 장치 및 방법

Info

Publication number: KR101362561B1
Application number: KR1020087029601A
Authority: KR
Inventors: 줄리안 엠. 테리; 네일 에이. 클락슨; 제프리 에스. 바랄
Original assignee: 드로보, 인크.
Priority date: 2006-05-03
Filing date: 2007-05-03
Publication date: 2014-02-13
Also published as: AU2007244671A2; CA2651757A1; JP2009536414A; JP4954277B2; CN101501623A; CN101501623B; AU2007244671B2; KR20090009300A; AU2007244671A1; WO2007128005A3; EP2372520B1; AU2007244671B9; EP2372520A1; EP2024809A2; WO2007128005A2

Abstract

파일시스템 인식 저장 시스템은 호스트 파일시스템의 저장 용도를 결정하기 위해 호스트 파일시스템 데이터 구조를 찾아 분석한다. 이를 위해, 스토리지 시스템은 오퍼레이팅 시스템 파티션을 찾고, 그 오퍼레이팅 시스템 파티션을 파싱하여 그의 데이터 구조를 찾고, 오퍼레이팅 시스템 데이터 구조를 파싱하여 호스트 파일시스템 데이터 구조를 찾는다. 스토리지 시스템은 호스트 파일 시스템의 저장 용도에 기초하여 데이터 스토리지를 관리한다. 스토리지 시스템은 저장 용도 정보를 사용하여, 호스트 파일시스템에 의해 더 이상 사용되지 않는 저장 영역을 식별하고, 부가의 데이터 저장 용량을 위해 그들 영역을 재사용한다. 또한, 스토리지 시스템은 호스트 파일시스템에 의해 저장된 데이터 유형을 식별하고, 데이터 유형에 기초하여 데이터를 위한 인코딩 기법 및/또는 스토리지 레이아웃을 선택하는 것과 같은, 데이터 유형에 기초하여 데이터 스토리지를 관리한다.

저장 시스템, 리던던시, 리던던트, 핫 스페어, 지시자

Description

파일 시스템 인식 블록 저장 시스템, 장치 및 방법{FILESYSTEM-AWARE BLOCK STORAGE SYSTEM, APPARATUS, AND METHOD}

우선권

본 PCT 출원은, Julian M. Terry, Neil A. Clarkson 및 Geoffrey S. Barrall이라는 이름으로 2006년 5월 3일 출원되고 발명의 명칭이 Filesystem-Aware Block Storage System, Apparatus, and Method"인 미국 가출원 번호 60/797,127을 우선권주장한다.

본 출원은 또한, 미국 가출원 번호 60/625,495(2004년 11월 5일 출원)와 미국 가출원 번호 60/718,768(2005년 9월 20일 출원)을 우선권 주장하는 미국 특허 출원 번호 11/267,938 (발명의 명칭 Dynamically Expandable and contractible Fault-Tolerant Storage System Permitting Variously Sized Storage Devices and Method, Geoffrey S. Barrall이라는 이름을 2005년 11월 4일 출원)와 관계가 있다.

상기 모든 특허 출원은 그 전체가 본 명세서에서 참조된다.

본 발명은 디지털 데이터 저장 시스템들 및 방법들에 관한 것으로, 특히 내장애성(fault-tolerant) 저장을 제공하는 것들에 관한 것이다.

종래 기술에서는 RAID(Redundant Array of Independent Disks) 프로토콜들 중 어느 하나에 따른 패턴으로 리던던트 디스크 저장(redundant disk storage)을 제공하는 것이 알려져 있다. 전형적으로 RAID 패턴을 이용한 디스크 어레이들은 숙련된 정보 기술자들에 의한 관리를 필요로 하는 복잡한 구조들이다. 또한 RAID 패턴을 이용한 다수의 어레이 설계에서, 어레이 내의 디스크 드라이브들이 균일하지 않은 용량들로 되어 있으면, 설계는 어레이 내의 가장 작은 드라이브의 용량을 초과하는 어떠한 용량도 드라이브에 이용할 수 없을 수 있다.

표준 RAID 시스템과 관련된 하나의 문제점은 디스크 어레이의 드물게 사용되는 영역들에서 디스크 표면 훼손이 발생할 수 있다는 점이다. 다른 드라이브가 고장나는 경우에, 훼손이 발생하였음을 항상 결정할 수 있는 것은 아니다. 그 경우, 훼손된 데이터는 RAID 어레이가 고장난 드라이브를 재구성할 때 전파되어 보존될 수 있다.

다수의 저장 시스템들에서, 다른 저장 디바이스가 고장나는 경우에 이용될 수 있도록 여분의 저장 디바이스가 준비 상태로 유지될 것이다. 그러한 여분의 저장 디바이스는 종종 "핫 스페어(hot spare)"로 지칭된다. 핫 스페어는 저장 시스템의 정상 동작 중에는 데이터를 저장하기 위해 이용되지 않는다. 작동중인 저장 디바이스가 고장나는 경우, 그 고장난 저장 디바이스는 핫 스페어에 의해 논리적으로 교체되고, 데이터는 핫 스페어 상에 옮겨지거나 또는 다른 방법으로 재생성된다. 고장난 저장 디바이스가 수리 또는 교체되는 경우, 데이터는 전형적으로 (재)작동된 저장 디바이스 상에 옮겨지거나 또는 다른 방법으로 재생성되고, 핫 스페어는 또 다른 고장의 경우에 이용될 준비가 되도록 오프라인으로 된다. 핫 스페어 디스크의 유지관리는 일반적으로 복잡하고, 그래서 일반적으로 숙련된 관리자에 의해 핸들링된다. 핫 스페어 디스크는 또한 추가 비용을 나타낸다.

일반적으로 말하면, 호스트 파일시스템이 데이터 블록을 저장 시스템에 기입할 때, 저장 시스템은 데이터용 저장 블록을 할당하고, 그 저장 블록이 사용 중인 것을 나타내도록 데이터 구조를 업데이트한다. 그 포인트로부터, 저장 시스템은 호스트 파일시스템이 그 블록을 사용하는 것을 뒤이어 중지하더라도 그 저장 블록이 사용중일 것이라고 고려한다.

호스트 파일시스템은 일반적으로 비트맵을 사용하여 자신의 사용되는 디스크 블록을 추적한다. 볼륨 샘성 후 짧은 시간에, 비트맵은 전형적으로 모든 비트를 클리어함으로써 대부분의 블록이 비워진다는 것을 지시할 것이다. 파일시스템이 사용됨에 따라, 호스트 파일시스템은 단지 빈 블록 비트맵을 사용하여서만 블록들을 할당한다.

호스트 파일시스템이 일부 블록들을 빈 풀(pool)로 다시 릴리스(release)할 때는, 자신의 빈 블록 비트맵에 있는 대응 비트를 간단히 클리어한다. 저장 시스템에서, 이것은 호스트의 빈 블록 비트맵 부분을 포함하게 되는 클러스터로의 기입 및 거의 저널 파일로의 기입으로서 명시된다; 자체가 비워지는 실제 클러스터 자체에 대한 입력/출력(I/O)은 아마도 거의 없을 것이다. 호스트 파일시스템이 어떤 향상된 보안 모드에서 작동 중이라면, 그 경우 그것은 아마도 상한(stale) 클러스터 콘텐츠가 공격자에 의해 판독될 수 있는 가능성을 줄이기 위하여 호스트에 의해 현재의 온 디스크 데이터의 과기입에 기인한 비워진 블록으로의 I/O가 있을 수 있 지만, 삭제 프로세스의 부분이 됨에 따라 그러한 기입을 식별할 방법이 없다. 따라서, 저장 디바이스는 호스트가 이전에 사용된 것을 사용하고 후속하여 빈 것으로 마킹되는 블록을 구별할 방법이 없다.

이러한 비워진 블록을 식별할 수 없는 저장 시스템의 무능함으로 인해 다수의 부정적인 결과를 초래할 수 있다. 예를 들면, 저장 시스템은 사용되고 있는 저장량을 상당히 과보고(over-report)하고 저장 공간을 매우 빠르게 소진할 것이다.

본 발명의 일 형태에 따라, 호스트 파일시스템의 제어 하에 데이터를 저장하는 블록-레벨 저장 시스템에 의해 데이터를 저장하는 방법이 제공된다. 이 방법은 호스트 파일시스템용으로 저장된 호스트 파일시스템 데이터 구조를 블록-레벨 저장 시스템에서 찾는 단계; 호스트 파일시스템 데이터 구조를 분석하여, 저장될 데이터와 관계된 데이터 유형을 식별하는 단계; 및 데이터 유형을 기초로 선택된 저장 기법을 사용하여 데이터를 저장하는 단계 - 이에 의해 서로 다른 데이터 유형을 갖는 데이터는 데이터 유형을 기초로 선택된 서로 다른 저장 기법을 사용하여 저장될 수 있음 - 를 포함한다.

본 발명의 다른 형태에 따라, 호스트 파일시스템의 제어 하에 데이터를 저장하는 블록-레벨 저장 시스템이 제공된다. 이 시스템은 호스트 파일시스템용으로 호스트 파일시스템 데이터 구조가 저장된 블록-레벨 스토리지, 블록-레벨 스토리지에 접속되어 동작하고, 블록-레벨 스토리지에 저장된 호스트 파일시스템 데이터 구조를 찾고, 호스트 파일시스템 데이터 구조를 분석하여 저장될 데이터와 관계된 데이터 유형을 식별하고, 데이터 유형을 기초로 선택된 저장 기법을 사용하여 데이터를 저장하는 저장(스토리지) 컨트롤러 - 이에 의해 서로 다른 데이터 유형을 갖는 데이터는 데이터 유형을 기초로 선택된 서로 다른 저장 기법을 사용하여 저장될 수 있음 - 를 포함한다.

다양한 대체 실시예에서, 데이터는 데이터 유형을 기초로 선택된 인코딩 기법 및/또는 스토리지 레이아웃을 사용하여 저장될 수 있다. 예를 들면, 빈번하게 액세스되는 데이터를 저장하여(예를 들면, 압축하지 않은 형태로 순차 저장하여) 액세스능력을 향상시킬 수 있는 한편, 빈번하지 않은 액세스 데이터를 (예를 들면, 데이터 압축 및/또는 비순차 저장을 사용하여) 저장함으로써 저장 효율을 향상시킬 수 있다. 부가적으로 또는 대안으로, 데이터는 데이터 유형에 따라 압축되고 및/또는 암호화될 수 있다.

다양한 대체 실시예에서, 호스트 파일시스템 데이터 구조는 파티션 테이블을 유지하는 단계, 파티션 테이블을 파싱하여 오퍼레이팅 시스템 파티션을 찾는 단계, 오퍼레이팅 시스템 파티션을 파싱하여 오퍼레이팅 시스템을 식별하고 오퍼레이팅 시스템 데이터 구조를 찾는 파싱 단계, 및 오퍼레이팅 시스템 데이터 구조를 파싱하여 호스트 파일시스템을 식별하고 호스트 파일시스템 데이터 구조를 찾는 단계를 포함한다. 오퍼레이팅 시스템 데이터 구조는 수퍼블록을 포함하고, 이 경우, 오퍼레이팅 시스템 데이터 구조는 수퍼블록을 파싱하는 단계를 포함할 수 있다. 호스트 파일시스템 데이터 구조는 호스트 파일시스템 데이터 구조의 작업 사본을 작성하고 그 작업 사본을 파싱하여 파싱될 수 있다.

전술한 발명의 특징들은 첨부 도면들을 참조하여 이하의 상세한 설명을 참조함으로써 더 잘 이해될 것이다.

도 1은 오브젝트가 저장을 위한 일련의 청크들로 파싱(parse)되는 본 발명의 실시예에 대한 예시이다.

도 2A 및 도 2B는 더 많은 저장의 추가의 결과로 청크에 대한 내장애성 저장을 위한 패턴이 어떻게 동적으로 변경될 수 있는지를 동일 실시예에서 예시한다.

도 3은 상이한 크기의 저장 디바이스들을 이용하여 구성된 저장 시스템에서 상이한 내장애성 패턴들로 청크들을 저장하는 것을 본 발명의 다른 실시예에서 예시한다.

도 4A, 도 4B, 및 도 4C는 비효율적인 저장 사용 및 낮은 레벨의 내장애성을 경고하기 위해 지시자 상태들이 이용되는 본 발명의 또 다른 실시예를 예시한다.

도 5는 본 발명의 실시예에 따른 데이터의 저장, 검색 및 재배치(re-layout)에 이용되는 기능적 모듈들의 블록도이다.

도 6은 3개 이상의 드라이브들을 포함하는 어레이에서 미러링(mirroring)이 이용되는 예를 도시한다.

도 7은 그들의 데이터를 저장하기 위해 상이한 레이아웃 방식들을 이용하는 몇몇 예시적인 존(zone)들을 도시한다.

도 8은 스파스 볼륨(sparse volume)들을 구현하기 위한 조회 테이블(lookup table)을 도시한다.

도 9는 본 발명의 예시적인 실시예에 따른, 이용 가능한 저장 공간을 갖고 내장애성 방식으로 동작하는 예시적인 어레이에 대한 상태 지시자들을 도시한다.

도 10은 본 발명의 예시적인 실시예에 따른, 리던던트 데이터 저장을 유지하기 위해 충분한 공간을 갖고 있지 않고 더 많은 공간이 추가되어야 하는 예시적인 어레이에 대한 상태 지시자들을 도시한다.

도 11은 본 발명의 예시적인 실시예에 따른, 고장의 경우에 리던던트 데이터를 유지할 수 없게 될 예시적인 어레이에 대한 상태 지시자들을 도시한다.

도 12는 본 발명의 예시적인 실시예에 따른, 저장 디바이스가 고장난 예시적인 어레이에 대한 상태 지시자들을 도시한다. 슬롯들 B, C, 및 D는 저장 디바이스들로 채워져 있다.

도 13은 예시적인 실시예의 상이한 소프트웨어 계층들 및 그들이 서로 어떻게 관련되는지를 나타내는 모듈 계층구조를 도시한다.

도 14는 본 발명의 예시적인 실시예에 따른, 존 내의 데이터 클러스터들에 액세스하기 위해 클러스터 액세스 테이블이 어떻게 이용되는지를 도시한다.

도 15는 본 발명의 예시적인 실시예에 따른 저널 테이블 업데이트를 도시한다.

도 16은 본 발명의 예시적인 실시예에 따른 드라이브 레이아웃을 도시한다.

도 17은 본 발명의 예시적인 실시예에 따른, 존 0(Zone 0)의 레이아웃 및 다른 존들이 어떻게 참조되는지를 설명한다.

도 18은 본 발명의 예시적인 실시예에 따른 판독 에러 핸들링을 설명한다.

도 19는 본 발명의 예시적인 실시예에 따른 기입 에러 핸들링을 설명한다.

도 20은 본 발명의 예시적인 실시예에 따른 에러 관리자(Error Manager)에 의한 불량 영역(bad Region)의 백업을 설명하는 논리 흐름도이다.

도 21은 본 발명의 예시적인 실시예에 따른 저장 어레이의 관련 컴포넌트들을 보여주는 개략 블록도이다.

도 22는 본 발명의 예시적인 실시예에 따른 가상 핫 스페어(virtual hot spare)를 관리하기 위한 예시적인 논리를 보여주는 논리 흐름도이다.

도 23은 본 발명의 예시적인 실시예에 따른, 도 22의 블록 2102에서와 같이, 각각의 가능한 디스크 고장에 대한 재배치 시나리오를 결정하기 위한 예시적인 논리를 보여주는 논리 흐름도이다.

도 24는 본 발명의 예시적인 실시예에 따른 가상 핫 스페어 기능을 호출(invoke)하기 위한 예시적인 논리를 보여주는 논리 흐름도이다.

도 25는 본 발명의 예시적인 실시예에 따른, 도 24의 블록 2306에서와 같이, 데이터의 내장애성을 복원하기 위해 하나 이상의 남아 있는 드라이브들을 자동으로 재구성하기 위한 예시적인 논리를 보여주는 논리 흐름도이다.

도 26은 본 발명의 예시적인 실시예에 따른, 저장 디바이스를 업데이트하기 위한 예시적인 논리를 보여주는 논리 흐름도이다.

도 27은 본 발명의 예시적인 실시예에 따른 컴퓨터 시스템의 개념적 블록도이다.

도 28은 본 발명의 예시적인 실시예에 따른, 파일시스템 인식 저장 컨트롤러 에 대한 고레벨 논리 흐름도이다.

도 29는 본 발명의 예시적 실시예에 따른, 호스트 파일시스템 데이터 구조를 찾기 위한 논리 흐름도이다.

도 30은 본 발명의 예시적 실시예에 따른, 미사용 저장 공간을 재이용하는 논리 흐름도이다.

도 31은 본 발명의 예시적 실시예에 따른, 데이터 유형에 기초한 사용자 데이터의 저장을 관리하는 논리 흐름도이다.

도 32는 본 발명의 예시적 실시예에 따른, 스캐빈저(scavenger)의 관련 컴포넌트를 도시하는 개략 블록도이다.

도 33은 본 발명의 예시적 실시예에 따른, 호스트 파일시스템 비트맵을 찾기 위한 의사(pseudo) 코드이다.

도 34는 본 발명의 예시적 실시예에 따른, BBUM에 대한 고레벨 의사 코드이다.

도 35는 본 발명의 예시적 실시예에 따른, 새로운 파티션을 생성하는 LBA 0 업데이트의 동기 처리를 위한 고레벨 의사 코드이다.

도 36은 본 발명의 예시적 실시예에 따른, 파티션을 (재)포맷하는 LBSA 0 업데이트의 동기 처리를 위한 고레벨 의사 코드이다.

도 37은 본 발명의 예시적 실시예에 따른, 파티션을 삭제하는 LBA 0 업데이트의 동기 처리를 위한 고레벨 의사 코드이다.

도 38은 본 발명의 예시적 실시예에 따른, 비동기 작업을 위한 고레벨 의사 코드이다.

정의. 이 설명 및 첨부 도면들에서 사용될 때, 다음의 용어들은 컨텍스트(context)가 달리 요구하지 않는 한, 지시된 의미들을 가질 것이다:

오브젝트의 "청크(chunk)"는, 사용되고 있는 임의의 물리적 저장과 무관하게 만들어진, 오브젝트의 추출 슬라이스(abstract slice)이고, 전형적으로 오브젝트의 일정한 수의 연속된 바이트들이다.

데이터 저장에 대한 내장애성 "패턴(pattern)"은 그에 의해 데이터가 하나 이상의 저장 디바이스들에 걸쳐서 리던던트하게 분배되는 특칭(particular)으로, 그 중에서도 특히, 미러링(예컨대, RAID1과 유사한 방식의), 스트라이핑(예컨대, RAID5와 유사한 방식의), RAID6, 이중 패리티(dual parity), 대각선 패리터(diagonal Parity), 저밀도 패리티 체크(Low Density Parity Check) 코드, 터보 코드, 또는 다른 리던던시 방식 또는 리던던시 방식들의 조합일 수 있다.

다른 청크가 주어진 청크와 동일한 데이터 콘텐츠를 갖는 경우를 제외하고, 그 주어진 청크가 임의의 다른 청크에 대한 해시 넘버와 일반적으로 다를 해시 넘버를 생성할 경우 주어진 청크에 대한 해시 넘버는 "유일(unique)"하다. 즉, 2개의 청크는 그들의 콘텐츠가 동일하지 않을 때는 언제나 일반적으로 상이한 해시 넘버들을 가질 것이다. 아래에서 더 상세히 설명되는 바와 같이, 이 컨텍스트에서 "유일"이라는 용어는, 이따금 동일하지 않은 청크들에 대하여 공통의 해시 넘버를 생성하는 해시 함수로부터 생성되는 해시 넘버를 포함하기 위해 사용된다. 왜냐하 면 해시 함수들은 상이한 청크들에 대하여 상이한 넘버들을 생성하는 것에 일반적으로 완벽하지 않기 때문이다.

"영역(Region)"은 저장 매체(예컨대, 하드 드라이브) 상의 연속된 물리적 블록들의 세트이다.

"존(Zone)"은 2 이상의 영역들로 구성된다. 존을 구성하는 영역들은 일반적으로 연속되어야 할 필요가 없다. 아래에서 설명되는 예시적 실시예들에서, 존은 1GB 상당의 데이터 또는 제어 정보를 저장한다.

"클러스터(Cluster)"는 존들 내의 단위 사이즈로 압축의 단위를 나타낸다(아래에서 설명됨). 아래에서 설명되는 예시적 실시예에서, 클러스터는 4KB(즉, 8개의 512바이트 섹터)이고 본질적으로 청크와 같다.

"리던던트 세트(Redundant set)"는 데이터의 세트에 대한 리던던시를 제공하는 섹터들/클러스터들의 세트이다.

"영역 백업(Backing up a Region)"은 하나의 영역의 콘텐츠를 다른 영역에 복사하는 것을 수반한다.

"제1 쌍(first pair)" 및 "제2 쌍(second pair)"의 저장 디바이스들은 공통 저장 디바이스를 포함할 수 있다.

"제1 복수(first plurality)" 및 "제2 복수(second plurality)"의 저장 디바이스들은 하나 이상의 공통 저장 디바이스들을 포함할 수 있다.

"제1 배열(first arrangement)" 및 "제2 배열(second arrangement)" 또는 "상이한 배열(different arrangement)"의 저장 디바이스들은 하나 이상의 공통 저장 디바이스들을 포함할 수 있다.

본 발명의 실시예에서, 파일시스템 인식 저장 시스템은 호스트 파일시스템의 저장 용도를 결정하기 위해 호스트 파일시스템 데이터 구조를 분석한다. 예를 들면, 블록 저장 디바이스는 호스트 파일시스템 데이터 구조를 파싱하여, 그러한 것을 사용 블록, 미사용 블록 및 데이터 유형으로 결정할 수 있다. 블록 저장 디바이스는 호스트 파일시스템의 저장 용도에 기초하여 물리적 저장을 관리한다.

그러한 파일시스템 인식 블록 저장 디바이스는 데이터의 물리적 저장에 관한 현명한 결정을 할 수 있다. 예를 들면, 파일시스템 인식 블록 저장 디바이스는 호스트 파일 시스템에 의해 릴리스된 블록을 식별하고, 시스템의 데이터 저장 능력을 효과적으로 확장하기 위해 그 릴리스된 블록을 재사용할 수 있다. 이 후, "스캐비닝" 또는 "가비지 수집"으로 칭해지는 그러한 릴리스된 블록의 재사용은, 호스트 파일시스템이 실제 물리적 저장 능력보다 더 많은 스토리지로 구성되는 가상 스토리지를 구현하는데 특히 유용하다. 파일시스템 인식 블록 저장 디바이스는 또한 파일시스템에 의해 저장된 오브젝트의 데이터 유형을 식별하고, 데이터 유형에 기초하여 서로 다른 저장 기법을 사용하여 그 오브젝트들을 저장할 수 있다(예를 들면, 빈번하게 액세스되는 데이터는 압축하지 않고 순차 블록으로 저장하는 반면, 빈번하지 않게 액세스되는 데이터는 압축하고 및/또는 비순차 블록으로 저장할 수 있다: 데이터 압축 및 암호화 같은 서로 다른 인코딩 기법을 데이터 유형에 기초하여 서로 다른 오브젝트에 적용가능하다).

파일시스템 인식 블록 저장 디바이스는 일반적으로 하위 데이터 구조(예를 들면, 빈 블록 비트맵)를 찾고 이용하는데 충분한 내부 작업을 "이해하는" 파일시스템의 사전설정된 세트를 지원할 것이다. 파일시스템 유형(예를 들면, NTFS, FAT, ReiserFS, ext3)을 결정하기 위해, 파일시스템 인식 블록 저장 디바이스는 전형적으로 파티션 테이블을 파싱하여 오퍼레이팅 시스템(OS) 파티션을 찾은 후 그 OS 파티션을 파싱하여 호스트 파일시스템의 수퍼블록을 찾음으로써 파일시스템 유형을 식별한다. 파일시스템 유형이 알려지기만 하면, 파일시스템 인식 블록 저장 디바이스는 수퍼블록을 파싱하여 호스트 파일시스템을 위한 빈 블록 비트맵을 찾을 수 있고, 그 후 빈 블록 비트맵을 파싱하여 사용된 블록과 미사용 블록을 식별할 수 있다.

시간에 따른 데이터 구조(예를 들면, 빈 블록 비트맵)의 변화를 검출하기 위해, 파일시스템 인식 블록 저장 디바이스는 주기적으로 데이터 구조의 사본을 (예를 들면, 사적인 비용장(non-redundant) 존에) 만들고, 후에 현재 활성 버전인 데이터 구조를 사전에 만들어놓은 사본과 비교하여 변화를 검출한다. 예를 들면, 가비지 수집 동작이 교정에 양호한 후보인 클러스터에 정확하게 적용되도록 하면서, 할당에서 빈 것으로 전이하는 임의의 비트맵 엔트리들이 식별될 수 있다. 각각의 비트맵 클러스터가 처리됨에 따라, 역사적 사본을 현재 사본으로 대체하여 비트맵 동작의 롤링 히스토리를 유지할 수 있다. 시간이 흐르면서 빈 블록 비트맵의 사본이 시간상 해체 클러스터의 패치워크가 될 수 있지만, 빈 엔트리를 찾는데 현재 사본을 사용할 수 있기 때문에, 이것은 어떠한 문제도 일으키지 않는다.

이후, 저장 어레이 시스템을 참조하여 예시적 실시예들을 설명한다.

도 1은 오브젝트가, 이 예에서는, 파일이 저장을 위한 일련의 청크들로 파싱되는 발명의 실시예에 대한 예시이다. 처음에 파일(11)은 저장 소프트웨어로 전달되어 거기서 그것은 오브젝트(12)로 지정되고 유일한 오브젝트 식별 번호, 이 경우에는, #007을 할당받는다. 이 새로운 오브젝트에 대한 할당을 나타내기 위해 오브젝트 테이블(13) 내에 새로운 엔트리(131)가 만들어진다. 오브젝트는 이제 오브젝트의 일정 길이 세그먼트들인 데이터(121, 122, 및 123)의 "청크들"로 파싱된다. 각 청크는 해싱 알고리듬을 통하여 전달되고, 해싱 알고리듬은 청크에 대한 유일한 해시 넘버를 반환한다. 이 알고리듬은 나중에 검색된(retrived) 청크에 적용될 수 있고 그 결과는 최초의 해시와 비교되어 재시도된(retried) 청크가 저장된 것과 동일하다는 것을 보장하게 된다. 각 청크에 대한 해시 넘버들은 오브젝트 테이블(13)에서 해당 오브젝트에 대한 엔트리 행(132)에 저장되어, 나중에 청크들의 수집에 의해 완전한 오브젝트가 검색될 수 있게 된다.

또한 도 1에서, 청크 해시들은 이제 청크 테이블(14) 내의 기존의 엔트리들과 비교된다. 기존의 엔트리(141)와 일치하는 임의의 해시는 이미 저장되어 있어 아무런 조치(action)도 취해지지 않는다(즉, 데이터는 다시 저장되지 않고, 결국 오브젝트들이 자동 압축되게 된다). 새로운 해시(청크 테이블(14) 내에 대응하는 엔트리가 없는 것)가 청크 테이블(141) 내에 입력된다. 그 후 청크 내의 데이터는 이용 가능한 저장 디바이스들(151, 152, 및 153)에 내장애성 저장을 위한 가장 효율적인 방법으로 저장된다. 이 방법은 청크 데이터가 예를 들어 하나 또는 2개의 디바이스들로 구성된 저장 시스템에 미러 방식(mirrored fashion)으로 또는 3개 이 상의 저장 디바이스들을 갖는 시스템에 패리티 스트라이브 방식으로(parity striped) 저장되는 결과로 될 수 있다. 이 데이터는 저장 디바이스들에서 물리적 위치들(1511, 1521, 및 1531)에 저장될 것이고, 이 위치들 및 위치들의 수는 청크 테이블 열들(143 및 142)에 저장되어, 청크의 모든 물리적 부분들이 나중에 위치 확인되어 검색될 수 있을 것이다.

도 2A 및 도 2B는 더 많은 저장의 추가의 결과로 청크에 대한 내장애성 저장을 위한 패턴이 어떻게 동적으로 변경될 수 있는지를 동일 실시예에서 예시한다. 특히, 도 2A 및 도 2B는 일단 전체 시스템에 추가의 저장이 추가되면 저장 디바이스들 상에 물리적으로 저장된 청크가 어떻게 새로운 패턴으로 레이아웃될 수 있는지를 보여준다. 도 2A에서, 저장 시스템은 2개의 저장 디바이스들(221 및 222)을 포함하고 청크 데이터는 내장애성을 제공하기 위해 2개의 저장 디바이스들의 위치들(2211 및 2221)에 물리적으로 미러(mirror)되어 있다. 도 2B에서 제3의 저장 디바이스(223)이 추가되고, 미러 패턴(mirrored pattern)보다 더 저장 효율적인 패턴인 패리터 스트라이프 방식(parity striped manner)으로 청크를 저장하는 것이 가능하게 된다. 청크는 이 새로운 패턴으로 3개의 물리적 위치들(2311, 2321, 및 2331)에 레이아웃되어, 이용 가능한 저장의 훨씬 더 낮은 비율을 차지한다. 청크 테이블(21)은 새로운 레이아웃이 3개의 위치들에 있는 것을 나타내도록(212) 업데이트되고 또한 새로운 청크 물리적 위치들(2311, 2321, 및 2331)이 기록된다(213).

도 3은 얼마간의 시간 동안 기능하고 있는 본 발명의 실시예에 따른 성숙한 저장 시스템을 보여준다. 이것은 저장 용량들이 다른 저장 디바이스들에서 청크들 이 시간에 걸쳐 어떻게 물리적으로 저장될 수 있는지를 예시한다. 이 도면은 40GB 저장 디바이스(31), 80GB 저장 디바이스(32) 및 120GB 저장 디바이스(33)로 구성된 저장 시스템을 보여준다. 처음에 청크들은 40GB 저장 디바이스(31)가 찰 때까지 내장애성 스트라이프 패턴(34)으로 저장된다. 그 후, 저장 공간의 부족으로 인해, 새로운 데이터는 80GB 저장 디바이스(32) 및 120GB 저장 디바이스(33) 상의 이용 가능한 공간에 미러 패턴(36)으로 저장된다. 일단 80GB 저장 디바이스(32)가 차면, 새로운 데이터는 단일 디스크 내장애성 패턴(37)으로 레이아웃된다. 저장 디바이스가 데이터를 저장하기 위한 단일 풀(pool)을 포함한다 하더라도, 청크들에 저장된 데이터 자체는 각종의 별개의 패턴들로 저장되어 있다.

도 4A 및 도 4B는 비효율적인 저장 사용 및 낮은 레벨의 내장애성을 경고하기 위해 지시자 상태들이 이용되는 발명의 또 다른 실시예를 예시한다. 도 4A에서, 모든 3개의 저장 디바이스들(41, 42, 및 45)은 자유(빈) 공간을 갖고 있고 지시자 라이트(44)는 데이터가 효율적이고 내장애성 방식으로 저장되어 있음을 지시하도록 녹색이다. 도 4B에서 40GB 저장 디바이스(41)는 차게 되었고, 따라서 새로운 데이터는 남아 있는 자유 공간을 갖는 2개의 저장 디바이스들(42 및 43)에만 미러 패턴(46)으로 저장될 수 있다. 데이터가 여전히 충분히 리던던트하지만 효율적으로 저장되지 않은 것을 지시하기 위하여, 지시자 라이트(44)는 황색(amber)으로 변하였다. 도 4C에서는, 120GB 저장 디바이스(13)만이 남아 있는 자유 공간을 갖고 있어 모든 새로운 데이터는 이 하나의 디바이스(43) 상에 미러 패턴으로만 저장될 수 있다. 내장애성은 덜 견고하고 시스템은 위급하게 공간이 부족하기 때문에, 지시자 라이트(44)는 적색으로 변하여 더 많은 저장의 추가가 필요함을 지시한다.

하나의 대안 실시예에서는, 어레이 내의 각 드라이브/슬롯마다, 예를 들어, 3색 라이트(예컨대, 녹색, 황색, 적색)의 형태로 지시자가 제공된다. 하나의 특정 실시예에서, 라이트들은 발광 효과(glowing effect)로 디스크 캐리어의 정면 전체를 비추기 위해 이용된다. 라이트들은 시스템의 전체 상태뿐만 아니라, 어느 드라이브/슬롯이 주의를 필요로 하는지(만일 있다면)도 지시하도록 제어된다. 각각의 3색 라이트는 적어도 4개의 상태, 구체적으로 오프, 녹색, 황색, 적색으로 놓일 수 있다. 특정 슬롯에 대한 라이트는 그 슬롯이 비어 있고 시스템이 충분한 저장 및 리던던시로 동작하고 있어 그 슬롯에 드라이브가 설치될 필요가 없다면 오프 상태로 놓일 수 있다. 특정 슬롯에 대한 라이트는 대응하는 드라이브가 충분하고 교체될 필요가 없다면 녹색 상태로 놓일 수 있다. 특정 슬롯에 대한 라이트는 시스템 동작이 열화되어 대응하는 드라이브의 보다 더 큰 드라이브로의 교체가 권장된다면 황색 상태로 놓일 수 있다. 특정 슬롯에 대한 라이트는 대응하는 드라이브가 설치 또는 교체되어야 한다면 적색 상태로 놓일 수 있다. 필요에 따라 또는 원하는 대로, 예를 들어, 라이트를 온 상태와 오프 상태 간에 번쩍이거나 또는 라이트를 2개의 상이한 색들 간에 번쩍임(예컨대, 드라이브가 교체된 후에 데이터의 재배치(re-layout)가 진행중일 때 적색과 녹색 간에 번쩍임)으로써, 추가 상태들이 지시될 수 있다.

물론, 시스템 상태 및 드라이브/슬롯 상태의 양쪽 모두를 지시하기 위해 다른 지시 기법들이 이용될 수 있다. 예를 들면, 시스템 상태 및, 필요하다면, 주의 를 필요로 하는 슬롯 번호를 지시하기 위해 단일 LCD 디스플레이가 이용될 수 있다. 또한, 다른 유형의 지시자들(예컨대, 슬롯 지시자 또는 각 슬롯에 대한 라이트와 함께 시스템에 대한 단일 상태 지시자(예컨대, 녹색/황색/적색)이 이용될 수 있다.

도 5는 도 1-3과 관련하여 위에서 논의된 것과 같은, 발명의 실시예에 따른 데이터의 저장, 검색 및 재배치에 이용되는 기능적 모듈들의 블록도이다. 통신을 위한 입구(entry) 및 출구(exit) 포인트는, 오브젝트들의 저장 또는 검색을 위해 오브젝트들을 시스템에 전달하기 위한 오브젝트 인터페이스(511), 저장 시스템이 하나의 대형 저장 디바이스인 것으로 보이게 하는 블록 인터페이스(512), 및 저장 시스템이 윈도즈 파일 시스템인 것으로 보이게 하는 CIFS 인터페이스(513)이다. 이들 인터페이스들이 데이터의 저장을 필요로 할 경우, 데이터는 청크 파서(Chunk Parser)(52)로 전달되고, 청크 파서(52)는 데이터의 청크들로의 분해를 수행하고 (도 1과 관련하여 위에서 논의된 바와 같이) 오브젝트 테이블(521) 내에 처음 엔트리를 생성한다. 그 후 이들 청크들은 해시 코드 생성기(53)에 전달되고, 해시 코드 생성기(53)는 각 청크에 대하여 관련 해시 코드들을 생성하고 이들을 오브젝트 테이블에 입력하여 (도 1과 관련하여 위에서 논의된 바와 같이) 각 오브젝트와 관련된 청크들이 리스트(512)되게 한다. 청크 해시 넘버들은 청크 테이블(531) 내의 엔트리들과 비교된다. 일치가 발견되는 경우에, 새로운 청크는 저장 시스템에 이미 저장된 청크와 동일할 것이므로 그 새로운 청크는 무시된다. 만일 청크가 새로운 것이면, 그에 대한 새로운 엔트리가 청크 테이블(531)에 만들어지고, 해싱된 청 크는 물리적 저장 관리자(physical storage manager)(54)에 전달된다. 물리적 저장 관리자는 이용 가능한 저장 디바이스들(571, 572, 및 573) 상에 가능한 가장 효율적인 패턴으로 청크를 저장하고 대응하는 엔트리를 청크 테이블(531)에 만들어 청크의 물리적 저장이 어디에 발생하였는지를 보여주어 (도 1과 관련하여 위에서 논의된 바와 같이) 청크의 콘텐츠가 나중에 검색(512)될 수 있게 한다.

오브젝트(511), 블록(512) 또는 CIFS(513) 인터페이스에 의한 도 5에서의 데이터의 검색은 검색 관리자(retrieval manager)(56)에의 요구에 의해 수행되고, 이 검색 관리자(56)는 오브젝트 테이블(521)을 참고(consult)하여 어느 청크들이 해당 오브젝트를 포함하는지를 결정한 다음 이들 청크들을 물리적 저장 관리자(54)에게 요구한다. 물리적 저장 관리자(54)는 청크 테이블(521)을 참고하여 요구된 청크들이 어디에 저장되어 있는지를 결정한 다음 그들을 검색하고 완성된 데이터(오브젝트)를 다시 검색 관리자(56)에 전달하고, 검색 관리자(56)는 그 데이터를 요구하는 인터페이스에 반환한다. 도 5에는 또한 내장애성 관리자(FTL : fault tolerant manager)(55)도 포함되어 있는데, 이것은 끊임없이 청크 테이블을 스캔하여 청크들이 가능한 가장 효율적인 방식으로 저장되어 있는지를 결정한다. (이것은 저장 디바이스들(571, 572, 및 573)이 추가 및 제거될 때 변할 수 있다.) 만일 청크가 가능한 가장 효율적인 방식으로 저장되어 있지 않다면, FTL은 물리적 저장 관리자(54)에게 청크에 대한 새로운 레이아웃 패턴을 생성하고 청크 데이블(531)을 업데이트하도록 요구할 것이다. 이런 식으로 모든 데이터는 (도 2 및 3과 관련하여 논의된 바와 같이) 어레이를 구성하는 저장 디바이스들의 수에 대하여 가능한 가장 효율적인 방식으로 저장된 상태로 계속 유지된다.

다음은 본 발명의 예시적 실시예에 대한 추가적인 상세들을 제공한다.

데이터 레이아웃 방식(Data Layout Scheme) - 존(Zones)

그 중에서도 특히, 존은 디스크에 저장되어 있는 실제 데이터로부터 리던던시 및 디스크 재배치를 숨기는 효과를 갖는다. 존들은 존의 사용자에게 영향을 미치지 않고 추가 레이아웃 방법들이 추가 및 변경되도록 허용한다.

저장 어레이는 디스크 상에서 존이라 불리는 가상 섹션들에 데이터를 레이아웃한다. 존은 주어진 일정량의 데이터(예를 들어 1G 바이트)를 저장한다. 존은 단일 디스크 상에 존재하거나 또는 하나 이상의 드라이브들에 걸쳐 있을 수 있다. 존의 물리적 레이아웃은 해당 존에 대하여 특정된 형태로 리던던시를 제공한다.

도 6은 3개 이상의 드라이브들을 포함하는 어레이에서 미러링(mirroring)이 이용되는 예를 도시한다. 도 7은 그들의 데이터를 저장하기 위해 상이한 레이아웃 방식들을 이용하는 몇몇 예시적인 존들을 도시한다. 도면은 존이 1GB의 데이터를 저장한다고 가정한다. 다음 점들에 유의하자:

ⅰ) 다수의 드라이브들에 걸쳐 있는 존은 반드시 세트에 걸쳐서 드라이브 내에 동일한 오프셋을 이용하지는 않는다.

ⅱ) 단일 드라이브 미러는 1G의 데이터를 저장하기 위해 2G의 저장을 필요로 한다.

ⅲ) 2중 드라이브 미러는 1G의 데이터를 저장하기 위해 2G의 저장을 필요로 한다.

ⅳ) 3 드라이브 스트라이프는 1G의 데이터를 저장하기 위해 1.5G의 저장을 필요로 한다.

ⅴ) 4 드라이브 스트라이프는 1G의 데이터를 저장하기 위해 1.33G의 저장을 필요로 한다.

ⅵ) 존 A, 존 B 등은 임의의 존 명칭들이다. 실제 구현에서 각 존은 유일 번호로 식별될 것이다.

ⅶ) 도면에 의해 암시되기는 하지만, 존들은 반드시 디스크 상에서 연속되는 것은 아니다(나중에 영역들 참조).

ⅷ) 미러링이 2개의 드라이브에 제한되는 기술적 이유는 없다. 예를 들면, 3 드라이브 시스템에서 데이터의 1 사본은 1 드라이브에 저장될 수 있고 미러링된 데이터의 절반은 다른 2개의 드라이브의 각각에 저장될 수 있다. 마찬가지로, 데이터는 3개의 드라이브에 걸쳐서 미러링되어, 데이터의 절반은 2개의 드라이브의 각각에 그리고 미러의 절반은 다른 2개의 드라이브에 있을 수 있다.

데이터 레이아웃 방식 - 영역(Regions)

각 디스크는 동일 사이즈의 영역들의 세트로 분할된다. 영역의 사이즈는 존보다 훨씬 작고 존은 하나 이상의 디스크들로부터의 하나 이상의 영역들로 구성된다. 디스크 공간의 효율적인 사용을 위하여, 영역의 사이즈는 전형적으로 상이한 존 사이즈들 및 어레이에 의해 지지되는 상이한 수의 디스크들의 공통 인자(common factor)이다. 예시적인 실시예에서, 영역들은 존의 데이터 사이즈의 1/12이다. 다음의 표는 본 발명의 예시적 실시예에 따른, 각종 레이아웃에 대한 영역 수/존(number of Regions/Zone) 및 영역 수/디스크(number of Regions/disk)를 리스트한다.

레이아웃 방법	영역 수/존	영역 수/디스크
1 드라이브 미러	24	24
2 드라이브 미러	24	12
3 드라이브 스트라이프	18	6
4 드라이브 스트라이프	16	4

개개의 영역들은 사용(used), 자유(free) 또는 불량(bad)으로 표시(mark)될 수 있다. 존이 생성될 때, 적당한 디스크들로부터의 자유 영역들의 세트가 선택되어 테이블에 로그인된다. 이들 영역들은 임의의 순서로 있을 수 있고 디스크 상에서 연속될 필요는 없다. 데이터가 존에 기입되거나 존으로부터 판독될 때, 액세스는 적당한 영역으로 리다이렉트된다. 그 중에서도 특히, 이것은 데이터 재배치가 유연하고 효율적인 방식으로 발생하도록 허용한다. 시간에 걸쳐서, 상이한 사이즈의 존들이 조각화(fragmentation)를 일으켜서, 완전한 존을 유지하기에는 너무 작은 다수의 디스크 영역들(disk areas)을 남길 수 있을 것이다. 적당한 영역 사이즈를 이용함으로써, 조각화에 의해 남겨진 모든 갭들이 사이즈에서 적어도 하나의 영역이 되어, 전체 디스크를 조각 모음(de-fragment)하지 않고도 이들 작은 갭들의 용이한 재사용을 가능케 할 것이다.

데이터 레이아웃 방식 - 재배치(Re-Layout)

구현을 용이하게 하기 위하여, 일정한 시퀀스의 확장 및 수축이 실시될 수 있다. 예를 들면, 2개의 드라이브가 갑자기 추가되면, 존의 확장은 제2의 드라이브를 통합하기 위해 제2 확장이 수행되기 전에 마치 하나의 드라이브가 추가된 것처럼 중간 확장을 거칠 수 있다. 대안적으로, 다수의 드라이브를 수반하는 확장 및 수축은, 중간 단계 없이, 자동으로 핸들링될 수 있다.

임의의 재배치가 발생하기 전에, 요구되는 공간이 이용 가능해야 한다. 이것은 불필요한 재배치가 발생하지 않도록 하기 위해 재배치를 시작하기 전에 계산되어야 한다.

데이터 레이아웃 방식 - 드라이브 확장(Drive Expansion)

다음은 발명의 예시적인 실시예에 따라서 단일 드라이브 미러링으로부터 2중 드라이브 미러링으로 확장하는 일반적인 프로세스를 설명한다:

ⅰ) 단일 드라이브 미러가 데이터 'A' 및 미러 'B'를 갖는다고 가정하고

ⅱ) 'C' 상에 존을 확장하기 위해 드라이브 상의 12개 영역들을 할당하고

ⅲ) 미러 'B'를 영역 세트 'C'에 복사하고

ⅳ) 이미 복사된 데이터에 행해진 임의의 기입들은 'C' 내의 적당한 위치에 미러링되어야 하고

ⅴ) 복사가 완료될 때, 존 테이블을 새로운 레이아웃 타입으로 업데이트하고 'B'에의 포인터들을 'C'에의 포인터들로 교체하고

ⅵ) 'B'를 구성하는 영역들을 자유로 표시(mark)한다.

다음은 발명의 예시적인 실시예에 따라서 2중 드라이브 미러링을 3중 드라이브 패리티 스트라이핑(triple drive striping with parity)으로 확장하는 일반적인 프로세스를 설명한다:

ⅰ) 하나의 드라이브가 데이터 'A'를 갖고 제2 드라이브가 미러 'B'를 갖는다고 가정하고

ⅱ) 패리티 정보 'C'를 위하여 제3 드라이브 상의 6개의 영역들을 할당하고

ⅲ) 'A'의 처음 6개 영역들 및 'B'의 두 번째 6개 영역들을 이용하여 패리티 정보를 계산하고

ⅳ) 패리티 정보를 'C'에 배치하고

ⅴ) 이미 처리된 데이터에 행해진 임의의 기입들은 'C' 내의 적당한 위치에 패리티되어야 하고

ⅵ) 복사가 완료될 때, 존 테이블을 새로운 레이아웃 타입으로 업데이트하고 테이블을 'A'의 제1 절반, 'B'의 제2 절반 및 'C'에 포인팅하고

ⅶ) 'A'의 제2 절반 및 'B'의 제1 절반을 자유로 표시한다.

다음은 발명의 예시적인 실시예에 따라서 3중 드라이브 스트라이핑을 4중 드라이브 패리티 스트라이핑(quad drive striping with parity)으로 확장하는 일반적인 프로세스를 설명한다:

ⅰ) 하나의 드라이브가 데이터 'A'를 갖고, 제2 드라이브가 데이터 'B'를 갖고, 제3 드라이브가 패리터 'P'를 갖는다고 가정하고

ⅱ) 스트라이프 데이터 'C'를 위하여 제4 드라이브 상의 4개의 영역들을 할당하고

ⅲ) 'A'의 마지막 2개 영역들을 'C'의 처음 2개 영역들에 복사하고

ⅳ) 'B'의 처음 2개 영역들을 'C'의 영역들 마지막에 복사하고

ⅴ) 패리티 드라이브 'D' 상의 4개의 영역들을 할당하고

ⅵ) A의 처음 4개 영역들, 및 B의 마지막 4개 영역들을 이용하여 패리티 정보를 계산하고

ⅶ) 패리티 정보를 'D'에 배치하고

ⅷ) 이미 처리된 데이터에 행해진 임의의 기입들은 'D' 내의 적당한 위치에 패리티되어야 하고

ⅸ) 존 테이블을 새로운 레이아웃 타입으로 업데이트하고 테이블을 'A'의 처음 4개 영역들, 'C', 'B'의 두 번째 4개의 영역들 및 'D'에 포인팅하고

ⅹ) 'A'의 마지막 3개 영역들 및 'B'의 처음 2개 영역들을 자유로 표시한다.

데이터 레이아웃 방식 - 드라이브 수축(Drive Contraction)

드라이브 수축은 디스크가 제거되거나 고장났을 때 발생한다, 그러한 경우, 어레이는 가능하다면 모든 존들을 다시 리던던트 상태로 하기 위해 데이터를 수축시킨다. 드라이브 수축은 팽창보다 선택할 것이 더 많기 때문에 팽창보다 약간 더 복잡하다. 그러나, 레이아웃 방법들 간의 전이는 팽창과 유사한 방식으로, 다만 반대로 일어난다. 재생될 데이터의 양을 최소한도로 유지함으로써 되도록 신속히 리던던시가 달성될 수 있다. 일반적으로 드라이브 수축은 모든 존들이 재배치 될 때까지 공간이 이용 가능한 동안 하나의 존보다 앞서 일어난다. 일반적으로, 제거되거나 고장난 디스크 상에 존재하는 데이터만 재구성될 것이다.

수축 방법 선택

다음 표는 본 발명의 예시적인 실시예에 따른, 재배치될 필요가 있는 각 존에 대한 판정 트리(decision tree)를 설명한다:

존 타입 데이터 분실	상태	조치
무엇이든	존 재배치를 위해 이용 가능한 공간이 없음	새로운 디스크가 추가되거나 제거된 디스크가 교체될 때까지 존을 퇴화 상태로 놔둔다
단일 드라이브 미러	데이터 불일치	시스템을 록 다운(lock down)하고 리셋 또는 분실한 드라이브가 교체되기를 기다린다
2중 드라이브 미러	시스템에 1 디스크가 남겨짐	단일 드라이브 미러로 변환
	남아 있는 데이터를 포함하는 드라이브에서만 공간이 이용 가능함	단일 드라이브 미러로 변환
	시스템에 2 또는 3 디스크가 남겨지고 공간이 이용 가능함	다른 드라이브 상에 미러를 재구성
3 드라이브 스트라이핑	시스템에 2 디스크가 남겨지고 공간이 이용 가능함	2중 드라이브 미러링으로 변환
3 드라이브 스트라이핑	시스템에 3 디스크가 남겨지고 공간이 이용 가능함	제3 드라이브 상에 분실한 스트라이프 세그먼트를 재구성
4 드라이브 스트라이핑	시스템에 3 디스크가 남겨지고 공간이 이용 가능함	3 드라이브 스트라이핑으로 변환

다음은 발명의 예시적인 실시예에 따라서 2중 드라이브 미러링으로부터 단일 드라이브 미러링으로 수축하는 일반적인 프로세스를 설명한다:

ⅰ) 단일 드라이브 미러가 데이터 'A'를 갖고 있고 미러 'B'를 분실하였거나 그 반대라고 가정하고

ⅱ) 'A'를 포함하는 드라이브 상의 12개 영역을 'C'로서 할당하고

ⅲ) 데이터 'A'를 영역 세트 'C'에 복사하고

ⅴ) 복사가 완료될 때, 존 테이블을 새로운 레이아웃 타입으로 업데이트하고 'B'에의 포인터들을 'C'에의 포인터들로 교체한다.

다음은 발명의 예시적인 실시예에 따라서 3중 드라이브 스트라이프로부터 2중 드라이브 미러로 수축하는 일반적인 프로세스(패리티 분실)를 설명한다:

ⅰ) 스트라이프가 상이한 드라이브들 상의 데이터 블록들 'A', 'B' 및 'C'로 이루어져 있다고 가정한다. 패리티 'C'가 분실되었다.

ⅱ) 'A'를 존의 처음 절반을 포함하는 것으로 'B'를 존의 두 번째 절반을 포함하는 것으로 정의하고

ⅲ) 'A' 드라이브 상의 6개 영역들 'D' 및 'B' 드라이브 상의 6개 영역들 'E'를 할당하고

ⅳ) 'A'를 'E'에 복사하고

ⅴ) 'B'를 'D'에 복사하고

ⅵ) 이미 복사된 데이터에 행해진 임의의 기입들은 'D' 및 'E' 내의 적당한 위치에 미러링되어야 하고

ⅶ) 복사가 완료될 때, 존 테이블을 새로운 레이아웃 타입으로 업데이트하고 'A'/'D' 및 'E'/'B'에의 포인터들을 설정한다.

다음은 발명의 예시적인 실시예에 따라서 3중 드라이브 스트라이프로부터 2중 드라이브 미러로 수축하는 일반적인 프로세스(데이터 분실)를 설명한다:

ⅰ) 스트라이프가 상이한 드라이브들 상의 데이터 블록들 'A', 'B' 및 'C'로 이루어져 있다고 가정한다. 데이터 'C'가 분실되었다.

ⅱ) 'A'를 존의 처음 절반을 포함하는 것으로 'C'를 존의 두 번째 절반을 포함하는 것으로 정의하고

ⅳ) 'A'를 'E'의 처음 절반에 복사하고

ⅴ) 'A' 및 'B'로부터 분실한 데이터를 재구성하고, 데이터를 'D'에 기입하고

ⅵ) 'D'를 'E'의 두 번째 절반에 복사하고

ⅶ) 이미 복사된 데이터에 행해진 임의의 기입들은 'D' 및 'E' 내의 적당한 위치에 미러링되어야 하고

ⅷ) 복사가 완료될 때, 존 테이블을 새로운 레이아웃 타입으로 업데이트하고 'A'/'D' 및 'E'에의 포인터들을 설정하고

ⅸ) 'B' 영역들을 자유로 표시한다.

다음은 발명의 예시적인 실시예에 따라서 4중 드라이브 스트라이프로부터 3중 드라이브 스트라이프로 수축하는 일반적인 프로세스(패리티 분실)를 설명한다:

ⅰ) 스트라이프가 상이한 드라이브들 상의 데이터 블록들 'A', 'B', 'C' 및 'D'로 이루어져 있다고 가정한다. 패리티 'D'가 분실되었다.

ⅱ) 'A'를 존의 처음 1/3을 포함하는 것으로 'B'를 존의 두 번째 1/3을 포함하는 것으로 'C'를 존의 세 번째 1/3을 포함하는 것으로 정의하고

ⅲ) 'A' 드라이브 상의 2개 영역들 'G', 'C' 드라이브 상의 2개 영역들 'E' 및 IB· 드라이브 상의 2개 영역들 'F'를 할당하고

ⅳ) 'B'의 처음 절반을 'G'에 복사하고

ⅴ) 'B'의 두 번째 절반을 'E'에 복사하고

ⅵ) 'A'/'G' 및 'E'/'C'로부터 패리티를 구성하여 'F'에 기입하고

ⅵ) 이미 복사된 데이터에 행해진 임의의 기입들은 'G', 'E' 및 'F' 내의 적당한 위치에 미러링되어야 하고

ⅶ) 복사가 완료될 때, 존 테이블을 새로운 레이아웃 타입으로 업데이트하고 'A'/'G', 'E'/'C' 및 'F'에의 포인터들을 설정하고

ⅸ) 'B' 영역들을 자유로 표시한다.

다음은 발명의 예시적인 실시예에 따라서 4중 드라이브 스트라이프로부터 3중 드라이브 스트라이프로 수축하는 일반적인 프로세스(처음 1/3 분실)를 설명한다:

ⅰ) 스트라이프가 상이한 드라이브들 상의 데이터 블록들 'A', 'B', 'C' 및 'D'로 이루어져 있다고 가정한다. 데이터 'A'가 분실되었다.

ⅱ) 'A'를 존의 처음 1/3을 포함하는 것으로 'B'를 존의 두 번째 1/3을 포함하는 것으로 'C'를 존의 세 번째 1/3을 포함하는 것으로 그리고 'D'를 패리터로서 정의 하고

ⅲ) 'B' 드라이브 상의 4개 영역들 'E', 'C' 드라이브 상의 2개 영역들 'F' 및 'D' 드라이브 상의 6개 영역들 'G'를 할당하고

ⅳ) 'B'의 두 번째 절반을 'F'에 복사하고

ⅴ) 'B', 'C' 및 'D'로부터 분실한 데이터를 구성하여 'E'에 기입하고

ⅵ) 'E'/'B'의 처음 절반 및 'F'/'C'로부터 새로운 패리티를 구성하여 'G'에 기입하고

ⅶ) 이미 복사된 데이터에 행해진 임의의 기입들은 'B', 'E', 'F' 및 'G' 내의 적당한 위치에 미러링되어야 하고

ⅷ) 복사가 완료될 때, 존 테이블을 새로운 레이아웃 타입으로 업데이트하고 'E'/'B'의 처음 절반 및 'F'/'C' 및 'G'에의 포인터들을 설정하고

ⅸ) 'B'의 두 번째 절반 및 'D' 영역들을 자유로 표시한다.

다음은 발명의 예시적인 실시예에 따라서 4중 드라이브 스트라이프로부터 3중 드라이브 스트라이프로 수축하는 일반적인 프로세스(두 번째 1/3 분실)를 설명한다:

ⅰ) 스트라이프가 상이한 드라이브들 상의 데이터 블록들 'A', 'B', 'C' 및 'D'로 이루어져 있다고 가정한다. 데이터 'B'가 분실되었다.

ⅱ) 'A'를 존의 처음 1/3을 포함하는 것으로 'B'를 존의 두 번째 1/3을 포함하는 것으로 'C'를 존의 세 번째 1/3을 포함하는 것으로 그리고 'D'를 패리터로서 정의하고

ⅲ) 'A' 드라이브 상의 2개 영역들 'E', 'C' 드라이브 상의 2개 영역들 'F' 및 'D' 드라이브 상의 6개 영역들 'G'를 할당하고

ⅳ) 'A'의 처음 절반, 'C'의 처음 절반 및 'D'의 처음 절반으로부터 분실한 데이터를 구성하여 'E'에 기입하고

ⅴ) 'A'의 두 번째 절반, 'C'의 두 번째 절반 및 'D'의 두 번째 절반으로부터 분실한 데이터를 구성하여 'F'에 기입하고

ⅵ) 'A'/'E' 및 'F'/'C'로부터 새로운 패리티를 구성하여 'G'에 기입하고

ⅶ) 이미 복사된 데이터에 행해진 임의의 기입들은 'E', 'F' 및 'G' 내의 적당한 위치에 미러링되어야 하고

ⅷ) 복사가 완료될 때, 존 테이블을 새로운 레이아웃 타입으로 업데이트하고 'E', 'F' 및 'G'에의 포인터들을 설정하고

ⅸ) 'D' 영역들을 자유로 표시한다.

다음은 발명의 예시적인 실시예에 따라서 4중 드라이브 스트라이프로부터 3중 드라이브 스트라이프로 수축하는 일반적인 프로세스(세 번째 1/3 분실)를 설명한다:

ⅰ) 스트라이프가 상이한 드라이브들 상의 데이터 블록들 'A', 'B', 'C' 및 'D'로 이루어져 있다고 가정한다. 데이터 'C'가 분실되었다.

ⅲ)'A' 드라이브 상의 2개 영역들 'E', 'B' 드라이브 상의 4개 영역들 'F' 및 'D' 드라이브 상의 6개 영역들 'G'를 할당하고

ⅳ) 'B'의 처음 절반을 'E'에 복사하고

ⅴ) 'A', 'B' 및 'D'로부터 분실한 데이터를 구성하여 'F'에 기입하고

ⅵ) 'A'/'E' 및 'B'의 두 번째 절반/'F'로부터 새로운 패리티를 구성하여 'G'에 기입하고

ⅷ) 복사가 완료될 때, 존 테이블을 새로운 레이아웃 타입으로 업데이트하고 'A'/'E' 및 'B'의 두 번째 절반/'F' 및 'G'에의 포인터들을 설정하고

ⅸ) 'B'의 처음 절반 및 'D' 영역들을 자유로 표시한다.

예를 들면, 도 3을 다시 참조하여, 드라이브 2 상에 이용 가능한 충분한 공간이 있다는 것을 조건으로 하여, 드라이브 0 또는 드라이브 1이 분실되면 드라이브 2 상에 2중 드라이브 미러(존 B)가 재구성될 수 있다. 유사하게, 드라이브 3 상에 이용 가능한 충분한 공간이 있다는 것을 조건으로 하여, 드라이브 0-2 중 어느 하나가 분실되면 드라이브 3을 이용하여 3중 드라이브 스트라이프(존 C)가 재구성될 수 있다.

데이터 레이아웃 방식 - 존 재구성(Zone Reconstruction)

존 재구성은 드라이브가 제거되었고 이상적인 존 재배치를 위하여 남아 있는 드라이브들 상에 충분한 공간이 있거나 또는 드라이브가 보다 큰 사이즈의 새로운 드라이브로 교체된 경우에 발생한다.

다음은 발명의 예시적인 실시예에 따라서 2중 드라이브 미러 재구성의 일반적인 프로세스를 설명한다:

ⅰ) 단일 드라이브 미러가 데이터 'A'를 갖고 있고 미러 'B'를 분실하였다고 가정하고

ⅱ) 'A'를 포함하는 것 이외의 드라이브 상의 12개 영역 'C'를 할당하고

ⅲ) 데이터 'A'를 'C'에 복사하고

ⅳ) 이미 복사된 데이터에 행해진 임의의 기입들은 'C' 내의 적당한 위치에 미 러링되어야 하고

ⅴ) 복사가 완료될 때,'B'에의 존 테이블 포인터들을 'C'에의 포인터들로 업데 이트한다.

다음은 발명의 예시적인 실시예에 따라서 3중 드라이브 스트라이프 재구성의 일반적인 프로세스를 설명한다:

ⅰ) 하나의 드라이브가 데이터 'A'를 갖고 있고, 제2 드라이브가 데이터 'B'를 갖고 있고, 제3 드라이브가 패리티 'P'를 갖고 있다고 가정한다. 'B'는 분실되었다. 어느 부분이 분실되었는지는 중요하지 않고, 필요한 조치는 모든 경우에 동일하다는 것에 유의하자.

ⅱ) 'A' 및 'P'를 포함하는 것 이외의 드라이브 상의 6개 영역들 'D'를 할당하고

ⅲ) 'A' 및 'P'로부터 분실한 데이터를 구성하여, 데이터를 'D'에 기입하고

ⅳ) 이미 처리된 데이터에 행해진 임의의 기입들은 'D' 내의 적당한 위치에 패리티되어야 하고

ⅴ) 'B'에의 포인터들을 'D'에의 포인터들로 교체함으로써 존 테이블을 업데이트한다.

이 예시적인 실시예에서, 4-드라이브-재구성은 제거된 드라이브가 다른 드라이브로 교체된 경우에만 발생할 수 있다. 그 재구성은 새로운 드라이브 상의 6개 영역들을 할당하고 분실한 데이터를 다른 3개의 영역 세트들로부터 재구성하는 것으로 구성된다.

데이터 레이아웃 방식 - 일시적 드라이브 분실 문제

드라이브가 제거되고 재배치를 위한 공간이 없을 경우, 구 드라이브가 다시 플러그 접속되거나 그 드라이브가 새로운 드라이브로 교체될 때까지 어레이는 계속해서 퇴화된 모드에서 동작할 것이다. 새로운 드라이브가 플러그 접속되면, 드라이브 세트는 재구성되어야 한다. 이 경우, 데이터는 재배치될 것이다. 만일 구 디스크가 어레이로 다시 배치되면, 더 이상 현 디스크 세트의 일부가 아니고 새로운 디스크로 간주될 것이다. 그러나, 새로운 디스크가 어레이에 배치되지 않고 구 디스크가 다시 배치되면, 구 디스크는 비록 구식 멤버이긴 하지만 여전히 디스크 세트의 멤버로서 인식될 것이다. 이 경우, 이미 재배치된 임의의 존들은 그들의 새로운 구성을 유지할 것이고 구 디스크 상의 영역들은 자유롭게 될 것이다. 재배치되지 않은 임의의 존들은 여전히 구 디스크의 적당한 영역들을 가리킬 것이다. 그러나, 퇴화된 존들에 어떤 기입들이 수행되었을지도 모르므로, 이들 존들은 리프레시될 필요가 있다. 발생한 기입마다 모두 로깅(logging)하기보다는, 변경된 퇴화된 영역들이 표시(mark)될 수 있다. 이런 식으로, 디스크가 교체될 때, 변경된 영역들만 리프레시될 필요가 있다.

또한, 기입된 존들은 재배치를 위한 우선 순위 리스트에서 더 위에 배치될 수 있다. 이렇게 함으로써 디스크가 교체되면 리프레시될 필요가 있는 영역들의 수가 저감될 것이다. 타임아웃이 이용될 수도 있고, 그 시점 후에 디스크는, 교체되더라도, 지워질(wipe) 것이다. 그러나, 이 타임아웃은 수분이 아니라 어쩌면 수시간으로 매우 클 수 있다.

데이터 레이아웃 방식 - 데이터 무결성(Data Integrity)

위에서 논의된 바와 같이, 표준 RAID 시스템에서의 하나의 문제점은 디스크 어레이의 드물게 사용되는 영역들에서 디스크 표면 훼손이 발생할 수 있다는 점이다. 다른 드라이브가 고장나는 경우에, 훼손이 발생하였음을 항상 결정할 수 있는 것은 아니다. 그 경우, 훼손된 데이터는 RAID 어레이가 고장난 드라이브를 재구성할 때 전파되어 보존될 수 있다.

위에서 논의된 해시 메커니즘은 RAID 하에서 이용 가능한 것에 비하여 데이터 훼손 검출을 위한 추가 메커니즘을 제공한다. 다른 곳에 언급되어 있는 바와 같이, 청크가 저장될 때, 그 청크에 대하여 해시 값이 계산되어 저장된다. 청크가 판독될 때 언제라도, 검색된 청크에 대한 해시 값이 계산되고 저장된 해시 값과 비교될 수 있다. 만일 해시 값이 일치하지 않으면(훼손된 청크를 나타냄), 청크 데이터는 리던던트 데이터로부터 복구될 수 있다.

디스크 상의 데이터 훼손이 발생할 수 있는 시간 윈도(time window)를 최소화하기 위하여, 되도록 신속히 훼손된 데이터를 찾아 정정하기 위해 디스크들의 정기적인 스캔이 수행될 것이다. 그것은 또한, 선택적으로, 어레이로부터의 판독 시에 체크가 수행되도록 할 것이다.

데이터 레이아웃 방식 - 볼륨(Volume)

스파스 볼륨(sparse volume)에서는, 어레이 내의 디스크들 상에서 이용 가능한 저장 공간의 양에 관계없이, 어레이는 항상 일정한 사이즈 - 예컨대, M 테라바이트 - 임을 주장한다. 어레이가 S 바이트의 실제 저장 공간을 포함하고(S <= M), 데이터가 M 테라바이트 공간 내의 위치들 L1, L2, L3 등에 저장되도록 요구될 수 있다고 가정하자, 만일 요구된 위치 Ln > S이면, Ln에 대한 데이터는 위치 Pn < S에 저장되어야 한다. 이것은, 도 8에 도시된 바와 같이, Ln에 기초하여 Pn을 인덱싱하는 조회 테이블(lookup table)을 포함함으로써 관리된다. 이 특징은 어레이가 윈도즈(Windows), 리눅스(Linux), 및 애플(Apple) 운영 시스템들과 같은, 볼륨 확장을 지원하지 않는 운영 시스템과 함께 작동하도록 허용한다. 또한, 어레이는 모두가 동일 물리적 저장을 공유하는 다수의 스파스 볼륨들을 제공할 수 있다. 각 스파스 볼륨은 전용 조회 테이블을 갖겠지만, 데이터 저장을 위하여 동일 물리적 공간을 공유할 것이다

드라이브 슬롯 지시자(Drive slot indicators)

위에서 논의된 바와 같이, 저장 어레이는 하나 이상의 드라이브 슬롯들로 이루어진다. 각 드라이브 슬롯은 비어 있거나 하드 디스크 드라이브를 포함할 수 있다. 각 드라이브 슬롯은 4개의 상태, 오프(Off), OK, 퇴화(Degraded) 및 고장(Fail)을 지시할 수 있는 전용 지시자를 갖는다. 상태들은 일반적으로 다음과 같이 해석된다.

지시자 상태	어레이 사용자에 대한 의미
오프(Off)	드라이브 슬롯이 비어 있고 추가 드라이브가 삽입될 수 있음
OK	슬롯 내의 드라이브가 바르게 기능하고 있음
퇴화(Degraded)	사용자에 의한 조치가 권장됨: 슬롯이 비어 있으면, 이 슬롯에 드라이브를 추가하고; 슬롯이 드라이브를 포함하고 있으면, 드라이브를 다른 더 높은 용량의 드라이브로 교체한다.
고장(Fail)	사용자에 의한 조치가 가능한 빨리 요구됨: 슬롯이 비어 있으면, 이 슬롯에 드라이브를 추가하고; 슬롯이 드라이브를 포함하고 있으면, 드라이브를 다른 더 높은 용량의 드라이브로 교체한다.

이 예시적 실시예에서, 적색/황색/녹색 발광 다이오드(LED)들이 지시자들로서 사용된다. LED들은 일반적으로 다음과 같이 해석된다.

LED 상태	지시자 상태	상태들이 발생할 수 있는 상황 예	도면
오프	오프	슬롯이 비어 있다. 어레이가 이용 가능한 공간을 갖고 있다.	9,10,12
녹색	OK	드라이브가 바르게 기능하고 있고, 어레이 데이터가 리던던트하고 어레이가 이용 가능한 디스크 공간을 갖고 있다.	9,10,11,12
황색	퇴화	어레이가 고장 상태에 접근하고 있다; 디스크 고장의 경우에 리던던트 데이터를 유지하기 위해 충분한 공간이 없다.	11
적색	고장	이 슬롯 내의 디스크가 고장나서 교체되어야 한다; 어레이는 리던던트 데이터 저장을 유지하기 위해 충분한 공간을 갖고 있지 않고 더 많은 공간이 추가되어야 한다.	10,12

도 9는 본 발명의 예시적인 실시예에 따라서, 이용 가능한 저장 공간을 갖고 내장애성 방식으로 동작하는 예시적인 어레이를 도시한다. 슬롯들 B, C, 및 D는 저장 디바이스들로 채워져 있고, 추가 데이터를 리던던트하게 저장하기 위해 이용 가능한 충분한 저장 공간이 있다. 슬롯들 B, C, 및 D에 대한 지시자들은 녹색이고(이들 저장 디바이스들이 바르게 동작하고 있고, 어레이 데이터는 리던던트하고, 어레이는 이용 가능한 디스크 공간을 갖고 있음을 지시함), 슬롯 A에 대한 지시자는 오프이다(슬롯 A에 저장 디바이스가 채워질 필요가 없음을 지시함),

도 10은 본 발명의 예시적인 실시예에 따라서, 리던던트 데이터 저장을 유지하기 위해 충분한 공간을 갖고 있지 않고 더 많은 공간이 추가되어야 하는 예시적이 어레이를 도시한다. 슬롯들 B, C, 및 D는 저장 디바이스들로 채워져 있다. 슬롯 C 및 D 내의 저장 디바이스들은 차 있다. 슬롯들 B, C, 및 D에 대한 지시자들은 녹색이고(이들 저장 디바이스들이 바르게 동작하고 있음을 지시함), 슬롯 A에 대한 지시자는 적색이다(어레이가 리던던트 데이터 저장을 유지하기 위해 충분한 공간을 갖고 있지 않고 슬롯 A에 저장 디바이스가 채워져야 함을 지시함).

*도 11은 본 발명의 예시적인 실시예에 따라서, 고장의 경우에 리던던트 데이터를 유지할 수 없게 될 예시적인 어레이를 도시한다. 슬롯들 A, B, C, 및 D는 저장 디바이스들로 채워져 있다. 슬롯들 C 및 D 내의 저장 디바이스들은 차 있다. 슬롯들 A, B, 및 C에 대한 지시자들은 녹색이고(이들 저장 디바이스들이 바르게 동작하고 있음을 지시함), 슬롯 D에 대한 지시자는 황색이다(슬롯 D 내의 저장 디바이스가 보다 큰 저장 웅량을 갖는 저장 디바이스로 교체되어야 함을 지시함).

도 12는 본 발명의 예시적인 실시예에 따라서, 저장 디바이스가 고장난 예시적인 어레이를 도시한다. 슬롯들 B, C, 및 D는 저장 디바이스들로 채워져 있다. 슬롯 C 내의 저장 디바이스는 고장났다. 슬롯들 B 및 D에 대한 지시자들은 녹색이고(이들 저장 디바이스들이 바르게 동작하고 있음을 지시함), 슬롯 C에 대한 지시자는 적색이고(슬롯 C 내의 저장 디바이스가 교체되어야 함을 지시함), 슬롯 A에 대한 지시자는 오프이다(슬롯 A에 저장 디바이스가 채워질 필요가 없음을 지시함).

다음은 본 발명의 예시적 실시예에 대한 소프트웨어 설계에 대한 설명이다. 소프트웨어 설계는 6개의 소프트웨어 계층들에 기초하고, 이 소프트웨어 계층들은 논리적 아키텍처가 물리적으로 디스크에 액세스하는 것으로부터 호스트 컴퓨팅 시스템과 통신하는 것까지 걸쳐 있다.

이 예시적 실시예에서, 파일 시스템은 윈도즈, 리눅스, 또는 애플 서버와 같은 호스트 서버 상에 존재하고, USB 또는 iSCSI 디바이스로서 저장 어레이에 액세스한다. 호스트 인터페이스를 통하여 착신되는 물리적 디스크 요구들은 호스트 요구 관리자(HRM : Host Request Manager)에 의해 처리된다. 호스트 1/0 인터페이스는 호스트 USB 또는 iSCSI 인터페이스를 호스트에 제공(presentation)하는 것을 코디네이트(coordinate)하고, HRM과 인터페이스한다. HRM은 호스트 1/0 인터페이스로부터의 데이터 판독/기입 요구들을 코디네이트하고, 판독 및 기입 요구들을 디스패치(dispatch)하고, 이들 요구들이 완료될 때 호스트로 다시 이들 요구들을 회수(retiring)하는 것을 코디네이트한다.

저장 어레이의 무엇보다 중요한 목적은 일단 데이터가 시스템에 의해 수취되면, 시스템이 현재 저장하는 최대량의 리던던시를 이용하여, 데이터가 신뢰할 만한 방식으로 저장되도록 하는 것이다. 어레이가 물리적 구성을 변경할 때, 데이터는 리던던시를 유지하도록(가능하다면 최대화하도록) 재편성된다. 또한, 이용되는 저장의 양을 저감시키기 위해 단순한 해시 기반 압축이 이용된다.

가장 기본적인 계층은 상이한 디스크들에 데이터를 저장하는 디스크 드라이버들로 이루어진다. 디스크들은 USB 인터페이스를 통하여 터널링되는 ATA와 같은 각종 인터페이스들을 통하여 부착된다.

디스크들 상의 섹터들은, 각각이 상이한 논리적 역할을 갖는, 영역들, 존들, 및 클러스터들로 편성된다.

영역들은 디스크 상의 연속된 물리적 블록들의 세트를 나타낸다. 4 드라이브 시스템에서, 각 영역은 사이즈가 1/12 GB이고, 리던던시의 최소 단위를 나타낸다. 만일 영역 내의 섹터가 물리적으로 손상된 것으로 확인되면, 전체 영역이 버려질 것이 다.

존들은 리던던시의 단위들을 나타낸다. 존은 적당한 양의 리던던시를 제공하기 위해 어쩌면 상이한 디스크들 상의 다수의 영역들로 이루어질 것이다. 존들은 1GB의 데이터 용량을 제공하겠지만, 리던던시를 제공하기 위하여 더 많은 영역들을 필요로 할 수 있다. 리던던시가 없는 1GB는 한 세트의 12 영역들(1GB)을 필요로 하고; 1GB 미러링된 존(mirrored zone)은 2 세트의 1GB 영역들(24 영역들)을 필요로 할 것이고; 1GB 3-디스크 스트라이프 존(stripped zone)은 3 세트의 0.5GB 영역들(18 영역들)을 필요로 할 것이다. 상이한 존들은 상이한 리던던시 특성들을 가질 것이다.

클러스터들은 압축의 기본 단위를 나타내고, 존들 내의 단위 사이즈이다 그것들은 현재 사이즈가 4KB: 8 × 512 바이트 섹터들이다. 디스크 상의 다수의 클러스터들이 아마도 동일 데이터를 포함할 것이다. 클러스터 액세스 테이블(CAT : cluster access table)은 해싱 함수를 통하여 클러스터들의 사용을 추적하기 위해 이용된다. CAT는 논리적 호스트 어드레스와 존 내의 적당한 클러스터의 위치 사이를 번역(translate)한다.

디스크에 기입할 때, 해시 함수는 데이터가 이미 디스크 상에 존재하는지를 확인하기 위해 이용된다. 만일 그렇다면, CAT 테이블 내의 적당한 엔트리는 기존의 클러스터를 가리키도록 설정된다.

CAT는 그 자신의 존 내에 존재한다. 만일 그것이 존의 사이즈를 초과한다면, 추가 존이 이용될 것이고, 논리적 어드레스를 CAT의 해당 부분에 대한 존에 맵핑하기 위한 테이블이 이용될 것이다. 대안적으로, 존들은 CAT 테이블을 포함하도록 미리 할당된다.

호스트 기입 레이턴시를 줄이고 데이터 신뢰도를 보장하기 위하여, 저널 관리자(journal manager)가 모든 기입 요구들을 기록할 것이다(디스크에 또는 NVRAM에). 만일 시스템이 재부팅되면, 저널 엔트리들은 재부팅 시에 커밋(commit)될 것이다.

디스크들이 오고 갈 수 있고, 영역들이 훼손(Corrupton)을 갖고 있는 것으로 확인되면 그 영역들이 회수(retire)될 수 있다. 이들 상황 중 어느 쪽이든, 레이아웃 관리자가 존의 리던던시 타입을 변경하거나, 또는 (영역이 훼손되면) 존의 영역 구성을 변경하기 위하여 존 내의 영역들을 재편성할 수 있을 것이다.

저장 어레이는 물리적 디스크 공간의 레벨들을 변경함으로써 지원되는 가상 디스크 어레이를 제공하므로, 그리고 그것은 블록 레벨 인터페이스를 제공(present)하기 때문에, 클러스터들이 더 이상 파일 시스템에 의해 사용되지 않는 때가 명백하지 않다. 그 결과, 사용되는 클러스터 공간은 계속해서 확장할 것이다. (호스트 상에 또는 펌웨어 내에 위치하는) 가비지 컬렉터(garbage collector)가 파일 시스템을 분석하여 어느 클러스터들이 자유롭게 되었는지를 결정하고, 그것들을 해시 테이블로부터 제거할 것이다.

다음 표는 발명의 예시적 실시예에 따른 6개의 소프트웨어 계층들을 보여준다.

계층 5: 가비지 컬렉터, 호스트 인터페이스(USB/iSCSI)

계층 4: 호스트 요구 관리자

계층 3: CAT, HASH, 저널 관리자

계층 2: 존 관리자. 존이라 불리는 섹터들의 청크들을 할당하고/자유롭게 한다. 에러 및 에러 복구를 처리하기 위해 SDM, DDM, SD3 등에 관하여 알고 있다. 레이아웃 관리자

계층 1: 물리적 클러스터들/섹터들을 판독/기입한다. 디스크마다 영역들을 할당한다.

계층 0: 디스크 액세스 드라이버들

도 13은 상이한 소프트웨어 계층들 및 그들이 서로 어떻게 관련되는지를 나타내는 모듈 계층구조를 도시한다. 소프트웨어 계층화(layering)는 명백한 API들 및 경계 식별(delineation)을 제공하기 위하여 바람직하게는 고정된다(rigid).

가비지 컬렉터는 호스트 파일 시스템에 의해 더 이상 사용되지 않는 클러스터들을 자유롭게 한다. 예를 들면, 파일이 삭제될 때, 그 파일을 포함하기 위해 사용되었던 클러스터들은 바람직하게는 자유롭게 된다.

저널 관리자는 정전 또는 다른 에러 상태의 경우에 미처리(pending) 기입들이 손실되지 않도록 기입들의 저널링(journaling)의 일종을 제공한다.

레이아웃 관리자는 그들의 영역들과 비교하여(vis-a-vis) 존들의 실행시간 재배치(run-time re-layout)를 제공한다. 이것은 디스크 삽입/제거 또는 고장의 결과로 일어날 수 있다.

클러스터 관리자는 데이터 존들의 세트 내에 클러스터들을 할당한다. 디스크 이용 디먼(Disk Utilization Daemon)은 주기적으로 자유 디스크 공간을 체크한다.

록 테이블(Lock Table)은 기입 후 판독 충돌(read after write collision) 문제들을 처리한다.

호스트 요구 관리자는 호스트 및 가비지 컬렉터로부터의 판독/기입 요구들을 처리한다. 기입들은 저널 관리자에 전달되는 반면, 판독들은 클러스터 액세스 테이블(CAT) 관리 계층을 통하여 처리된다.

위에서 논의된 바와 같이, 전형적인 파일 시스템들에서, 데이터의 얼마간의 양은 일반적으로 사실상 반복성일 것이다. 디스크 공간 이용을 줄이기 위하여, 이 데이터의 다수의 사본들이 디스크들에 기입되지 않는다. 대신, 하나의 인스턴스가 기입되고, 동일 데이터의 모든 다른 인스턴스들은 이 하나의 인스턴스에 참조된다.

이 예시적 실시예에서, 시스템은 언제나 데이터의 클러스터(예컨대, 8개의 물리적 섹터들)에 작용하고, 이것은 해싱되는 단위이다. SHA1 알고리듬은 160 비트 해시를 생성하기 위해 이용된다. 이것은 양호한 유일성(good uniqueness), 및 다수의 프로세서들에서 온칩으로 지원되는 것을 포함하여 다수의 이점들을 갖는다. 모든 160 비트는 해시 레코드에 저장되겠지만, 최하위 16 비트만이 해시 테이블에의 인덱스로서 이용될 것이다. 최저 16 비트와 일치하는 다른 인스턴스들은 링크된 리스트(linked-list)를 통하여 연쇄(chain)될 것이다.

이 예시적 실시예에서는, 한 번에 하나의 판독/기입 동작만 발생할 수 있다. 성능을 위하여, 해시 분석은 클러스터를 디스크에 기입할 때는 발생하도록 허용되지 않는다. 대신, 해시 분석은 해시 관리자에 의해 배경 활동(background activity)으로서 발생할 것이다.

*기입 요구들은 저널의 큐(queue)로부터 판독되어, 완료까지 처리된다. 데이터 일관성을 보장하기 위하여, 기입 동작이 이미 클러스터 상에서 활성이면 기입들이 연기되어야 한다. 다른 클러스터들 상의 동작들은 방해받지 않고 처리될 수 있다.

전체 클러스터가 기입되지 않는 한, 기입되는 데이터는 클러스터에 저장된 기존의 데이터와 병합될 필요가 있을 것이다. 논리적 섹터 어드레스(LSA : logical sector address)에 기초하여, 클러스터에 대한 CAT 엔트리가 위치 확인(locate)된다. 해시 키, 존 및 클러스터 오프셋 정보가 이 레코드로부터 획득되고, 그 후 그것은 일치를 찾기 위해 해시 테이블을 검색하는 데 이용될 수 있다. 이것이 클러스터이다.

정확한 해시 엔트리의 조회 속도를 향상시키기 위해 한 번은 SHA1 다이제스트를 통하여, 그 후 존/클러스터 오프셋에 의해, 해시 테이블을 이중으로 해싱하는 것이 필요할 수도 있다. 만일 해시 레코드가 이미 이용되었다면, 참조 카운트가 감소된다. 만일 참조 카운트가 이제 제로이면, 해시 엔트리에 의해 참조되는 스냅숏(snapshot)이 없고, 해시 엔트리 및 클러스터는 다시 그들 각각의 자유 리스트들로 자유롭게 될 수 있다.

최초 클러스터 데이터는 이제 클러스터의 업데이트 섹션과 병합되고, 데이터는 다시 해싱된다. 새로운 클러스터가 자유 리스트로부터 제거되고, 병합된 데이터는 그 클러스터에 기입되고, 새로운 엔트리가 해시 테이블에 추가되고, CAT 테이블 내의 엔트리는 새로운 클러스터를 가리키도록 업데이트된다.

해시 테이블을 업데이트한 결과, 엔트리는 또한 배경 작업으로서 처리되도록 내부 큐(internal queue)에 추가된다. 이 작업은 새로이 추가된 클러스터 및 해시 엔트리를 해시 테이블 행 어드레스(table row address)와 일치하는 다른 해시 엔트리들과 비교할 것이고, 그것들이 복제(duplicate)들이라면 레코드들을 결합하여, 적절한 해시 엔트리들 및 CAT 테이블 엔트리들을 자유롭게 할 것이다. 만일 이 처리 중에 고장(예컨대, 전력 손실)이 발생하면, 각종 테이블들이 삭제되어, 결국 데이터가 손실될 수 있다. 테이블들은 최종 커밋이 원자적(atomic)이도록 또는 저널 엔트리가 완전히 완료하지 않았다면 그 저널 엔트리가 다시 실행될 수 있도록 관리된다.

다음은 기입 논리에 대한 의사 코드이다:

판독 요구들은 또한 한 번에 한 클러스터씩("섹터"와는 대조적으로) 처리된다. 판독 요구들은 위에서 요약 설명된 해시 관련 처리를 거치지 않는다. 대신, 호스트 논리적 섹터 어드레스는 CAT를 참조하고 존 번호 및 존에의 클러스터 오프셋을 획득하기 위해 이용된다. 판독 요구들은 CAT 캐시 내의 CAT 테이블 엔트리를 조회해야 하고, 진행중-기입(write-in-progress) 비트가 세트일 때 연기되어야 한다. 다른 판독/기입들은 방해받지 않고 처리될 수 있다. 데이터 무결성 체킹을 향상시키기 위하여, 클러스터가 판독될 때, 그것은 해싱될 것이고, 그 해시는 해시 레코드에 저장된 SHA1 해시 값과 비교될 것이다. 이것은 해시, 존 및 클러스터 오프셋을 해시 테이블 내로의 검색 키로서 이용하는 것을 필요로 할 것이다.

클러스터들은 되도록 적은 수의 존들을 이용하도록 할당된다. 이것은 존들이 디스크 드라이브 이용에 직접 대응하기 때문이다. 모든 존마다, 하드 드라이브 어레이 상에 2 이상의 영역들이 있다. 존의 수를 최소화함으로써, 물리적 영역의 수가 최소화되고 따라서 하드 드라이브 어레이 상의 공간의 소비가 저감된다.

클러스터 관리자는 데이터 존들의 세트로부터 클러스터를 할당한다. 링크된 리스트는 존 내의 자유 클러스터들을 추적(keep track of)하기 위해 이용된다. 그러나, 자유 클러스터 정보는 디스크 상에 비트맵(존마다 32KB)으로서 저장된다. 링크된 리스트는 이 비트맵으로부터 동적으로 구성된다. 처음에, 어느 일정한 수의 자유 클러스터들의 링크된 리스트가 메모리에 생성된다. 클러스터들이 할당되면, 리스트는 수축(shrink)한다. 소정의 낮은 워터 마크(low-water mark)에서, 자유 클러스터들을 나타내는 새로운 링크된 리스트 노드들이 디스크 상의 비트맵으로부터 추출된다. 이런 식으로, 할당을 위한 자유 클러스터를 찾기 위하여 비트맵이 파싱될 필요가 없다.

이 예시적 실시예에서, 해시 테이블은 (해시의 하위 16 비트에 의해 인덱싱된) 64K 레코드들의 테이블이고 다음의 포맷을 갖는다:

오프셋	비트 사이즈	이름	값/유효 범위	설명
0	160	sha1Hash		완전한 SHA1 해시 다이제스트
	16	refCount		이 해시의 인스턴스들의 수; 16 비트를 넘으면 무엇을 하는가?
	18	Cluster offset		존 내의 클러스터 오프셋
	14	Zone #		이 클러스터를 포함하는 Zone #(존 번호)
	8	snapshot		이 클러스터 엔트리가 해당 스냅숏에 의해 이용되는 것을 지시하기 위해 스냇숏 인스턴스당 하나의 비트. 이 모델은 8개 스냅숏을 지원한다(어쩌면 7개만)

전부 제로인 클러스터(cluster of all zeros)는 꽤 흔할 수 있어서, 전부 제로인 경우는 특별한 경우로서, 예를 들면, 그것은 결코 삭제될 수 없도록(따라서 카운트를 랩핑하는 것(wrapping the count)이 문제가 되지 않도록), 취급될 수 있다.

자유 해시 레코드의 링크된 리스트는 다수의 해시들이 동일한 최하위 해시(least significant hash)를 갖는 경우, 또는 2개의 해시 엔트리들이 상이한 데이터 클러스터들을 가리킬 경우에 이용된다. 어느 경우든, 자유 해시 레코드가 리스트로부터 제거되어, pNextHash 포인터를 통하여 링크될 것이다.

해시 관리자는 해시 테이블에 추가된 엔트리들을 정리(tidy up)하고, 디스크 상의 동일한 클러스터들을 결합할 것이다. 새로운 해시 레코드들이 해시 테이블에 추가될 때, 메시지가 해시 관리자에 포스트(post)될 것이다. 이것은 해시 관리자에 의해 자동으로 행해질 것이다. 배경 활동으로서, 해시 관리자는 그것의 큐 상의 엔트리들을 처리할 것이다. 그것은 전체 해시 값을 비교하여 그것이 임의의 기존의 해시 레코드들과 일치하는지를 확인할 것이다. 만일 그렇다면, 그것은 또한 완전한 클러스터 데이터를 비교할 것이다. 만일 클러스터들이 일치하면, 새로운 해시 레코드는 다시 자유 큐로 폐기될 수 있고, 해시 레코드 카운트는 증가될 것이고, 복제 클러스터는 클러스터 자유 큐로 반환될 것이다. 해시 관리자는 레코드들을 결합할 때 스냅숏 비트를 전방으로 주의해서 전파해야 한다.

클러스터 액세스 테이블(CAT)은 간접 포인터들을 포함한다. 이 포인터들은 존 내의 데이터 클러스터들을 가리킨다(0이 제1 데이터 클러스터임). 하나의 CAT 엔트리는 단일 데이터 클러스터(시험적으로 4KB 사이즈)를 참조한다. CAT들은 많은 반복성 데이터가 있을 경우 디스크 이용 요건들을 줄이기 위하여 (해싱과 관련하여) 사용된다. 단일 CAT는 항상 연속된 저장 블록을 나타낸다. CAT들은 비-데이터(non-data) 존들 내에 포함된다. 각 CAT 엔트리는 48 비트이다. 다음 표는 (각 데이터 존이 1GB의 데이터를 포함한다고 가정하여)각 엔트리가 어떻게 레이아웃되는지를 보여준다:

비트 0-17	비트 18-31	비트 32-47	비트 48-63[..]
존 내의 데이터 클러스터의 오프셋	데이터를 포함하는 존#	해시 키	예비. 후보들은 가비지 컬렉터 기입 비트; 스냅숏 비트; 스냅숏 테이블 해시 키를 포함한다

CAT는 64 비트에 합치하는 것이 바람직하지만, 이것은 필수적인 것은 아니다. 2TB 어레이에 대한 CAT 테이블은 현재 사이즈가 4GB까지이다. 각 CAT 엔트리는 데이터 및 존의 번호를 포함하는 존을 가리킨다.

도 14는 존 내의 데이터 클러스터들에 액세스하기 위해 CAT가 어떻게 이용되는지를 도시한다. 2개의 논리적 클러스터들이 동일 데이터를 포함하고, 따라서 그들의 CAT 엔트리들은 동일한 물리적 클러스터에 지시된다.

해시 키 엔트리는 전체 클러스터의 160 비트 SHA1 해시 값의 16 비트 추출을 포함한다. 이 엔트리는 기입 동작 동안에 해시 테이블을 업데이트하기 위해 이용된다.

16TB의 데이터를 참조하기 위해 CAT 내의 각 엔트리에는 충분한 비트들이 있다. 그러나, 각 데이터 클러스터마다 모두 다른 클러스터와 (콘텐츠 면에서) 다르다면, 2TB의 데이터를 참조하기 위해 3 존을 겨우 넘는 만큼의(just over 3 Zones' worth of) CAT 엔트리들이 요구된다(각 존은 사이즈가 1GB이고, 따라서 1GB/사이즈의 CAT 엔트리 엔트리들(1GB/size of CAT entry entries)을 저장할 수 있다. 6 바이트 CAT 엔트리들을 가정하면, 그것은 178956970 CAT 엔트리/존이다. 즉, 테이블은 각 클러스터가 4K이면 약 682 GB/존을 참조한다).

호스트 논리적 섹터 번역 테이블은 호스트 논리적 섹터 어드레스를 존 번호로 번역하기 위해 이용된다. 호스트 논리적 섹터 어드레스에 대응하는 CAT의 부분은 이 존 내에 존재할 것이다. 각 CAT 엔트리는 4096 바이트의 클러스터 사이즈를 대표한다는 것에 유의하자. 이것은 8개의 512 바이트 섹터들이다. 다음은 호스트 논리적 섹터 번역 테이블의 표현을 보여준다.

시작 호스트 논리적 섹터 어드레스	끝 호스트 논리적 섹터 어드레스	CAT의 존#
0(클러스터#0)	1431655759(클러스터#178956969)
1431655760(클러스터#178956970)	...

존들은 전체 CAT를 보유하도록 미리 할당될 수 있다. 대안적으로, 존들은 CAT에의 더 많은 엔트리들이 요구될 때 CAT에 대하여 할당될 수 있다. CAT는 2TB 가상 디스크를 호스트 섹터 어드레스 공간에 맵핑하므로, 호스트에 의한 하드 디스크 분할 또는 포맷팅 동안에 CAT의 대부분이 참조될 가능성이 있다. 이 때문에, 존들은 미리 할당될 수 있다.

CAT는 큰 1GB/존 테이블이다. 사용 중인 클러스터들의 작업 세트는 이 큰 테이블로부터의 스파스 세트일 것이다. 성능을 위하여, 활성 엔트리들은 항상 그것들을 디스크로부터 판독하기보다는 (아마도 일시적으로) 프로세서 메모리에 캐싱될 수 있다. 캐시를 채우기 위한 적어도 2개의 옵션 - CAT로부터의 개개의 엔트리들, 또는 CAT로부터의 전체 클러스터들 - 이 있다.

진행중-기입(write-in-progress)이 CAT 캐시 테이블과 결합되기 때문에, 모든 미처리(outstanding) 기입들이 캐시 내에 남아 있도록 할 필요가 있다. 따라서, 캐시는 적어도 미처리 기입 요구들의 최대 수만큼 클 필요가 있다.

캐시 내의 엔트리들은 클러스터 사이즈(즉, 4K)일 것이다. 클러스터 상에서 동작하는 진행중-기입이 있는지를 알 필요가 있다. 이 지시(indication)는 클러스터에 대한 캐시 엔트리 내에 플래그로서 저장될 수 있다. 다음 표는 CAT 캐시 엔트리의 포맷을 보여준다:

비트 0-17	비트 18-31	비트 32-47	비트 48-63
존 내의 데이터 클러스터의 오프셋	데이터를 포함하는 존#	해시 키	비트 48: 진행중-기입 비트 49: 더티(Dirty)

캐시 엔트리 내의 진행중-기입 플래그는 2개의 암시들을 갖는다. 첫째로, 그것은 기입이 진행중이고, 이 클러스터 상의 어떠한 판독들(또는 추가 기입들)도 그 기입이 완료할 때까지 연기되어야 한다는 것을 지시한다. 둘째로, 캐시 내의 이 엔트리는 그 비트가 세트인 동안에 플러시(flush)되어서는 안 된다. 이것은 부분적으로는 비트의 상태를 보호하기 위한 것이고, 또한 이 클러스터가 현재 사용 중이라는 사실을 반영하기 위한 것이다. 또한, 이것은 캐시의 사이즈가 적어도 미처리 기입 동작들의 수만큼 커야 한다는 것을 의미한다.

클러스터에 대한 캐시 엔트리에 진행중-기입 지시자를 저장하는 것의 하나의 이점은 그것은 동작이 현재 행해지고 있다는 사실을 반영하고, 또 다른 테이블을 갖는 것을 면하게 해주고, 또한 그것은 이 비트도 체크하기 위한 추가적인 해시 기반 조회, 또는 테이블 보행(table walk)을 면하게 해준다는 점이다. 캐시는 연기 기입(write-delayed) 캐시일 수 있다. 기입 동작이 완료되면 캐시 엔트리를 다시 디스크에 기입하기만 하면 된다. 비록 그것을 더 일찍 다시 기입되게 하는 것이 유익할 수는 있지만. 해싱될 수 있는 미처리 기입 엔트리들의 수를 증가시키기 위해 해시 함수 또는 다른 메커니즘이 이용될 수 있다.

대안적인 접근법은 CAT의 전체 클러스터들(즉, 엔트리들 중 4K 엔트리)을 캐싱하는 것이다. 이것은 일반적으로 양호한 공간적 액세스 위치(spatial locality of access)가 있다면 성능을 도울 것이다. CAT 엔트리들은 48 비트 폭이고, 따라서 캐시 내에 전체 수의 엔트리들이 있지 않을 것이기 때문에 주의할 필요가 있다. 다음 표는 클러스터된 CAT 캐시 엔트리의 예를 보여준다.

2 워드	2 워드		2 워드	2 워드
CAT 엔트리 1 (마지막 2 워드의 부분적 엔트리)	CAT 엔트리 2
CAT 엔트리 3		CAT 엔트리 4
CAT 엔트리 4		CAT 엔트리 5
CAT 엔트리 5		CAT 엔트리 6
....
CAT 엔트리 682		CAT 엔트리 683 (처음 2 워드의 부분적 엔트리)
진행중-기입 비트 어레이[682 비트]: 비트 0-255
진행중-기입 비트 어레이 비트 256-511
진행중-기입 비트 어레이 512-682 + 스파스 비트들		더티 카운트	예비

테이블 사이즈는 4096 + 96(4192 바이트)이 될 것이다. 250 엔트리의 캐시 사이즈를 갖는 것이 필요하다고 가정하면, 캐시는 대략 1MB를 차지할 것이다.

논리적 CAT 엔트리 어드레스의 적절한 마스킹에 의해 처음과 마지막 엔트리가 불완전한지 여부를 추정하는 것이 가능하다. 캐싱 조회 루틴은 엔트리를 로딩하기 전에 이것을 해야 하고 요구되는 CAT 클러스터를 로딩해야 한다.

호스트가 섹터(또는 클러스터) 판독 요구를 송신할 때, 그것은 논리적 섹터 어드레스를 통하여 송신한다. 논리적 섹터 어드레스는 호스트에 의해 요구되는 실제 데이터를 포함하는 존 내의 클러스터의 오프셋을 얻기 위하여 CAT에 대한 오프셋으로서 이용된다. 결과는 존 번호 및 그 존에 대한 오프셋이다. 그 정보는 계층 2 소프트웨어에 전달되고, 그 후 계층 2 소프트웨어는 드라이브(들)로부터 원시(raw) 클러스터(들)를 추출한다.

호스트에 의해 기입된 적이 없는 클러스터들을 다루기 위하여, 모든 CAT 엔트리들은 전부 제로를 포함하는 "디폴트" 클러스터를 가리키도록 초기화된다.

저널 관리자는 바이레벨(bi-level) 저널링 시스템이다. 이 시스템의 목적은 호스트로부터 기입 요구들이 수취될 수 있도록 하고 데이터가 수취된 것을 신속히 호스트에게 지시함과 동시에 그것의 무결성을 보장하는 것이다. 또한, 이 시스템은 임의의 디스크 기입 동안에 시스템이 리셋되는 경우에 임의의 블록 레벨 데이터 또는 시스템 메타데이터(예컨대, CAT 및 해시 테이블 엔트리들)의 훼손 또는 분실이 일어나지 않도록 할 필요가 있다.

J1 저널 관리자는 호스트들로부터의 모든 기입 요구들을 되도록 신속히 디스크에 캐싱한다. 일단 기입이 성공적으로 완료하면(즉, 데이터가 어레이에 의해 수취되면), 호스트는 동작이 완료하였음을 지시하도록 신호를 받을 수 있다. 저널 엔트리는 고장으로부터 복구할 때 기입 요구들의 복구를 허용한다. 저널 레코드들은 디스크에 기입될 데이터, 및 기입 트랜잭션과 관련된 메타데이터로 이루어진다.

디스크 판독/기입들을 줄이기 위하여, 기입과 관련된 데이터는 자유 클러스터들에 기입될 것이다. 이것은 데이터를 자동으로 미러링할 것이다. 자유 클러스터들이 자유 클러스터 리스트로부터 제거될 것이다. 일단 데이터가 기입되면, 자유 클러스터 리스트는 다시 디스크에 기입되어야 한다.

저널 레코드는 미러링되지 않은(non-mirrored) 존 상의 저널 큐에 기입될 것이다. 각 레코드는 사이즈가 섹터일 것이고, 저널 기입 동안의 고장이 이전의 저널 엔트리를 훼손시킬 위험을 줄이기 위하여 섹터 경계에 정렬된다. 저널 엔트리들은 큐의 끝이 쉽게 식별될 수 있도록 레코드의 끝에 유일한, 증가하는 시퀀스 카운트(unique, incrementing sequence count)를 포함할 것이다.

저널 기입 동작들은 호스트 큐 처리 스레드와 동시에 일어날 것이다. 저널 기입들은, 디스크에 기입될 때, 언제든지 하나의 스레드만 저널을 기입할 수 있도록, 순서화되어야 한다. J1 테이블 내의 저널 엔트리의 어드레스는 J1 저널 엔트리가 J2 저널 내의 엔트리들과 상관될 수 있도록 유일 식별자로서 이용될 수 있다. 일단 저널 엔트리가 기입되면, 트랜잭션 완료 통지가 호스트 완료 큐에 포스트될 것이다. 이제 기입 동작이 실행될 수 있다. 저널 기입이 완료하기 전에 클러스터에 대한 임의의 후속 판독들이 연기되도록 하는 것이 중요하다.

다음 표는 J2 저널 레코드의 포맷을 보여준다:

비트 사이즈	이름	상세
32	LBA	논리적 블록 어드레스
14	Zone	관련 클러스터의 존#
18	Offset	관련 클러스터의 클러스터 오프셋
16	Size	데이터의 사이즈
16	SequenceNumber	큐의 끝을 쉽게 찾을 수 있도록 증가하는 시퀀스 번호

각 저널 레코드는 섹터 경계에 정렬될 것이다. 저널 레코드는 존/오프셋/사이즈 터플들(tuples)을 포함할 수 있다.

도 15는 본 발명의 예시적인 실시예에 따른 저널 테이블 업데이트를 도시한다. 구체적으로, 호스트 기입 요구가 수신되면, 저널 테이블이 업데이트되고, 하나 이상의 클러스터들이 할당되고, 데이터가 클러스터(들)에 기입된다.

호스트 저널 요구들이 처리된다. 이들은 클러스터들이 기입되게 하고, 또한 디스크에 다시 섀도우(shadow)되어야 하는 메타데이터 구조(예를 들면, CAT 테이블)에 대한 업데이트들을 일으킨다. 비록 시스템 리셋이 발생하더라도 이들 메타데이터 구조들이 디스크에 다시 정확하게 기입되도록 하는 것이 중요하다. 저레벨 I/O 기입(J2) 저널이 이를 위해 이용될 것이다.

호스트 인터페이스 저널 엔트리를 처리하기 위하여, 메타데이터 구조들의 적절한 조작(manipulation)이 결정되어야 한다. 변경들은 메모리에서 일어나야 하고 각종 디스크 블록들에 대한 변경들의 레코드가 생성되어야 한다. 이 레코드는 이루어져야 하는 디스크 상의 실제 변경들을 포함한다. 업데이트되는 각 데이터 구조는 J2 저널 관리자에 등록된다. 이 레코드는 디스크 기반 저널에 기록되고, 식별자로 스탬프되어야 한다. 레코드가 J1 저널 엔트리와 관계가 있는 경우, 식별자들은 링크되어야 한다. 일단 레코드가 저장되면, 디스크에 대한 변경들이 이루어질 수 있다(또는 배경 작업으로서 행해질 수 있다).

J2 저널은 계층 3에 논리적으로 존재한다. 그것은 존 관리자를 통한 기입들을 수반할 메타데이터 업데이트들을 저널링하는 데 이용된다. 저널 엔트리의 재생(playback)이 발생할 경우, 그것은 존 관리자 메소드들을 이용할 것이다. 저널 자체는 특화된 영역에 저장될 수 있다. 저널 엔트리들의 짧은 수명이 주어지면, 그것들은 미러링될 것이다. 모든 메타데이터 업데이트들이 J2 저널을 거칠 필요는 없다. 특히 구조들에 대한 업데이트들이 원자적일 경우 그러하다. 영역 관리자 구조는 J2 저널을 이용하지 않을 수 있다. 예를 들면, 무결성 체킹 배경 스레드(integrity checking background thread)에 의해, 영역 관리자 비트맵에서 불일치들을 검출하는 것이 가능할 것이다.

J2 저널에 대한 단순한 접근법은 단일 레코드를 포함하는 것이다. 레코드가 디스크에 커밋(commit)되자마자, 그것은 재생되어, 디스크 상의 구조들을 업데이트한다. 다수의 J2 레코드들을 갖고 또한 디스크들 상의 배경 작업 커밋팅 업데이팅 레코드들(background task committing updating records)을 갖는 것이 가능하다. 이 경우, 저널과 각종 데이터 구조들과 관련된 임의의 캐싱 알고리듬들 사이의 상호작용에 세심한 주의를 기울일 필요가 있다.

처음 접근법은 저널 엔트리가 디스크에 커밋되자마자 그것을 실행할 것이다. 원칙적으로 J2의 다수의 동시 사용자들이 있을 수 있지만, J2 저널은 한 번에 한 사용자에게 로크(lock)된다. 이 경우에도, 저널 엔트리들은 제시(submit)되자마자 커밋되어야 한다.

임의의 상위 레벨의 저널 활동이 발생하기 전에 메타데이터 구조들이 수리(repair)되도록 하는 것이 중요하다. 시스템 재부팅 시에, J2 저널은 분석되고, 임의의 레코드들이 재생될 것이다. 만일 저널 엔트리가 J1 저널 엔트리와 상관된다면, Jl 엔트리는 완료로 표시될 것이고, 제거될 수 있다. 일단 모든 J2 저널 엔트리들이 완료되면, 메타데이터는 신뢰할 만한 상태로 되고 남아 있는 J1 저널 엔트리들이 처리될 수 있다.

J2 저널 레코드는 다음 정보를 포함한다:

동작의 수

각 동작은 다음을 포함한다:

o Jl 레코드 지시자

o 기입할 존/데이터 오프셋

o 기입할 데이터

o 데이터의 사이즈

o 데이터 클러스터에 대한 오프셋

저널 레코드 식별자

엔드 마커(End Marker)

이 방식은 Jl 저널 방식과 유사하게 동작할 수 있다(예를 들면, 시퀀스 번호로 J2 저널 엔트리의 끝을 식별하고 J2 저널 엔트리들을 섹터 경계들에 배치하여).

만일 J1 데이터 포인터 지시자가 세트되면, 이 특정 동작은 Jl 저널 레코드를 가리킬 것이다. 호스트 공급 기입 데이터는 우리의 저널 엔트리에 복사되지 않아도 될 것이다. 동작 어레이는 저널 레코드 내의 동작들의 최대 수가 잘 이해되도록 기대되는 만큼 일정한 사이즈로서 정의될 수 있어야 한다.

(예컨대, 전력 손실로 인한) 저레벨 기입 동작 동안의 섹터의 훼손으로부터의 복구를 허용하기 위해, J2 저널은 기입된 전체 섹터를 저장할 수 있고, 따라서 필요하다면 이 정보로부터 섹터가 재기입될 수 있다. 대안적으로 또는 부가적으로, 각 수정된 섹터에 대하여 계산된 CRC는 J2 레코드에 저장되고 기입 동작의 재생이 요구되는지를 결정하기 위해 디스크 상의 섹터로부터 계산된 CRC와 비교될 수 있다(예컨대, 존 관리자에 의해).

상이한 저널들은 상이한 위치들에 저장될 수 있고, 따라서 저장을 지원하기 위해 기입 저널 레코드들에 제공된 인터페이스 계층이 있을 것이다. 위치는 불휘발성이어야 한다. 2개의 후보들은 하드 디스크 및 NVRAM이다. 만일 J1 저널이 하드 디스크에 저장된다면, 그것은 J1 저널 미러링되지 않은 존에 저장될 것이다. J1 저널은 NVRAM에 저장하기 위한 후보이다. J2 저널은 디스크에 저장되어야 하지만, 특화된 영역(즉, 그것은 짧은 수명을 갖기 때문에 리던던트하지 않은)에 저장될 수 있다. J2 저널을 디스크에 저장하는 것의 이점은, 내부 데이터 구조 업데이트 동안에 시스템 리셋이 있다면, (비록 그 장치가 장시간 동안 전력을 공급받지 못한 상태로 되더라도) 데이터 구조들은 일관된 상태로 복귀될 수 있다는 점이다.

존 관리자(ZM)는 상위 레벨 소프트웨어에 의해 요구되는 존들을 할당한다. ZM에의 요구들은 다음을 포함한다:

a. 존 할당

b. 존 할당 해제/자유롭게 함

c. L1(?)으로의 데이터 판독/기입 통과 제어

d. 존 내의 클러스터 판독/기입(클러스터의 오프셋 및 존 번호가 주어지면)

ZM은 (드라이브들의 수 및 그들의 관련 사이즈의 함수로서) 리던던시 메커니즘들을 관리하고 미러링, 스트라이핑, 및 데이터 판독/기입에 대한 다른 리던던시 방식 들을 처리한다.

ZM이 존을 할당할 필요가 있을 경우, 그것은 2 이상의 영역 세트들의 할당을 요구할 것이다. 예를 들면, 존은 1GB의 데이터에 대하여 할당될 수 있다. 이 존을 구성하는 영역들은 리던던시 데이터를 포함하여 1GB의 데이터를 포함할 수 있을 것이다. 미러링 메커니즘의 경우, 존은 각각 1GB인 영역들의 2 세트로 구성될 것이다. 다른 예로서, 3-디스크 스트라이핑 메커니즘은 각각 1/2 GB인 영역들의 3 세트를 이용한다.

ZM은 존을 구성하는 영역들의 각 세트의 위치(드라이브 번호 및 시작 영역 번호)를 찾아내기 위하여 ZR 번역 테이블(6)을 이용한다. 1/12GB 영역 사이즈를 가정하면, 최대 24 영역들이 요구될 것이다. 24 영역들은 2 x 1GB 존들을 구성한다. 따라서 ZR 번역 테이블은 드라이브/영역 데이터를 제공하는 24 컬럼들을 포함한다.

ZM은 일반적으로 다음과 같이 동작한다:

a. SDM(single drive mirroring)의 경우에, 24 컬럼들이 이용된다. 드라이브 번호들은 모든 컬럼들에서 동일하다. 각 엔트리는 존을 구성하는 물리적 드라이브 상의 물리적 영역에 대응한다. 처음 12 엔트리들은 데이터의 1 사본만 포함하는 영역들을 가리킨다. 마지막 12 엔트리들은 데이터의 제2 사본을 포함하는 영역들을 가리킨다.

b, DDM(dual drive mirroring)의 경우는 처음 12 엔트리들에서의 드라이브 번호가 마지막 12 엔트리들에서의 드라이브 번호와 다르다는 점을 제외하고 SDM과 동일하다.

c. 스트라이핑의 경우에, 3 이상의 컬럼들이 이용될 수 있다. 예를 들면, 3개의 드라이브에 걸쳐서 스트라이핑이 이용된다면, 3개의 상이한 드라이브들로부터 6개의 영역들이 요구될 수 있고(즉, 18 엔트리들이 이용된다), 이 경우 처음 6 엔트리들은 동일 드라이브 번호를 포함하고, 다음 6 엔트리들은 다른 드라이브 번호를 포함하고, 그 다음 6 엔트리들은 제3의 드라이브 번호를 포함하고, 미사용 엔트리들은 제로로 된다.

다음 표는 존 영역 번역 테이블의 표현을 보여준다:

존#	존의 사이즈	각 영역의 사이즈	사용	드라이브/영역(1)	드라이브/영역(2)	...	드라이브/영역(23)	드라이브/영역(24)
0	1GB	1/12	SDM	0,2000	0,1000	...	0,10	0,2000
1	1GB	1/12	DDM	0,8000	0,3000	...	1,2000	1,10
2	1GB	1/12	SD3	3,4000	3,3000	...	4,2000	4,1000
...
N			자유

판독/기입 요구가 들어오면, ZM은 존 번호 및 그 존에 대한 오프셋을 제공받는다. ZM은 ZR 번역 테이블을 조회하여 해당 존에 대한 리던던시 메커니즘을 산정하고 오프셋을 이용하여 어느 드라이브/영역이 판독/기입되어야 하는 섹터를 포함하는지를 산출한다. 그 후 그 드라이브/영역 정보는 실제 판독/기입을 행하기 위해 L1 계층에 제공된다. 이용 컬럼 내의 추가적인 가능한 엔트리는 "자유(Free)"이다. "자유"는 존이 정의되어 있지만 현재 사용되지 않는 것을 나타낸다.

클러스터 관리자는 데이터 존들의 세트 내에 클러스터들을 할당 및 할당 해제한다.

레이아웃 관리자는 존들의 영역들과 비교하여(vis-a-vis) 존들의 실행시간 재배치(run-time re-layout)를 제공한다. 이것은 디스크 삽입/제거 또는 고장의 결과로 일어날 수 있다.

계층 1(L1) 소프트웨어는 물리적 드라이브들 및 물리적 섹터들에 관하여 알고 있다. 그 중에서도 특히, Ll 소프트웨어는 존 관리자에 의해 사용되는 물리적 드라이브들로부터 영역들을 할당한다. 이 예시적 실시예에서, 각 영역은 4-드라이브 어레이 시스템의 경우 1/12GB(즉, 174763 섹터)의 사이즈를 갖는다. 더 큰 최대 수의 드라이브들(8, 12 또는 16)을 갖는 시스템은 상이한 영역 사이즈를 가질 것이다.

SD3(3개의 드라이브에 걸친 스트라이핑, 2개 데이터에 패리티를 더한 것)에 의한 1GB의 데이터를 포함하는 존을 생성하기 위해서는, 3개의 드라이브 각각에 6개의 영역들을 이용하여 끝낼 것이다(6 × 1/12 = 드라이브당 1/2GB).

이 영역 방식의 이용은 존들이 제거되거나 또는, 예를 들어, 미러링으로부터 스트라이핑으로 재구성될 때 디스크 공간의 보다 나은 이용을 제공할 수 있게 한다. L1 소프트웨어는 영역들의 비트맵을 갖는 물리적 드라이브들 상의 이용 가능한 공간을 추적한다. 각 드라이브는 하나의 비트맵을 갖는다. 각 영역은 그 영역이 자유인지, 사용중인지, 불량인지를 추적하기 위하여 비트맵 내의 2 비트에 의해 표현된다. L2 소프트웨어(ZM)가 존을 생성할 필요가 있을 경우, 그것은 L1 계층으로부터 영역들의 세트를 획득한다. 존을 구성하는 영역들은 디스크 내에서 연속되지 않는다.

L1에의 요구들은 다음을 포함한다:

a. (영역들의 그룹 내의 클러스터에 대한) 데이터 판독/기입

b. 데이터 판독/기입 제어(테이블, 데이터 구조, DIC 등)

c. 영역에 대한 물리적 공간 할당(1 드라이브 내의 실제 물리적 섹터들)

d. 영역 할당 해제

e. 물리적 드라이브 내의 물리적 클러스터에 대한 로(raw) 판독/기입

f. 하나의 영역으로부터 다른 영역으로 데이터 복사

g. 영역을 불량으로 표시

자유 영역 비트맵은 클 수 있고, 따라서 자유 엔트리를 찾는 검색(최악의 경우는 자유 엔트리가 없는 경우이다)이 느릴 수 있다. 성능을 향상시키기 위하여, 비트맵의 일부가 메모리에 미리 로딩될 수 있고, 자유 영역들의 링크된 리스트가 메모리에 저장될 수 있다. 각 활성 존에 대한 리스트가 있다. 만일 리스트 상의 낮은 워터마크에 도달하면, 배경 활동으로서 디스크로부터 더 많은 자유 엔트리들이 판독될 수 있다.

디스크 관리자는 계층 0으로서 동작한다. 다음 표에 도시된 바와 같이, 2개의 하위 계층(sub-layer)들, 구체적으로 추상화 계층 및 물리적 저장 어레이와 통신하는 디바이스 드라이버들이 있다.

계층 0a : 추상화

계층 0b : 디바이스 드라이버들에 대한 OS 인터페이스 및 디바이스 드라이버들

물리적 저장 어레이 하드웨어

디바이스 드라이버 계층도 수 개의 계층들을 포함할 수 있다. 예를 들면, USB 드라이버들을 이용하는 저장 어레이의 경우, USB 전송 계층의 위에 ATA 또는 SCSI 스택이 있다. 추상화 계층은 저장 어레이에서 이용되는 드라이버들의 종류에 관계없는 기본 판독/기입 기능들을 제공한다.

디스크 액세스 요구들을 큐(queue)하기 위해 하나 이상의 디스크 액세스 큐들이 이용될 수 있다. 디스크 액세스 레이트들은 본 시스템에서 중요한 성능 병목 장애들 중 하나일 것이다. 일반적인 시스템 레이턴시를 줄이고 성능을 향상시키기 위하여 디스크 인터페이스가 언제든지 되도록 바쁜 상태에 있도록 하길 원할 것이다. 디스크 인터페이스에의 요구들은 디스크 동작이 끝났을 때 동작을 완료하기 위해 콜백 핸들러(callback handler)와 함께, 비동기 인터페이스를 가져야 한다. 하나의 디스크 요구의 완료는 자동으로 큐 상의 다음 요구를 개시할 것이다. 드라이브마다 하나의 큐 또는 모든 드라이버들에 대해 하나의 큐가 있을 수 있다.

계층 1은 논리적 드라이브 번호들로서 드라이브들을 참조할 것이다. 계층 0은 논리적 드라이브 번호들을 물리적 드라이브 참조번호들(예컨대, open() 호출의 결과로서 /dev/sda 또는 파일 디바이스 번호)로 번역할 것이다. 융통성(USB를 통한 확장)을 위하여, 각 논리적 드라이브마다 큐가 있어야 한다.

다음은 몇몇 예시적인 오브젝트 정의들 및 데이터 흐름(data flow)들이다:

MSG 오브젝트: 호스트로부터 입력(incoming)

Lba

Length

LUN

Data

REPLY 오브젝트: 호스트로 출력(outgoing)

Status

Host

Length

Data

데이터 판독(Data Read)

데이터 판독 흐름(Data read flow):

데이터 기입(Data Write)

데이터 기입 흐름(Data write flow):

다음은 물리적 디스크 레이아웃에 대한 설명이다. 위에서 논의된 바와 같이, 각 디스크는 일정한 사이즈의 영역들로 분할된다. 이 예시적 실시예에서, 각 영역은 4-드라이브 어레이 시스템의 경우 1/12GB(즉, 174763 섹터)의 사이즈를 갖는다. 더 큰 최대 수의 드라이브들(8, 12 또는 16)을 갖는 시스템은 상이한 영역 사이즈를 가질 것이다. 처음에, 영역 번호 0 및 1은 영역 관리자에 의해 사용되도록 예비되고 할당을 위해 이용되지 않는다. 영역 번호 1은 영역 번호 0의 미러이다. 주어진 하드 디스크에 대하여 영역 관리자에 의해 이용되는 모든 내부 데이터는 이 하드 디스크의 영역 번호 0 및 1에 저장된다. 이 정보는 다른 드라이버들에 복제(duplicate)(또는 미러링)되지 않는다. 영역 0 또는 1에 에러가 있다면, 그 데이터를 유지하기 위해 다른 영역들이 할당될 수 있다. 디스크 정보 구조는 이들 영역들을 가리킨다.

각 디스크는 그 디스크, 그것이 속하는 디스크 세트, 및 그 디스크에 대한 레이아웃 정보를 식별하는 DIS를 포함할 것이다. 하드 디스크 상의 제1 섹터는 예비된다. DIS는 제1 섹터 뒤에 첫 번째의 불량이 아닌 클러스터에 저장된다. DIS는 1KB 만큼의 데이터에 포함된다. DIS의 2개 사본이 있다. DIS의 사본들은 그것이 속하는 디스크에 저장될 것이다. 또한, 시스템 내의 어느 디스크나 다 시스템 내의 디스크들의 모든 DIS들의 사본을 포함할 것이다. 다음 표는 DIS 포맷을 보여준다:

오프셋	사이즈	이름	값/유효 범위	설명
0	32바이트	disStartSigniture	"_DISC INFORMATION CLUSTER START_"	클러스터를 가능한 디스크 정보 클러스터인 것으로 식별. 클러스터는 그것이 유효한지를 체크하기 위해 CRC되어야 한다.
	워드16	disVersion	제로가 아닌 이진수	구조 버전을 식별. 이 값은 펌웨어의 이전 버전들과 호환성이 없게 만드는 구조 레이아웃 또는 콘텐츠 의미에 실질적인 변경이 이루어질 때만 변경된다.
	워드16	disClusterSize	제로가 아닌 이진수	이 디스크 상에 클러스터를 만드는 512 바이트 섹터들의 수
	워드32	disCRC	CRC-32	DSI 구조의 CRC
	워드32	disSize		DIS 클러스터의 사이즈(바이트)
	워드32	disDiskSet		이 디스크가 속하는 디스크 세트
	워드32	disDriveNumber	0 내지 15	디스크 세트 내의 드라이브 번호
	워드32	disSystemUUID		이 디스크가 속하는 박스의 UUID
	워드64	disDiskSize		섹터의 수로 나타낸 디스크의 사이즈
	워드32	disRegionSize		섹터의 수로 나타낸 영역의 사이즈
	워드64	disRegionsStart		디스크 상의 제1 영역의 시작에 대한 섹터 오프셋
	워드64	disCopyOffset		이 DIS의 사본이 저장되는 곳에 대한 섹터 오프셋. 각 DIS의 disCopyOffset는 서로 참조한다.
	워드64	disDISBackup		모든 디스크의 DIS들의 사본들을 포함하는 테이블에의 섹터 오프셋
	워드32	disDISBackupSize		DIS 백업 섹션 내의 DIS의 수
	워드32	disRIS0Region		RIS의 제1 사본이 저장되어 있는 곳의 영역 번호
	워드32	disRIS0Offset		영역 정보 구조가 위치하는 섹터에 대하여 영역 내에 오프셋된 섹터들의 수
	워드32	disRIS1Region		RIS의 사본에 대한 것
	워드32	disRIS1Offset		RIS의 사본에 대한 것
	워드32	disZIS0Region		존 정보 구조가 위치하는 영역의 영역 번호. 이것은 이 디스크 상에 ZTR이 있는 경우에만 사용된다. 그렇지 않으면, 그것은 제로이다.
	워드32	disZIS0Offset		영역 내의 ZIS에 대한 오프셋
	워드32	disZIS1Region		ZIS의 사본이 위치하는 영역의 영역 번호. 이것은 단일 드라이브 시스템에서만 사용된다. 다른 경우에는, 이 엔트리는 0이다.
	워드32	disZIS1Offset		영역 내의 ZIS에 대한 오프셋

영역 관리자는 그것의 내부 데이터를 영역 정보 구조로 저장한다. 다음은 영역 정보 구조 포맷을 보여준다:

오프셋	사이즈	이름	값/유효 범위	설명
0	워드64	risSignature		이것이 RIS임을 지시
	워드32	risSize		이 구조의 사이즈(바이트)
	워드32	risChecksum		체크섬
	워드32	risVersion		이 테이블(및 비트맵)의 버전
	워드32	risDrive		논리적 드라이브 번호
	워드64	risStartSector		영역 이용 비트맵의 (디스크 내의) 절대 시작 섹터
	워드32	risSectorOffset		현 영역 내의 영역 이용 비트맵의 섹터 오프셋
	워드32	risSizeBitmap		비트맵의 사이즈(비트?)
	워드64	risNumberRegions		이 디스크 상의 영역의 수(비트맵의 사이즈도 암시)

존 정보 구조는 존 관리자가 존 테이블을 어디에서 찾을 수 있는지에 대한 정보를 제공한다. 다음은 존 정보 구조 포맷을 보여준다:

오프셋	사이즈	이름	값/유효 범위	설명
0	워드64	zisSignature		이것이 ZIS임을 지시
8	워드32	zisSize		이 구조의 사이즈(바이트)
12	워드32	zisChecksum		체크섬
16	워드32	zisVersion		이 테이블(및 비트맵)의 버전
20	워드16	zisFlags		이 디스크가 존 정보를 포함하기 위해 이용된다면 비트 0 = 1 비트 14-15 : 리던던시 타입(SDM 또는 DDM만)
22	워드16	zisOtherDrive		존 테이블의 다른 사본을 포함하는 드라이브의 논리적 드라이브 번호
24	워드32	zisNumberRegions		존 테이블의 각 사본을 포함하기 위해 이용되는 영역의 수. 존 테이블 노드들의 수와 같다.
28	워드32	zisStartOffset		존 테이블을 포함하기 위해 이용되는 영역들의 링크된 리스트의 시작을 가리키는 바이트 오프셋. 링크된 리스트 내의 각 엔트리는 '존 테이블 노드'로 불린다.
	워드32	zisNumberofZones		시스템 내의 존들(존 테이블 내의 엔트리들)의 수
	워드32	zisZoneSize		바이트로 나타낸 존의 사이즈

상위 레벨 정보 존들은 존 테이블들 및 상위 레벨 관리자들에 의해 이용되는 다른 테이블들을 포함한다. 이것들은 미러링을 이용하여 보호될 것이다.

다음 표는 존 테이블 노드 포맷을 보여준다:

사이즈	이름	설명
워드32	ztNextEntry	링크된 리스트 내의 다음 엔트리에대한 포인터
워드32	ztCount	이 엔트리의 카운트
워드64	ztRegion	영역 번호

다음은 존 정보의 레이아웃에 대한 설명이다. 존 테이블 노드들의 링크된 리스트는 다음 방식으로 ZIS 뒤에 배치된다:

존 정보 구조

첫 번째 존 테이블 노드(16 바이트)

...
마지막 존 테이블 노드(16 바이트)

이 정보는 존 테이블 영역에 저장된다.

도 16은 발명의 예시적 실시예에 따른 드라이브 레이아웃을 보여준다. 처음 2개 영역들은 서로의 사본들이다. 세 번째(선택적임) 존 테이블 영역은 존 테이블들을 포함한다. 2 이상의 드라이브를 갖는 시스템에서는, 그 드라이브들 중 2개만 ZTR을 포함한다. 단 하나의 드라이브를 갖는 시스템에서는, ZTR의 2개의 (미러링된) 사본들을 유지하기 위해 2개의 영역들이 이용된다. DIS는 ZIS 및 RIS의 위치에 관한 정보를 포함한다. RIS의 제1 사본은 영역 0에 있을 필요가 없다(예컨대, 영역 0가 불량 섹터들을 포함한다면 다른 영역에 배치될 수도 있다)는 것에 유의하자.

존 관리자는 시스템 시동 시에 존들을 로딩할 필요가 있다. 그렇게 하기 위하여, 그것은 DIS들로부터 영역 번호 및 오프셋을 추출한다. 이것은 ZIS의 시작을 가리킬 것이다.

특정 모듈들(예컨대, CAT 관리자)은 그들의 제어 구조들 및 데이터 테이블들을 존들에 저장한다. 계층 3 및 그보다 상위 계층들 내의 모듈에 대한 모든 제어 구조들은 존 0에 저장되어 있는 구조들로부터 참조된다. 이것은, 예를 들면, 실제 CAT(Cluster Allocation Tables) 위치들은 존 0에 저장된 데이터 구조들로부터 참조된다는 것을 의미한다.

다음 표는 존 0 정보 테이블 포맷을 보여준다:

오프셋	사이즈	이름	값/유효 범위	설명
0	워드64	zitSignature		이것이 ZIT임을 지시
	워드32	zitSize		이 구조의 사이즈(바이트)
	워드32	zitChecksum		이 구조의 체크섬
	워드32	zitVersion		이 구조의 버전
	워드32	zitCATLStartOffset		CAT 링크된 리스트의 시작의 (이 존 내의) 바이트 오프셋
	워드32	zitCATSize		CAT 링크된 리스트 내의 노드들의 수. CAT를 포함하는 존들의 수와 같다.
	워드64	zitCATAddressable		CAT에 의해 지원되는 최대 LBA. 유효하게는 CAT의 사이즈
	워드32	zitHTStartOffset		해시 테이블 링크된 리스트의 시작의 (이 존 내의) 바이트
	워드32	zitHITNumberNodes		해시 테이블 링크된 리스트 내의 노드들의 수
	워드64	zitHTSize		바이트로 나타낸 해시 테이블 데이터의 사이즈

CAT 링크된 리스트는 CAT를 포함하는 존들을 기술하는 노드들의 링크된 리스트이다. 다음 표는 CAT 링크된 리스트 노드 포맷을 보여준다:

사이즈	이름	설명
워드32	cat1lNextEntry	링크된 리스트 내의 다음 엔트리에 대한 포인터
워드16	cat1lCount	이 엔트리의 카운트
워드16	cat1lZone	CAT의 이 부분을 포함하는 존 번호

해시 테이블 링크된 리스트는 해시 테이블을 보유하는 존들을 기술하는 노드들의 링크된 리스트이다. 다음 표는 해시 테이블 링크된 리스트 노드 포맷을 보여준다:

사이즈	이름	설명
워드32	htllNextEntry	링크된 리스트 내의 다음 엔트리에 대한 포인터
워드16	htllCount	이 엔트리의 카운트
워드16	htllZone	해시 테이블의 이 부분을 포함하는 존 번호

도 17은 발명의 예시적 실시예에 따른, 존 0의 레이아웃 및 다른 존들이 어떻게 참조되는지를 설명한다.

위에서 논의된 바와 같이, 리던던트 세트는 데이터의 세트에 대한 리던던시를 제공하는 섹터들/클러스터들의 세트이다. 영역 백업은 영역의 콘텐츠를 다른 영역에 복사하는 것을 수반한다.

데이터 판독 에러의 경우에, 하위 레벨 소프트웨어(디스크 관리자 또는 디바이스 드라이버)는 최초 실패 시도 후에 2회 더 판독 요구를 재시도한다. 실패 상태는 존 관리자에게까지 전달된다. 그 후 존 관리자는 디스크 어레이 내의 리던던트 클러스터들로부터 (판독에 의해) 요구되는 데이터를 재구성하려고 시도한다. 리던던트 데이터는 미러링된 데이터(SDM, DDM의 경우) 또는 패리티를 포함하는 클러스터들의 세트(스트라이프 구현의 경우)일 수 있다. 그 후 재구성된 데이터는 호스트에 전달된다. 만일 ZM이 데이터를 재구성할 수 없다면, 판독 에러가 호스트에 전달된다. 존 관리자는 에러 통지 패킷을 에러 관리자에 송신한다. 도 18은 발명의 실시예에 따른 판독 에러 핸들링을 설명한다.

데이터 기입 에러의 경우에, 하위 레벨 소프트웨어(디스크 관리자 또는 디바이스 드라이버)는 최초 실패 시도 후에 2회 더 기입 요구를 재시도한다. 실패 상태는 존 관리자에게까지 전달된다. 존 관리자는 에러 통지 패킷을 에러 관리자에 송신한다.

이 레벨에서 데이터 기입이 수행되는 경우, 리던던시 정보도 디스크에 기입된다. 그 결과, 하나의 클러스터만 기입 에러를 갖는 한, 후속 기입이 데이터를 재구성할 수 있을 것이다. 만일 다수의 디스크 에러들이 있고 리던던시 정보가 판독 또는 기입될 수 없다면, 적어도 2가지의 가능한 접근법이 있다:

a. 기입 에러 상태를 호스트에 반환한다. 리던던트 세트와 관련된 모든 영역들을 불량 섹터들을 포함하지 않는 새로이 할당된 영역들에 백업한다.

b. 기입을 미룬다(hold off) 리던던트 세트와 관련된 모든 영역들을 불량 섹터들을 포함하지 않는 새로이 할당된 영역들에 백업한다. 그 후, 새로이 할당된 영역들 내의 적당한 클러스터에 기입을 행한다(모든 리던던시 부분들, 예컨대, 패리티 등과 함께). 미루어진 기입들을 포함하기 위해 별도의 기입 큐가 이용될 것이다.

접근법 (a)는 저널의 성공적인 기입의 결과로 아마도 기입 상태가 이미 호스트에 송신되었을 것이고, 따라서 호스트가 에러가 있다는 것을 모를 수 있기 때문에 문제가 된다. 대안은 판독에서의 실패(a failure with a read)를 보고하지만, 기입은 허용하는 것이다. 특정 LBA가 불량 판독을 반환해야 하는 것을 추적하기 위해 CAT 내의 비트가 이용될 수 있다.

도 19는 발명의 예시적 실시예에 따른 기입 에러 핸들링을 설명한다.

에러 관리자(EM)는 클러스터를 체크하여 그것이 실제로 불량인지를 확인한다. 만일 그렇다면, 전체 영역이 불량으로 간주된다. 영역의 콘텐츠는 동일 디스크 상의 새로이 할당된 영역에 복사된다. 그 후 현재 영역은 불량(BAD)으로 표시된다. 영역을 복사하는 동안, 에러 관리자는 불량 섹터들과 마주치면 필요할 경우 데이터를 재구성할 것이다. 도 20은 발명의 예시적 실시예에 따라서 에러 관리자에 의한 불량 영역의 백업을 설명하는 논리 흐름도이다.

만일 데이터 판독 에러가 있고 에러 관리자가 주어진 클러스터에 대한 데이터를 재구성할 수 없다면(예컨대, 리던던트 세트에 걸친 판독 에러의 결과로), 재구성될 수 없는 데이터 대신에 제로들이 이용될 것이다. 이 경우, 불량 섹터들을 포함하는 (바로 그 리던던트 세트와) 다른 영역들도 백업되어야 할 것이다. 다시, 재구성될 수 없는 데이터 대신에 제로들이 이용될 것이다.

일단 리던던트 세트의 복사가 이루어지면, EM은 존의 이 부분에 대응하는 클러스터들에의 액세스를 디스에이블한다. 그 후 그것은 새로이 할당된 영역들을 가리키도록 존 테이블을 업데이트한다. 그 후, 클러스터들에의 액세스가 다시 인에이블된다.

이 예시적 실시예는 8개의 스냅숏을 지원하도록 설계되어 있다(이는 해시/클러스터 엔트리들이 특정 스냅숏 인스턴스에 의해 이용되는지 여부를 지시하기 위해 1 바이트의 사용을 허용한다). 스냅숏들과 관련된 2개의 테이블이 있다:

1. 논리적 섹터 어드레스와 그 LSA에 대한 데이터를 포함하는 디스크 상의 클러스터 간의 관계를 획득하기 위해 스냅숏마다의 CAT 테이블(per-snapshot CAT table)이 존재할 필요가 있을 것이다. 궁극적으로 스냅숏마다의 CAT 테이블은 스냅숏이 취해진 순간의 CAT의 사본이어야 한다.

2, 해시 간들과 데이터 클러스터 간을 매핑하는 시스템 해시 테이블. 해시 함수는 어느 스냅숏 인스턴스가 이용되고 있는지에 관계없이 동일 결과를 반환하고, 그 결과 모든 스냅숏들에 걸쳐서 공통이다. 그 결과, 이 테이블은 어떤 스냅숏들에 의해서도 유일한 클러스터가 이용되고 있는지를 이해해야 한다. 해시 클러스터 엔트리는 그 해시 엔트리를 이용한 스냅숏들이 없다면 자유롭게 되거나, 새로운 데이터로 교체될 수 없다.

현재의 그리고 추가되고 있는 스냅숏이 항상 있을 것이다. 해시 엔트리가 생성되거나 업데이트되면, 그 해시 엔트리에 대한 현재의 스탭숏 번호를 적용할 필요가 있을 것이다. 스냅숏이 만들어지면, 현재의 스냅숏 번호는 증가될 것이다.

어떤 스냅숏에 의해서도 더 이상 요구되지 않는 클러스터들/엔트리들은, 해시 테이블을 통해 보행(walking through)하여 회수(retiring) 스냅숏 비트가 세트인 임의의 해시 엔트리들을 찾아 그 비트를 클리어시킴으로써 자유롭게 된다. 만일 스냅숏 바이트가 이제 제로이면, 해시 엔트리는 테이블로부터 제거될 수 있고 클러스터는 자유롭게 될 수 있다.

(새로운 스냅숏 번호가 회수 스냅숏 번호와 동일하기 때문에) 해시 트리에 추가되고 있는 임의의 새로운 엔트리들과의 충돌을 방지하기 위해, 7개의 스냅숏들만 취해질 수 있도록 하고, 최종(8번째) 스냅숏은 회수되고 있는 것으로 한다. 배경 활동으로서 해시 테이블을 보행할 수 있다.

스냅숏을 생성하기 위하여, 주(main) CAT가 업데이트 중일 때마다 제2 CAT 존이 기입될 수 있다. 이들 업데이트는 큐(queue)될 수 있고 섀도우 CAT는 또 다른 작업으로서 업데이트될 수 있다. 스냅숏하기 위하여, 섀도우 CAT는 스냅숏 CAT가 된다.

일단 스냅숏이 행해지면, 이 스냅숏 테이블을 새로운 존에 복사하여 새로운 스냅숏 CAT가 되도록 하기 위해 배경 처리가 킥오프(kick off)될 수 있다. CAT의 복사가 완료할 때까지 섀도우 CAT 큐가 처리되지 않도록 큐가 사용될 수 있다. 만일 섀도우 CAT를 업데이트하기 전에 고장이 발생한다면(그 경우 큐 내의 엔트리들이 분실될 수 있다). 어레이가 온라인 상태가 되기 전에 주(primary) CAT 테이블로부터의 리섀도우(re-shadow)가 수행될 수 있다.

대안적으로, 스냅숏이 요구될 경우, "델타들(deltas)"의 컬렉션에 초기 CAT 사본을 더한 것이 스냅숏을 구성할 수 있을 것이다. 그러면 배경 작업이 이 정보로부터 전체 스냅숏 CAT를 재구성할 수 있을 것이다. 이것은 스냅숏을 하기 위해 거의 또는 전혀 비가동 시간(downtime)을 필요로 하지 않을 것이다. 한편, 다음 스냅숏을 위하여 또 다른 델타들의 세트가 수집될 수 있을 것이다.

파일시스템 인식 저장 시스템

위에서 논의된 바와 같이, 본 발명의 실시예들은 호스트 파일시스템 데이터 구조(즉, 메타데이터)를 분석하여, 호스트 파일시스템의 저장 용도를 결정하고, 호스트 파일시스템의 저장 용도에 기초하여 물리적 스토리지를 관리한다. 편의를 위해, 이러한 기능을 이후 "스캐빈저"로서 칭할 수 있다. 이후 "모니터"로서 칭해질 수 있는 유사한 기능은 저장 용도를 관리하지만 물리적 스토리지를 반드시 관리하는 것은 아니다. 스캐빈저 및 모니터 모두 이하에 설명한다.

도 27은 본 발명의 예시적 실시예에 따른 컴퓨터 시스템(2700)의 개념적 블록도이다. 컴퓨터 시스템(2700)은 특히 호스트 컴퓨터(2710) 및 저장 시스템(2720)을 포함한다. 호스트 컴퓨터(2710)은 특히 호스트 오퍼레이팅 시스템(OS)(2712) 및 호스트 파일시스템(2711)을 포함한다. 저장 시스템(2720)은 특히 파일시스템 인식 저장 컨트롤러(2721) 및 스토리지(2722)(예를 들면, 하나 이상의 밀집된 디스크 드라이브를 포함하는 어레이)를 포함한다. 스토리지(2722)는 특히 저장 컨트롤러 데이터 구조(2726), 호스트 OS 데이터 구조(2725), 호스트 파일시스템 데이터 구조(2723) 및 사용자 데이터(2724)를 저장하는데 사용된다. 파일시스템 인식 저장 컨트롤러(2721)는 (저장 컨트롤러 데이터 구조(2726)과 호스트 OS 데이터 구조(2725) 간에 점선으로 표시된) OS 파티션에 대한 참조를 포함하는 파티션 테이블 같은, (파일시스템 인식 저장 컨트롤러(2721)과 저장 컨트롤러 데이터 구조(2726) 간 점선으로 표시된) 다양한 유형의 정보를 저장 컨트롤러 데이터 구조(2726)에 저장한다. 호스트 OS(2712)는 (호스트 OS 데이터 구조(2725)와 호스트 파일시스템 데이터 구조(2723) 간에 점선으로 표시된) 호스트 파일시스템 데이터 구조(2723)에 대한 포인터/참조를 전형적으로 포함하는, (호스트 OS(2712)와 호스트 OS 데이터 구조(2725) 간에 점선으로 표시된) 다양한 유형의 정보를 호스트 OS 데이터 구조(2725)에 저장한다. 호스트 파일시스템(2711)은 사용자 데이터(2724)에 관련하는 (호스트 파일시스템(2711)과 호스트 파일시스템 데이터 구조(2723) 간에 점선으로 표시되고, 메타데이터로 칭해지는) 정보를 호스트 파일시스템 데이터 구조(2723)에 저장한다. 파일시스템 인식 저장 컨트롤러(2721)는 (호스트 파일시스템(2711)과 파일시스템 인식 저장 컨트롤러(2721) 간에 실선으로 표시된) 호스트 파일시스템(2711)으로부터의 저장 요청을 핸들링하고, 호스트 OS 데이터 구조(2725) 및 호스트 파일시스템 데이터 구조(2723)을 이용하여 (파일시스템 인식 저장 컨트롤러(2721)와 호스트 OS 데이터 구조(2725) 간의 점선 및 파일시스템 인식 저장 컨트롤러(2721)과 호스트 파일시스템 데이터 구조(2723) 간의 점선으로 표시된) 호스트 파일시스템(2711)의 저장 용도를 결정하고, (파일시스템 인식 저장 컨트롤러(2721)와 사용자 데이터(2724) 간 점선으로 표시된) 호스트 파일시스템(2711)의 저장 용도에 기초하여 사용자 데이터(2724)의 스토리지를 관리한다. 특히, 파일시스템 인식 저장 컨트롤러(2721)는 이하에 논의되는 바와 같이 스캐빈저 및/또는 모니터를 구현할 수 있다.

파일시스템 인식 저장 컨트롤러(2721)는 일반적으로 호스트 파일시스템 데이터 구조를 찾고 분석하기 위해 호스트 파일시스템(들)의 내부 작업을 충분히 이해할 필요가 있다. 물론, 서로 다른 파일시스템들은 서로 다른 데이터 구조를 갖고, 서로 다른 방법으로 동작하며, 이들 차이가 설계/구현의 선택에 영향을 미칠 수 있다. 일반적으로 말하면, 파일시스템 인식 저장 컨트롤러(2721)는 스토리지(2722)에 호스트 파일시스템 데이터 구조(2723)를 찾고 그 호스트 파일시스템 데이터 구조(2723)를 분석하여 호스트 파일시스템(2711)의 저장 용도를 결정한다. 그 후, 파일시스템 인식 저장 컨트롤러(2721)는 그러한 저장 용도에 기초하여 사용자 데이터 스토리지(2724)를 관리할 수 있다.

도 28은 본 발명의 예시적 실시예에 따른, 파일시스템 인식 저장 컨트롤러(2721)를 위한 고레벨 논리 흐름도이다. 블록(2802)에서, 파일시스템 인식 저장 컨트롤러(2721)는 호스트 파일시스템 데이터 구조(2723)를 스토리지(2722)에 찾은다. 블록(2804)에서, 파일시스템 인식 저장 컨트롤러(2721)는 호스트 파일시스템 데이터 구조를 분석하여 호스트 파일시스템 저장 용도를 결정한다. 블록(2806)에서, 파일시스템 인식 저장 컨트롤러(2721)는 호스트 파일시스템 저장 용도에 기초하여 사용자 데이터 스토리지를 관리한다.

도 29는 본 발명의 예시적 실시예에 따른, 호스트 파일시스템 데이터 구조(2723)를 찾기 위한 논리 흐름도이다. 블록(2902)에서, 파일시스템 인식 전장 컨트롤러(2721)는 자신의 파티션 테이블을 저장 컨트롤러 데이터 구조(2726)에 찾은다. 블록(2904)에서, 파일시스템 인식 저장 컨트롤러(2721)는 파티션 테이블을 파싱하여, 호스트 OS 데이터 구조(2725)를 포함하는 OS 파티션을 찾은다. 블록(2906)에서, 파일시스템 인식 저장 컨트롤러(2721)는 OS 파티션을 파싱하여 호스트 OS(2712)를 식별하고 호스트 OS 데이터 구조(2725)를 찾은다. 블록(2908)에서, 파일시스템 인식 저장 컨트롤러(2721)는 호스트 OS 데이터 구조(2725)를 파싱하여 호스트 파일시스템(2711)을 식별하고 호스트 파일시스템 데이터 구조(2723)를 찾은다.

파일시스템 인식 저장 컨트롤러(2721)가 일단 호스트 파일시스템 데이터 구조(2723)를 찾기만 하면, 데이터 구조를 분석하여 호스트 파일시스템(2711)의 저장 용도를 결정한다. 예를 들면, 파일시스템 인식 저장 컨트롤러(2721)는 호스트 파일시스템(2711)에 의해 더이상 사용되지 않는 저장 블록을 식별하고 호스트 파일시스템(2711)에 의해 저장된 데이터 유형을 식별함에 따라 그러한 것들을 위해 호스트 파일시스템 데이터 구조(2723)를 사용할 수 있다. 그 후, 파일시스템 인식 저장 컨트롤러(2721)는 호스트 파일시스템(2711)에 의해 더 이상 사용되지 않는 저장 공간을 동적으로 재사용하고 및/또는 데이터 유형에 기초하여 사용자 데이터(2724)의 스토리지를 관리할 수 있다(예를 들면, 빈번하게 액세스되는 데이터는 압축하지 않고 순차 블록으로 저장하여 액세스를 용이하게 하고, 빈번하지 않게 액세스되는 데이터를 압축하고 및/또는 비순차 블록으로 저장하고, 예를 들면, 데이터 유형에 기초하여 서로 다른 인코딩 기법을 적용한다).

도 30은 본 발명의 예시적 실시예에 따른 미사용 저장 공간을 재사용하기 위한 논리 흐름도이다. 블록(3002)에서, 파일시스템 인식 저장 컨트롤러(2721)는 호스트 파일시스템(2711)에 의해 미사용으로 마킹된 블록을 식별한다. 블록(3004)에서, 파일시스템 인식 저장 컨트롤러(2721)는 호스트 파일시스템(2711)에 의해 미사용으로 마킹되지만 파일시스템 인식 저장 컨트롤러(2721)에 의해 사용되는 것으로 마킹되는 임의의 블록들을 식별한다. 블록(3006)에서, 파일시스템 인식 저장 컨트롤러(2721)는 파일시스템 인식 저장 컨트롤러(2721)에 의해 사용되는 것으로 마킹되었지만 호스트 파일시스템(2711)에 의해 더 이상 사용되지 않는 임의의 블록들은 재사용하고, 부가의 저장을 위해 재사용 저장 공간을 이용가능하게 한다.

도 31은 본 발명의 예시적 실시예에 따른, 데이터 유형에 기초하여 사용자 데이터(2724)의 스토리지를 관리하는 논리 흐름도이다. 블록(3102)에서, 파일시스템 인식 저장 컨트롤러(2721)는 특정 사용자 데이터(2724)와 관계된 데이터 유형을 식별한다. 블록(3104)에서, 파일시스템 인식 저장 컨트롤러(2721)는 데이터 유형에 기초하여 선택된 스토리지 레이아웃을 사용하여 특정 사용자 데이터(2724)를 선택적으로 저장한다. 블록(3106)에서, 파일시스템 인식 저장 컨트롤러(2721)는 데이터 유형에 기초하여 선택된 인코딩 기법(예를 들면, 데이터 압축 및/또는 암호화)을 사용하여 특정 사용자 데이터(2724)를 선택적으로 인코딩한다. 이 방법에서, 파일시스템 인식 저장 컨트롤러(2721)는 서로 다른 레이아웃 및/또는 데이터 유형에 맞춘 인코딩 기법을 사용하여 서로 다른 데이터 유형을 저장할 수 있다.

스캐빈저의 일예는 소위 "가비지 컬렉터"이다. 앞서 논의한 바와 같이, 카비지 컬렉터는 (예컨대, 파일이 삭제될 때) 호스트 파일시스템에 의해 더 이상 사용되지 않는 클러스터들을 자유롭게 하기 위해 이용될 수 있다. 일반적으로, 가비지 컬렉터는 자유로운 블록들을 찾고, 그들의 호스트 LSA들을 계산하고, 이 LSA들에 기초하여 그들의 CAT 엔트리들을 찾아냄으로써 작업한다. 특정 LSA에 대하여 CAT 엔트리가 없다면, 클러스터는 이미 자유이다. 그러나, 만일 CAT 엔트리가 위치 확인되면, 참조 카운트는 감소되고, 그 카운트가 제로에 달하면 클러스터는 자유롭게 된다.

하나의 관심사는 가비지 컬렉터가 호스트 파일시스템이 사용중에 있는 블록을 이전에 사용된 적이 있고 어느 시점에 빈 것으로 표시된 블록과 구별하기 어려울 수 있다는 점이다. 호스트 파일시스템이 블록을 기입할 때, 저장 시스템은 그 데이터에 대한 클러스터는 물론 그것을 기술하기 위한 CAT 엔트리를 할당한다. 그 시점부터, 호스트 시스템이 그 후에 그 블록을 사용하지 않게 되더라도, 클러스터는 일반적으로 사용중인 것으로 보일 것이다(즉, 클러스터는 유효 CAT 엔트리와 함께 여전히 사용중일 것이다).

예를 들면, 특정 호스트 파일시스템들은 그것의 사용되는 디스크 블록들을 추적하기 위해 비트맵을 이용한다. 처음에, 비트맵은 예를 들어 모든 비트들을 클리어시킴으로써 모든 블록들이 자유임을 나타낼 것이다. 파일시스템이 이용될 때, 호스트 파일시스템은 그것의 자유 블록 비트맵을 이용하여 블록들을 할당할 것이다. 저장 시스템은 앞에서 개설(outline)된 바와 같이 클러스터들 및 CAT 엔트리들을 할당함으로써 물리적 저장과 이들 파일시스템 할당들을 관련시킬 것이다. 호스트 파일시스템이 몇몇 블록들 다시 그것의 자유 풀로 해방할 때, 그것은 단지 그것의 자유 블록 비트맵 내의 대응하는 비트들을 클리어시킬 필요가 있다. 저장 시스템에서, 이것은 일반적으로, 호스트의 자유 블록 비트맵의 일부를 공교롭게도 포함하는 클러스터에의 기입으로서 명시될 것이고, 아마도 자유롭게 되어 있는 실제 클러스터 자체에 대한 I/O는 없을 것이다(자유롭게 된 클러스터에 대한 I/O가 있을 수 있지만, 예를 들어, 호스트 파일시스템이 어떤 향상된 보안 모드에서 작동 중이라면, 그 경우 그것은 아마도 상한(stale) 클러스터 콘텐츠가 공격자에 의해 판독될 수 있는 가능성을 줄이기 위하여 그 클러스터에 제로들 또는 랜덤 데이터의 강력 암호화 해시(crypto strong hash)를 기입할 것이다). 또한, 호스트 파일시스템이 새로운 할당 요구들을 만족시키고 있을 경우 이전에 자유롭게 된 블록들을 재사용할 것이라는 보장이 없다. 따라서, 만일 호스트 파일시스템이 저장 시스템의 관점에서 새로운 것, 즉, 이전에 사용되지 않은 블록들을 계속해서 할당한다면, 어떤 공간이든 압축을 통하여 재활용될 수 있다는 것을 가정하여, 저장 시스템은 곧 자유 클러스터들을 다 써버릴 것이다. 예를 들면, 파일시스템 블록이 4k라고 가정할 때, 호스트가 파일시스템 블록들 100 내지 500을 할당하고, 그 후 블록들 300 내지 500을 자유롭게 한 다음, 블록들 1000 내지 1100을 할당하면, 총 파일시스템 사용은 300 블록들일 것이지만, 어레이는 사용중인 500 블록을 가질 것이다.

본 발명의 예시적 실시예에서, 저장 시스템은 호스트 파일시스템에 액세스하고, 그것의 자유 블록 비트맵들을 파싱하고, 그 정보를 이용하여 파일시스템에 의해 더 이상 사용되고 있지 않은 클러스터들을 식별함으로써 호스트 파일시스템 디스크 자원들의 해방(release)을 검출할 수 있다. 저장 시스템이 이런 식으로 미사용 클러스터들을 식별할 수 있게 하기 위해서, 저장 시스템은 파일시스템의 자유 블록 비트맵들을 찾아내고 이해할 수 있어야 한다. 따라서, 저장 시스템은 일반적으로 자유 블록 비트맵들을 찾아내고 이용하기 위해 충분히 내부 작업(inner working)을 "이해하는" 소정의 파일시스템들의 세트를 지원할 것이다. 지원되지 않는 파일시스템들에 대해서는, 저장 시스템은 아마도 가비지 수집을 수행할 수 없을 것이고 따라서 과할당(overcommit)되는 것을 피하기 위하여 어레이의 실제 물리적 사이즈를 통지할 뿐일 것이다.

파일시스템 타입(예컨대, NTFS, FAT, ReiserFS, ext3)을 결정하기 위하여, 파일시스템의 슈퍼블록(또는 동등한 구조)을 찾아낼 필요가 있다. 슈퍼블록을 찾기 위하여, OS 분할을 찾아내려는 시도에서 분할 테이블이 파싱될 것이다. OS 분할을 찾아냈다고 가정할 때, 슈퍼블록을 찾아내고 그에 의해 파일시스템 타입을 식별하려는 시도에서 OS 분할이 파싱될 것이다. 일단 파일시스템 타입을 알게 되면, 자유 블록 비트맵들을 찾기 위해 레이아웃이 파싱될 수 있다.

자유 블록들의 검색을 용이하게 하기 위하여, 예를 들면, 전용의 비-리던던트 존(private, non-redundant zone)에 저장될 수 있는 자유 블록 비트맵의 사본을 만들고, 그 사본을 이용하여 검색을 수행함으로써 호스트 파일시스템 비트맵의 이력 데이터(historical data)가 유지될 수 있다. 비트맵의 사이즈가 주어지면, 전체 비트맵에 대해서가 아니라 한 번에 비교적 적은 수의 클러스터들에 대하여 정보가 유지될 수 있다. 가비지 수집이 수행될 때, 현재의 자유 블록 비트맵은 이력 사본과 한 클러스터씩 비교될 수 있다. 할당 상태로부터 자유 상태로 전이하는 임의의 비트맵 엔트리들이 식별될 수 있어, 정리 동작(scavenging operation)을 재활용(reclamation)을 위한 양호한 후보들인 클러스터들에 정확하게 향하게 할 수 있다. 각 비트맵 클러스터가 처리될 때, 이력 사본은 비트맵 동작들의 진행 이력(rolling history)을 유지하기 위해 현재의 사본으로 교체될 수 있다. 시간이 지나면서 자유 블록 비트맵의 사본은 시간적으로 흩어진 클러스터들의 잡동사니(a patchwork of temporally disjoint clusters)가 되겠지만, 자유 엔트리들을 찾아내기 위해 항상 현재의 사본이 이용될 것이므로, 이것은 어떤 문제도 일으키지 않는다.

특정한 상황 하에서, 예를 들어, 호스트 파일시스템이 그것의 자유 블록 비트맵을 이용하여 디스크 블록들을 할당한 후, 그것의 데이터 블록들을 기입한 후, 수정된 비트맵을 다시 디스크에 플러싱(flush)할 경우, 자유 블록 비트맵에 관하여 경쟁 상태(race condition)가 있을 수 있다. 그 경우, 가비지 컬렉터는 파일 시스템이 클러스터를 사용하고 있더라도 그 클러스터를 자유롭게 할 수도 있다. 이것은 파일시스템 훼손으로 이끌 수 있다. 저장 시스템은 그러한 상태를 피하거나 핸들링하도록 구현되어야 한다.

가비지 수집은 꽤 고비용의 동작일 수 있기 때문에, 또한 가벼운 정리(lightweight scavenging)조차도 백엔드 대역폭(back-end bandwidth)을 소비할 것이므로, 가비지 수집은 남용되어서는 안 된다. 가비지 컬렉터는 가벼운 배경의 굼뜬 정리로부터 공격적인 무거운 또는 높은 우선순위 정리까지에 걸쳐 있는 수 개의 모드들에서 실행될 수 있어야 한다. 예를 들면, 가비지 컬렉터는 30%의 공간이 이용될 때 또는 최소 일주일에 한 번 가볍게 실행되고, 50%의 공간이 이용될 때는 약간 더 무겁게 실행되고, 90% 이상의 디스크 공간이 이용될 때는 최고로 높은 우선순위 정리로 실행될 수 있다. 가비지 컬렉터의 공격성은 재활용할 클러스터들의 목표 개수 및 어쩌면 각 수집 실행에 대한 최대 허용가능한 I/O 카운트까지 그것을 제한함으로써 제어될 수 있다. 예를 들면, 가비지 컬렉터는 10,000 이하의 I/O들을 이용하여 1GB를 재활용하도록 구성될 수 있다. 재활용 요구를 달성하지 못한 것은 다음번에 컬렉터가 실행될 때 더욱 공격적으로 동작하도록 컬렉터에의 피드백으로서 이용될 수 있다. 또한 가비지 컬렉터에게 전체 호스트 파일시스템 자유 블록 비트맵을 파싱하고 그것이 가능한 한 할 수 있는 모든 블록들을 재활용하는 허가를 주는 "전부 재활용(reclaim everything)" 모드가 있을 수 있다. 이것은 어레이가 (거의) 완전히 차있을 때 클러스터들을 재활용하려는 최후의 시도로서 행해질 수 있을 것이다. 가비지 컬렉터는 그것의 규칙들을 적용하기 위해 주기적으로 실행될 수 있고 정리 동작을 수행하기로 결정할 수도 있고 안 할 수도 있다. 정리 동작은 또한 다른 모듈로부터, 예를 들면 영역 관리자가 영역을 형성할 클러스터들을 찾으려고 애쓰고 있을 때 그 영역 관리자로부터 명백히 요구될 수 있어야 한다.

가비지 수집 기능은 상태 지시자 메커니즘에 결합될 수 있다. 예를 들면, 어느 시점에서, 저장 시스템은 "적색" 상태에 있을 수 있다. 비록 진행중인 가비지 수집 동작이 "적색" 상태를 없앨 충분한 공간을 자유롭게 할지라도. 관련 상태 정보를 나타내기 위해 추가적인 지시자 상태들이 이용될 수 있을 것이다(예컨대, 적색 지시자 라이트는 가비지 수집 동작이 진행중임을 지시하기 위해 깜박이게 될 수 있다).

도 21은 본 발명의 예시적 실시예에 따른 저장 어레이의 관련 컴포넌트들을 보여주는 개략 블록도이다. 그 중에서도 특히, 저장 어레이는 섀시(2502)를 포함하고, 이를 통하여 저장 관리자(2504)가 복수의 저장 디바이스들(2508₁-2508_N)과 통신하고, 이 복수의 저장 디바이스들은 각각 복수의 슬롯들(2506₁-2506_N)을 통하여 섀시에 연결되어 있다. 각 슬롯(2506₁-2506_N)은 하나 이상의 지시자들(2507₁-2507_N)과 관련될 수 있다. 그 중에서도 특히, 저장 관리자(2504)는 전형적으로 상술한 기능을 구현하기 위한 각종 하드웨어 및 소프트웨어 컴포넌트들을 포함한다. 하드웨어 컴포넌트들은 전형적으로 프로그램 코드, 데이터 구조, 및 데이터와 같은 것들을 저장하기 위한 메모리는 물론 프로그램 코드를 실행하기 위한 마이크로프로세서 시스템을 포함한다.

파일시스템 인식 저장 컨트롤러(2721)를 구현하기 위한 한가지 관심사는 다수의 호스트 파일시스템이 데이터 구조(즉, 메타데이터)를 실시간으로 업데이트하지 않는다는 점이다. 예를 들면, 저널링 파일시스템은 이미 발생한 트랙잭션에 대한 모든 사용자 데이터를 유지하는 것을 정상적으로는 보장하지 않거나, 그러한 트랜잭션에 대한 모든 메타데이터를 복구하는 것을 보장하지 않지만, 일반적으로 일관된 상태로 복구하는 능력만을 보장한다. 성능 및 효율을 위해, 저널링 파일시스템은 종종 사용자 데이터 기입과 메타데이터 기입 간에 어느 정도의 비동기성을 배치한다. 특히, 사용자 데이터 업데이트와 대응하는 메타데이터 업데이트 간에 지연이 있도록 디스크로의 메타데이터 기입이 느리게 수행되도록 하는 것이 일반적이다. 저널 기입은 또한 (마이크로소프트 윈도우즈 인터널의 Ed4에 따른 NTFS 같은) 일부 파일시스템에서 느리게 수행될 수 있다. 더욱이, 느린 메타데이터 기입은 트랜잭션별 방식에 저널의 전개(play-out)에 의해 수행될 수 있고, 게다가, 메타데이터를 이미 디스크상에 있는 사용자 데이터와 일치하지 않는 상태로 시간적으로 푸시할 수 있는 상당한 잠재력을 갖고 있다. 이것의 예로는 호스트가 클러스터를 재할당하고 재할당된 클러스터에 대응하는 사용자 데이터를 전송한 후 할당해제를 보여주는 비트맵 업데이트가 있을 수 있다. 따라서, 저장 시스템은 일반적으로 사용자 데이터의 현재 상태를 신뢰성있게 지시하지 않는 메타데이터 업데이트를 극복할 필요가 있다. 이전의 예에서는, 클러스터가 재사용가능하고 사용자 데이터는 소거가능하다는 것을 의미하는 것으로 저장 시스템이 할당해제를 해석해서는 안된다는 것을 의미하고 있다.

메타데이터 및 저널 업데이트들은 이들이 발생하는 사용자 데이터 업데이트와 전체적으로 비동기이면, 이들 업데이트들이 언제라도 발생할 수 있도록, 저장 시스템은 파일시스템의 내부 작업을 비교적 상세히 이해할 필요가 있고, 따라서, 적절한 의사 결정을 할 수 있도록 종합적인 상태 정보를 저장할 필요가 있다. 그러나, 하기에 설명되는 본 발명의 특정 실시예는 메타데이터 업데이트들이 이들이 포함하는 사용자 데이터가 기입된 후 비교적 결정적인 시간 윈도우 내(예를 들면, 1분내)에 발생할 것이라는 가정하에 동작하도록 설계되어 있다. 그러한 실시예들은, 동작중의 윈도우(VxFS는 일예일 수 있음) 또는 사용자 데이터 업데이트들 및 대응하는 메타데이터 업데이트들 간의 긴 지연이 일어나는 경계 조건(예를 들면, 호스트로부터의 기능 손실 - 이는 일반적으로 저장 시스템의 제어범위를 넘어서는 것으로 어쨌든 데이터 손실을 초래할 수 있고, 또는 저장 싯템이 검출하고 이에 의해 적절히 호스트 활동을 가정하는 임의의 행동을 업악하는 접속 손실임-)을 고집하지 않는 호스트 파일시스템을 핸들링하는 것을 특별히 고려할 필요가 있더라도,이들이 종합적인 상태 정보의 저장 및 파일시스템의 내부 작업을 상세히 이해할 필요가 없다는 점에서 복잡도와 기능성 간의 트레이드오프라는 것이 이해된다.

예시적인 일 실시예에서, 스캐빈저는 순수하게 비동기식으로 동작할 수 있다. 이 실시예에서, 스캐빈저는 주기적으로 비트맵을 전체 또는 부분적으로 스캔하고, 비트맵을 CAT에 포함된 정보와 비교하여, 임의의 저장 어레이 클러스터가 재사용될 수 있는지를 결정하는 순수한 비동기식 작업일 수 있다. 비트맵을 체크하기 전에, 시스템은 또한 비트맵이 이동했는지를 경정하기 위해 비트맵의 위치를 포함하는 블록을 체크할 수 있다.

순수한 비동기식 스캐빈저의 한가지 장점은, 실질적인 비동기식 디스크 I/O(예를 들면, 4k 클러스터로 논리적으로 분할되고 64MB 비트맵을 갖는 2TB 볼륨에 대하여, - 전체 비트맵을 판독하는 것은 스캐빈저가 실행될 때마다 디스크 데이터의 64+MB를 판독하는 것을 포함함-)를 포함하고, 따라서 스캐빈저가 얼마나 종종 실행되는지에 따라 전체적인 시스템 성능에 영향을 미칠 수 있다하더라도, 주 데이터 경로 내의 프로세서 오버헤드에는 직접적인 영향을 기본적으로 미치지 않는다는 점이다. 따라서, 스캐빈저 빈도수는 이용가능한 저장 공간의 양 및/또는 시스템 부하에 따라 변경될 수 있다. 예를 들면, 이용가능한 저장 공간이 풍부하고 시스템 부하가 높으면, 스캐빈저 기능을 보다 덜 빈번하게 실행될 수 있다. 스캐빈저 빈도수를 줄이게 되면, 일반적으로 저장 공간이 재사용되는 레이트를 줄일 것이고, 이는 일반적으로 저장 공간이 풍부한 경우를 수용가능하게 한다. 한편, 이용가능한 저장 공간이 적고 시스템 부하가 낮으면, 스캐빈저 기능은 보다 빈번하게 실행되어 (부가된 처리 오버헤드를 희생해서라도) 저장 공간이 재사용되는 레이트를 증가시킬 수 있다.

또 다른 예시적 실시예에서, 스캐빈저는 부분적으로는 동기식으로 동작하고, 부분적으로는 비동기식으로 동작할 수 있다. 이 실시예에서, 스캐빈저는, 예를 들면, 주 기입 핸들링 경로에 몇몇 부가의 체크를 부가함으로써, 변화가 발생함에 따라 비트뱀에 대한 변화를 모니터링할 수 있다. 스캐빈저는 관심있는 LBA 범위(들)를 포함하는 부트 시간에 테이블(이후 비트맵 로케이터 테이블(Bitmap Locator Table; BLT)이라 칭함)을 구성할 수 있다. 초기화되지 않은 디스크 또는 초기화되었지만 파티션되지 않은 디스크에 대하여, BLT는 일반적으로 단지 LBA 0만을 포함할 것이다. 완전히 초기화되고 포맷된 디스크에 대하여, BLT는 일반적으로 LBA 0, 모든 파티션 부트 섹터의 LBA(들), 비트맵 메타데이터를 포함하는 LBA(들), 및 비트맵 데이터 자체를 포함하는 LBA 범위(들)를 포함할 수 있다.

주 기입 핸들링 경로(예를 들면, HRT)는 전형적으로 기입의 상세가 핸들링되면서 스캐빈저를 호출하는데, 이 경우, 호출은 일반적으로, 관심있는 LBA 범위(들)로 오버랩되는 기입을 식별할 목적으로 BLT를 구비한 기입 요청의 LBA(들)를 내부적으로 상호참조할 수 있다. 다음에, 스캐빈저는 그들 기입을 파싱할 필요가 있는데, 이는 대부분 비동기식으로 행해지지만(이 경우, 하기에 논의되는 바와 같이, 일반적으로 비동기식 작업을 위해 중요한 상세가 저장될 필요가 있음), 중요한 기입은 인라인(inline)으로 파싱된다(예를 들면, 업데이트가 잠재적으로 재할당 비트맵을 나타내는 경우, 그 기입은 BLT가 임의의 추가의 기입이 상호참조되기 전에 업데이트되도록 인라인으로 파싱될 수 있다). 순수한 비동기식 스캐빈저를 참조하여 전술한 바와 같이, 비동기식 작업의 빈도수는 이용가능한 저장 공간의 양 및/또는 시스템 부하에 따라 변경될 수 있다.

비동기식 작업을 위한 스토리지는 큐(queue)의 형태일 수 있다. 그러나, 간단한 큐는 동일 블록에 대한 다수의 요청의 큐잉(queuing)을 가능하게 하고, 이는 기입 캐시의 의미론(semantics)이, 다수의 요청이 캐시에 있는 동일한 데이터 블록(즉, 가장 최근 데이터)을 지적할 것 같기 때문에 발생할 수 있고 동일한 LBA를 나타내는 다수의 요청을 홀드할 이유가 없기 때문에 불충분하다. 이것은 큐를 체크해서 동일 블록에 대한 이전 요청을 삭제함으로써 완화될 수 있다. 또한, 비동기식 작의 빈도수가 이용가능한 저장 공간의 양 및/또는 시스템 부하에 따라 변경된다고 가정하면, 큐에는 비동기식 작업이 업악되는 (몇일동안 지속될 수 있는) 집중 활동 주기 동안 최대 크기에 도달할 것이라는 기대가 제공되어야 한다. 시스템이 동일 LBA에 대하여 다수의 엔트리를 허가하지 않는다고 가정하면, 큐의 최대 이론적 크기는 LBA의 크기와 비트맵 내의 LBA들의 수의 곱이 되고, 이는 큐 크기가 매우 크게 될 수 있다(예를 들면, 2TB 볼륨은 64MB 비트맵(즉, 128K 블록들)을 갖고, 따라서 대략 128*4=512K의 큐 크기를 필요로하고; 16TB 볼륨은 대략 4MB의 큐 크기를 필요로 한다).

비동기식 작업을 위한 대체 스토리지는 비트맵의 비트맵(이후 "비트맵 블록 업데이트 비트맵(Bitmap Block Updates Bitmap" 또는 "BBUB"으로 칭해짐)의 형태일 수 있고, 여기서 각 비트는 실제 비트맵의 한 블록을 나타낸다. BBUB는, 동일 비트는 요청들 각각에 대하여 설정되어 있고, 따라서, 다수의 요청들은 단지 BBUB에서는 단지 한 번만 나타나기 때문에, 동일 블록에 대하여 다수의 요청을 본질적으로 회피한다. 또한, BBUB의 크기는 비동기식 작업과 관계없이 기본적으로 고정되어 있고, 일반적으로 큐보다 공간을 덜 점유한다(예를 들면, BBUB는 2TB 볼륨에 대하여는 메모리 중 16KB를 점유하고, 또는 16TB에 대하여는 128KB를 점유한다). 실제 비트맵이 이동하는 경우에, 저장 시스템은 BBUB에서 비트의 매핑을 손쉽게 조정할 수 있지만, 일반적으로 호스트가 데이터를 교차로 복제하기 전에 계류중인 요청들을 새로운 위치로 매핑하지 않도록 주의할 필요가 있다(사실상, 호스트 파일시스템이 어쨌든 매 LBA마다 재기입할 것이라는 가정하에 비트맵을 소거하는(zero out) 것이 가능할 수 있다). BBUB는 비휘발성 메모리(NVRAM)에 위치되어 현재 BBUB의 손실을 방지하거나, 또는 현재 BBUB가 손실될 수 있고 손실된 정보를 복구하기 위해 재부트 후에 때때로 완전한 비트맵을 실행할 필요가 있다는 것을 이해하면서 휘발성 메모리에 위치될 수 있다. 비트맵은 본질적으로 비동기식 작업을 이미 측정한 요청들의 수에 제공하지 않기 때문에, 저장 시스템은 비동기식 장업이 단지 업데이트된 것이 없다는 것을 결정하기 위해 전체 비트맵에 걸쳐 스캔할 필요가 없도록 비트맵에 설정된 비트들의 수에 관한 통계를 유지할 수 있다. 예를 들면, 저장 시스템은 얼마나 많은 비트들이 비트맵에 설정되어 있는지의 카운트를 유지하고 그 카운트에 기초하여 비동기식 작업의 빈도수를 조정할 수 있다(예를 들면, 사용자가 구성할 수 있는 카운트 소정의 임계치에 도달하지 않으면 그 때까지 비동기식 작업을 실행하지 않음). 그러한 전략은, 예를 들면, 다수의 맵 섹션들 각각에 대하여 설정 비트의 개별 카운트(예를 들면, 1K 청크들)를 유지하고, 또한 어떤 맵 섹션이 가장 높은 카운트를 갖는지를 추적함으로써 더 세분화되어, 비동기식 작업이 단지 가장 큰 보상으로 되돌아 올 것 같은 맵 섹션(들)을 단지 파싱할 수 있다.

업데이트를 파싱하는 것은 일반적으로 서로 다른 LBA에 대하여 서로 다른 논리를 포함한다. 예를 들면, LBA 0로의 변경은 일반적으로 파티션 테이블이 부가되었다거나, 또는 파티션이 테이블에 부가되었다거나, 또는 파티션이 삭제되었다는 것을 의미한다. 파티션 부트 섹터로의 업데이트는 비트맵 메타데이터가 재할당되었다는 것을 의미할 수 있다. 비트맵 메타데이터로의 업데이트는 비트맵이 제거되었거나, 또는 확장되었다는 것을 의미한다. 비트맵 자체로의 업데이트는 클러스트의 할당 또는 할당해제를 나타낼 수 있다. 업데이트가 비동기식으로 파싱되면, 시스템은 일반적으로, 비동기식 작업이 실행한 시간에 의해, 새로운 데이터가 구 데이터를 중첩할 수도 있기 때문에 구 데이터를 새로운 데이터와 용이하게 비교할 수 없다. 이러한 문제를 회피하기 위해, 시스템은 비교를 위해 구 데이터의 개별 사본을 유지하거나, 맵을 반복하고 설정되지 않은 비트를 CAT와 비교한다(이는 약간의 보다 많은 프로세서 오버헤드를 필요로 하지만 디스크 I/O는 덜 필요로 함). 비트맵을 CAT와 간단히 비교하기 위해서는 일반적으로, 전술한 바와 같이, 비트맵 상태가 사용자 데이터와 동기되어 있지 않을 수 있기 때문에, 부가의 논리 및 상태 정보를 필요로 할 수 있다. 또한, 비트맵 데이터의 사본을 유지하기 위해서는 저장 시스템이 새로운 데이터를 구 데이터와 비교하여, 변한 것을 정확하게 결정할 수 있어야 하지만, 저장 시스템은 일반적으로, 전술한 바와 같이, 상태 자체에 의존할 수 있는 이상으로 현재의 사용자 데이터 상태의 정확한 뷰(view)로서 상태 전이를 의존할 수 없다.

또 다른 예시적 실시예에서, 스캐빈저는 순수하게 동기식으로 동작할 수 있다. 이 실시예에서, 스캐빈저는 기입이 발생함에 따라 기입을 처리할 것이다. 수순한 동기식 실시예의 한가지 장점은, 호스트로부터 기입을 핸들링하는 중요 시간 동안 프로세서에 오버헤드를 개재하고, 비동기식 메타데이터 업데이트를 보상하기 위해 부가의 논리 및 상태 정보가 필요하더라도, 비동기식 작업의 동작과 관계된 복잡도 및 그와 관련된 저장을 회피할 수 있다는 점이다.

비동기식 비트맵와 관련하여 클러스터를 재사용하는 한가지 관심사는, 스캐빈저가 사용자 데이터의 상태를 정확하게 반영하지 않은 비트맵 값에 기초하여 클러스터를 부적절하게 비울 수 있다는 점이다. 그러한 문제를 보호하기 위해, 저장 시스템은 수행하는 클러스터 액세스의 몇몇 히스토리(예를 들면, 클러스터에 사용자 데이터를 최근에 액세스하였는지 여부)를 유지하고, 클러스터에 대하여 계류중인 메타데이터 업데이트가 없는 것을 확실히 하기 위해 몇몇 이전 시간 간격에 걸쳐 클러스터가 활동하지 않았다면 클러스터를 재사용한다. 예를 들면, 저장 시스템은 클러스터의 임의의 재사용을 수행하기 전에 클러스터가 적어도 1분 동안 활동하지 않을 것을 요구할 수 있다(일반적으로 말하면, 비활동 시간을 증가시키면 부적절한 재사용의 위험은 감소시키지만, 데이터 삭제에 대응시에 레이턴시를 증가시키고, 따라서, 여기에서는 트레이드오프가 된다). 저장 시스템은, 부가적으로 부가의 디스크 I/O를 희생하기는 하나, 클러스터 활동을 표명할 때 완벽을 위해 저장 시스템이 클러스터 판독을 부가적으로 추적할 수 있음에도 불구하고, 단지 클러스터 기입만을 추적할 수 있다. 비활동 시간은 고정값일 수 있고, 또는 서로 다른 파일시스템에 대하여 서로 다를 수 있다.

클러스터 액세스는, 예를 들면, 스캐빈저 실행에 대한 액세스의 지시자로서스캐빈저 싸이클 수를 CAT에 기입함으로써 추적될 수 있다.

클러스터 액세스는 대안으로, 데이터 기입 전에 파일시스템의 비트맵에 비트를 기입함으로써 추적될 수 있다. 파일시스템의 메타데이터의 임의의 그러한 수정은, 파일시스템 동작과의 임의의 유해한 상호작용을 회피하기 위해 주의하여 조정되어야 한다.

클러스터 액세스는 대안으로, 각 클러스터에 대한 비트, 블록 또는 (어떠한 크기의) 청크를 사용하여 추적될 수 있다. 비트는 일반적으로 엔티티가 액세스될 때 설정되고, 스캐빈저가 다음 실행을 완료하거나 스캐빈저가 다음에 클러스터를 재사용하고자 시도할 때 재설정될 수 있다. 스캐빈저는 일반적으로 재사용을 수행하는 것을 시도할 대 그 비트가 이미 재설정되었을 때에만 클러스터를 재사용할 것이고, 이는 클리어 되는 실제 호스트 파일시스템 비트맵에 있는 대응 비트에 의해 그 자체가 구동될 것이다. 이들 비트는 간단한 비트맵으로서 함께 유지될 수 있고, 또는 분배 비트맵으로서 CAT에 부가(CAT 레코드당 부가의 1비트 필요)될 수 있다. 간단한 비트맵 접근법은 대부분의 데이터 기입 동작에 부가의 판독-수정-기입을 필요로 한다. 참재적으로 비트맵이 메모리에 캐시되지 않으면 주 데이터 경로의 성능 감소를 유발할 수 있다(비트맵은 휘발성 메모리에 캐시될 수 있는데, 이는 비트맵이 예기치못한 정정에 기인하여 손실된다면 문제가 될 수 있고, 또는 비휘발 메모리에서는 메모리 제한에 기인하여 보다 작은 비트맵 따라서 더 적은 그래뉼래리티(granularity)을 필요로 할 수 있다는 문제가 있을 수 있다). CAT 접근법은 일반적으로 J2 및 그의 빈 NVRAM 캐싱으로부터 이점이 있을 수 있다.

클러스터 액세스는 대안으로, 비트맵 업데이트가 수신되고 클러스터 수정이 수행될 때의 타임스탬프를 유지함으로써 추적될 수 있다. 그러면, 클러스터 수정이 비트맵 업데이트보다 이후의 타임스탬프를 가지면, 시스템은 일반적으로 클러스터를 비우지 않을 것이다. 비트 접근법에 비해 이러한 접근법의 한가지 장점은 스캐빈저가 마지막 액세스가 얼마나 오래전에 발생했는지를 결정할 수 있고, 충분히 길면, 클러스터를 즉시 사용할 수 있다는 점이다. 타임스탬프는 또한 CAT 레코드에 부가될 수도 있다. 대안으로, 필드가 단지 스캐빈저 동작에 관련한 시기(age)를 실제로 지시할 필요가 있음에 따라, 각 스캐빈저 실행에 글로벌 식별자가 할당될 수 있다. 시스템은 CAT 내의 유사한 필드를 사용하여, 글로벌 식별자의 값을 표시한다. 글로벌 식별자는 스캐빈저 실행이 가장 최근에 완료되었거나, 또는 그 다음 기한이었거나, 또는 클러스터가 마지막 액세스 되었을 때를 식별할 수 있다. 이 정보는 시기 측정으로서 스캐빈저에 의해 사용될 수 있다. CAT 레코드에서의 공간 소모를 절약하기 위해, 식별자는 단지 1바이트 카운터일 수 있다. 카운터 래핑(wrapping)에 기인한 임의의 부정확한 시기 결정은 자신들보다 더 어린것을 찾는 구 클러스터일 것이다. 필드는 NVRAM에 저장되어, 필드가 재부트마다, 시기로의 몇몇 클러스터 액세스를 너무 이르게 유발하는 제로로 리셋되는 것을 방지할 수 있다.

따라서, 예를 들면, 모든 스캐빈저 실행은 1 바이트 식별자 값과 관계될 수 있고, 이는 스캐빈저 실행을 위한 식별자가 카운터의 증분후(post-increment) 값이 되도록 스캐빈저가 웨이크(wake)할 때마다 증분하는 NVRAM의 글로벌 카운터로서 구현될 수 있다. CAT 관리자는 클러스터에 업데이트를 서비스할 때마다 글로벌 카운터의 현재 값을 사용하고 그 값의 사본을 대응하는 CAT 레코드에 저장할 수 있다. 그와 같이 구현하기 위해서는 CAT 관리자 논리를 수정할 필요가 있다.

클러스터 액세스는 대안으로, 래핑 리스트에 클러스터 업데이트의 짧은 히스토리를 유지함으로써 추적될 수 있다. 다음에 스캐빈저는 리스트를 검색하여, 막 비워진 임의의 클러스터가 호스트에 의해 최근에 액세스되지 않았다는 것을 검증한다. 리스트의 크기는 일반적으로 특별히 구현될 것이다. 그러나, 크기가 길어지면, 저장 시스템은 일반적으로 리스트가 완전히 채워지기 전에 비동기식 작업을 실행하고, 게다가 조용한 주기까지 작업을 연기하기 위한 능력을 보상해야만 한다.

스캐비닝을 지원하는 저장 시스템에서는, 특히, 너무 이른 재사용 때문에 실패하는 판독(즉,스캐빈저에 의해 비워진 클러스터로부터 판독 시도), 그러나 또한 할당되지 않은 클러스터(이는 일반적으로 할당될 것이고 따라서 해는 없게됨)로의 기입같은 너무 이른 재사용을 식별하고 추적하는 것이 바람직할 수 있다. 몇몇 상황에서, (예를 들면, 사용자 데이터 기입으로부터의 비트맵 및 적절한 비트가 설정된 체크에 대한 상호참조하여) 파일시스템 비트맵에 기초하지만, 단지 비트맵 업데이트가 사용자 데이터를 앞두고 완료될 것이라는 것을 보장한다면 - 이는 항상 있는 경우는 아님 - 에러를 식별하는 것이 가능하다. 대안으로, 비트맵을 파싱할 때, 스캐빈저는 할당된 비트가 실지로 할당된 클러스터에 대응하는지를 체크하고; 할당된 클러스터가 없으면, 클러스터 또는 적어도 CAT 레코드를 할당하고; 그러한 각각의 CAT 레코드에 스캐빈저로부터 할당이 강제로 되었다는 것을 지시하는 비트를 설정하고; 클러스터로의 데이터 기입에 의해 리세트되는 비트; 및 다음 스캐빈저 실행시에 그 비트를 다시 체크하고 여전히 설정되어 있으면 스크리밍한다(scream). 이러한 방지 조치에 기인하아 클러스터 재사용이 중단된 회수의 카운트 같은 부가의 자가진단을 포함하여 파일시스템이 이것을 얼마나 행하는지를 우리에게 알려준다.

전술한 세 가지 유형의 스캐빈저는 단지 예시적인 것으로 본 발명을 임의의 특정 설계 또는 구현예로 한정하는 것은 아니다. 각각의 스캐빈저 유형은 특정 구현예에 대하여 특히 적절하거나 적절하지 않을 수 있는 임의의 상대적인 장점 및 단점이 있다. 또한, 특정 구현예는 하나 이상의 스캐빈저 유형을 지원할 수 있고, 예를 들면, 호스트 파일시스템, 이용가능한 저장 공간량, 및 시스템 부하같은 것에 기초하여 필요에 따라 그들 스캐빈저를 유동적으로 교환할 수 있다. 비동기식 작업을 위한 정보를 저장하기 위해 BBUB를 사용하고, 클러스터 액세스를 추적하기 위해 (분류의 타임스탬프로서) CAT 내의 바이트 크기 스캐빈저 실행 카운터를 사용하는, 부분적으로는 동기식이고, 부분적으로는 비동기식인 스캐빈저가 특정 구현예를 위해 계획된다.

스캐빈저에 부가하거나, 또는 그 대신의 개별 모니터를 사용하여, 얼마나 많은 클러스터가 호스트 파일시스템에 의해 사용되고 있는지를 추적한다(예를 들면, 호스트 파일시스템이 공지되어 새로운 블록을 사용하기 보다는 할당해제된 블록을 신뢰성있게 사용함으로써 재사용이 필요없고 모니터링이 충분하다면 스캐빈저는 생략될 수 있다; 모니터는 스캐빈저를 구현하는 시스템에 복사함으로써 생략될 수 있다). 일반적으로 말하면, 모니터는 단지 얼마나 많은 비트가 비트맵에 설정되는지를 결정하는데에만 필요하고 어떤 비트가 설정되고 어떤 비트가 클리어되는지를 정밀히 아는데에는 필요치 않다. 또한, 모니터는 정밀한 비트 카운트를 필요로 하지 않지만, 단지 설정 비트의 수가 임의의 임계값보다 크거나 작은지를 결정하거나, 또는 그 수가 동일 영역에 대한 이전 값보다 크거나 작은지를 결정하는데에만 필요할 수 있다. 따라서, 모니터는 전체 비트맵을 파싱할 필요가 없을 수 있다.전술한 스캐빈저 실시예들에 대하여, 새로운 데이터를 CAT와 주기적으로 비교하거나 또는 비트맵의 사본을 유지하고 사본을 새로운 데이터로 덮어쓰기 전에 현재 비트맵(새로운 데이터)을 사본(구 데이터)와 비교할 수 있는, 모니터 기능은 비동기 작업을 사용하여 전체 또는 부분적으로 구현될 수 있다.

편의를 위해, 스캐빈저를 참조하여, 주로 NTFS와 관련하여 하기에 다양한 설계 및 동작을 고려하여 논의된다. 그러나, 많은 설계 및 동작 고려가 모니터에도 동일하게 적용된다는 것을 이해해야 한다.

도 32는 본 발명의 예시적 실시예에 다른, 스캐빈저(3210)의 관련 컴포넌트를 도시하는 개략 블록도이다. 특히, 스캐빈저(3210)는 비트맵 블록 업데이트 모니터(BBUM; 3211), 각각의 LUN에 대한 BLT를 포함하는 비트맵 로케이터 테이블들(BLT; 3212)의 컬렉션, 각 파티션에 대하여 하나의 BBUB를 포함하는 BBUB들(3213)의 컬렉션, 비동기 작업(3214), 및 할당해제된 공간 테이블들(DST; 3215)을 포함한다. 이들 컴포넌트 각각은 이하에 보다 상세히 설명된다. 또는 이하에 보다 상세히 설명되는 바와 같이, BBUM(3211)에는 HRM(3220)으로부터 수신된 호출을 통해 기입 동작이 통지된다.

스캐빈저(3210)는 각각의 LUN에 대한 BLT(3212)를 포함한다. 각각의 BLT(3212)는 파티션 식별자, LBA 범위, LBA 범위의 역할 지시, 및 LBA 범위가 동기식으로 또는 비동기식으로 파싱되어야 하는지의 여부를 나타내는 플래그를 포함하는 일련의 레코드를 포함한다. 각각의 BLT는 LBA 0에 대한 엔트리를 갖는데, 이는 파티션과는 독립적이다. BLT들에는 일반적으로 빠른 LBA기반 룩업을 (그들이 처음에 속한 파티션이 어떤 것인지를 체크하지 않고) 그 LUN 상의 입력 기입에 제공하는 것이 필요하고, 상대적으로 빠른 파티션 기반 룩업을 (예를 들면, 스토리지를 위한 분류 벡터 및, 룩업에 대하여는, 시작 LBA의 하위 경계(bound) 이진 검색 플러스 이전 요소가 룩업되는 LBA보다 높은 마지막 LBA를 갖는지의 검사를 사용하여 달성될 수 있는) LBA 0 기입에 제공하는 것이 필요하다. BLT들은 일반적으로, 예를 들면, LoadDiskPack 호출 동안 통과하는 임의의 호스트 기입 전에 프로그래밍될 필요가 있을 것이다. BLT는 LBA 0(이것이 파티션 테이블의 위치임에 따라)로 프로그래밍되고, 따라서 파티션의 생성은 이 LBA로의 기입을 포함한다. LBA 0는, 이 테이블 내에서, 업데이트가 즉각적인 파싱을 필요로 하는 위치로서 플래깅(flagged)될 것이다.

스캐빈저(3210)는 저장 시스템에 의해 지원되는 각각의 파티션에 대한 BBUB(3213)를 포함한다. 각각의 BBUB(3213)는 그가 속하는 파일시스템 비트맵의 크기에 적절한 크기로된다(sized). 각각의 BBUB(3213)는 비트맵에 비트가 얼마나 설정될 수 있는지를 반영하는 카운터와 관계가 있다. BBUB(3213)는 또한 각각의 비트맵이 자신의 대응하는 파일시스템 비트맵에 얼마나 적합한지를 보여주는 몇몇 매핑 정보와 관계가 있다.

스캐빈저(3210)는 각각의 LUN에 대한 DST(3215)를 포함한다. 각각의 DST(3215)는 레코드당 하나의 LBA 범위를 포함한다. 테이블에 제공된 각각의 LBA 범위는 CAT로부터 재사용될 필요가 있는 삭제되거나 종료된 파티션의 일부이다. BBUM(3211)은, 예를 들면, 동기 처리동안 재사용을 위해 미사용 저장 영역을 식별할 때, DST(3215)를 업데이트할 수 있다(이 경우, BBUM(3211)은 LBA 범위를 DST(3215)에 부가한다). 유사하게, 비동기 작업(3214)은, 예를 들면, 비동기 처리동안 재사용을 위해 미사용 저장 영역을 식별할 때, DST(3215)를 업데이트할 수 있다(이 경우, LBA 범위를 DST(3215)에 부가한다). 비동기 작업(3214)는 DST(3215)를 사용하여, 미사용 저장 공간을 비동기식으로 재사용한다. DST(3215)는 언클린(unclean) 셧다운으로 복구되는 방식으로 계속해서 저장될 수 있고, 또는 다른 부가의 논리를 제공하여, 예를 들면, 부팅 후 풀(full) 스캔을 수행하여 어떠한 볼륨에도 속하지 않는 할당된 클러스터를 찾음으로써 DST(3215)의 임의의 손실을 복구할 수 있다.

BBUB(3213)와 DST(3215)의 스토리지는 특정한 구현예이다. 예시적 실시예에서, BBUB(3213)는 NVRAM에 저장하기에는 너무 크고, 따라서, 휘발성 메모리나 디스크 상에 저장할 수 있는 한편, DST(3215)는 비휘발성 메모리, 휘발성 메모리, 또는 디스크상에 저장될 수 있다. DST(3215)와 BBUB(3213)가 완전히 휘발성이라면, 스캐빈저(3210)는 일반적으로 DST(3215)와 BBUB(3213)의 (예를 들면, 예기치 못한 셧 다운에 기인한) 손실을 복구할 수 있어야 한다. 복구는, 예를 들면, 전체의 CAT를 스캐닝하고 그것을 현재의 파티션 및 클러스터 비트맵 정보와 비교하여 각각의 클러스터가 공지의 파티션에 매핑되는지 그리고 대응하는 파일시스템의 클러스터 비트맵에 할당되는지를 앎으로서 이루어질 수 있다. 또 다른 가능성은, 클러스터 비트맵의 현재 상태가 소실됨에도 불구하고, 모든 클러스터 비트맵의 풀 스캔을 필요로 하면서, NVRAM에 DST(3215)를 저장하고 BBUB(3213)를 휘발성 메모리에 두어 볼륨 외부의 디스크 공간에 대한 상태 정보가 (잠재적으로 파티션 외부의 클러스터에 관하여 CATM에 질의할 필요를 방지하면서) 재부팅에 걸쳐 유지되도록 하는 것이 있다. 그러한 비트맵 스캔은, 예를 들면, 모든 필요한 상태 정보를 디스크에 저장하고 단지 부팅시에 재로딩함으로써 감소되거나 제거될 수 있다. 스캐빈저(3210)가 셧다운의 통지를 예상할 수 없기 때문에, 레코드들은 그들을 동기식으로 업데이팅하거나 또는 그들을 단지 몇 밀리초 또는 몇 초내에 다시 기입함으로써, 실시간 상태로 밀접하게 동기될 필요가 있다. 호스트가 실제로 셧다운되지는 않더라도, 의도적인 셧다운은 호스트로부터의 비활동인 몇 초만큼 선행되고, 따라서, 몇 초 내의 업데이트는 아마도 대부분의 상황에 대하여 충분하다고 가정하는 것이 합리적일 것 같다; 그럼에도 불구하고 I/O 중간(mid-I/O)에 발생된 셧 다운은 여전히 풀 스캔을 필요로 할 것 같다. 레코드들이 동기식으로(즉, 비트맵 업데이트를 디스크에 기입하기 전에) 업데이트되면, 시스템은 (부팅시 보다 나은 효율을 얻기 위해 정상 상태 동안 더 많은 디스크 I/O를 요구하더라도) 상태의 손실 및 부팅시 풀 스캔에 대한 대응하는 필요성을 완전히 제거할 수 있다. 또 다른 옵션은 정보가 재부팅시 이용가능하도록 (예기치못한 실패/셧다운의 경우-이 경우 재부팅시 클러스터의 풀 스캔이 필요할 수 있음-는 제외하고) 시스템 셧다운 과정동안 BBUB(3213)와 DST(3215)를 디스크에 기입하는 것이다.

일반적으로 말하면, 스캐빈저(3210)는, 본 예시적 실시예에서 (DiskPack으로부터 판독하기 위한) 캐시 관리자 또는 CAT 관리자 및 (카운터를 증분시키기 위한) NVRAM 관리자 같은, 스캐빈저가 의존하는 모듈을 초기화한 후 스캐빈저(3210)가 시스템 관리자에 의해 초기화될 것이라고 계획되었더라도, 디스크 팩이 로딩될 때까지 많은 일을 할 필요는 없다. 대안으로, 스캐빈저는, 예를 들면, DiskPack이 로딩된 후 천천히 초기화될 수 있다. 스캐빈저는 DiskPack으로부터 거의 즉시 판독을 시작할 수 있기 때문에, 스캐빈저는 다른 컴포넌트가 준비되어 있고 동일한 DiskPack을 로딩할 때까지 DiskPack(즉, LoadDiskPack)을 로딩하도록 지시받지 못해야 한다.

스캐빈저(3210)의 초기화 동안(또는 어느 정도의 다른 적당한 시간에), BBUM(3211)은 LBA )에서 NTFS 파티션 테이블을 찾는다. NTFS 파티션 테이블은 Master Boot Record, 즉, LBA 0로서 동일 LBA에 위치된 64바이트 데이터 구조이다. 각각의 파티션 테이블 엔트리는, 최대 네개의 엔트리를 이용가능하게 하는, 16바이트 길이이다. 각각의 엔트리는 소정 구조 및 섹터의 시작부로부터의 소정의 오프셋에서 시작한다. 파티션 레코드는 저장 시스템이 파티션 유형이 NTFS인지 아닌지의 여부를 결정하도록 하는 시스템 식별자를 포함한다. 파티션 테이블 포지션 및 레이아웃은, 단지 NTFS가 아니고, 단지 마이크로소프트 포맷이 아니고, 동일한 파티션 테이블 구조가 파일시스템 포캣의 범위를 제공하면서, 일반적으로 그를 기입하는 오퍼레이팅 시스템과는 어느정도 독립적이라는 것이 발견되었다(HFS+ 및 다른 파일시스템은 서로 다른 구조를 사용하여 자신의 파티션을 찾는다).

NTFS 파티션 테이블이 LBA 0에서 발견된다고 가정하면, BBUM(3211)은 LBA 0로부터 파티션 테이블을 판독한 다음, 파티션 테이블에서 식별된 각각의 NTFS 파티션에 대하여, 파티션의 부트 섹터(파티션의 제1 섹터) 및, 특히 Master File Table(MFT)의 위치를 제공할 NTFS 파티션에 대한 구조 비밀(proprietary)인 확장 BIOS 파티션 블록을 판독한다. 다음에, BBUM(3211)은 MFT의 상주하는 ＄bitmap 레코드를 판독하여 파일 속성, 특히 실제 비트맵 데이터의 위치(들) 및 길이(들)을 얻는다. BBUM(3211)은 또한 각각의 파티션의 부트 섹터 LBA, 비트맵 레코드(들)의 LBA(들), 및 실제 비트맵의 LBA들로 BLT(3212)를 프로그래밍한다. 부트 섹터 LBA들 및 비트맵 LBA들은 또한, 업데이트가 항상 즉각적인 파싱을 요구하는 위치들로서 플래깅될 것이다. 실제 비트맵은 일반적으로 즉각적인 파싱을 필요로 하지 않고 적절히 플래깅될 것이다. LBA 0에서 파티션 테이블이 발견되지 않으면, BLT(3212)에 부가의 위치가 부가되지 않는다.

도 33은 본 발명의 예시적인 실시예에 따른, 호스트 파일시스템 비트맵을 찾는 의사 코드이다. 파일시스템 인식 저장 컨트롤러(2721)는 우선 LBA 0에서 파티션 테이블을 찾는다. 파티션 테이블이 발견되는 것으로 가정하면, 파일시스템 인식 저장 컨트롤러(2721)는 파티션 테이블을 판독하여 파티션을 식별한다. 그 후, 각각의 파티션에 대하여, 파일시스템 인식 저장 컨트롤러(2721)는 파티션의 부트 섹터를 판독하여 MFT를 발견하고, MFT의 상주하는 ＄bitmap 레코드를 판독하여, 실제 비트맵의 위치(들) 및 길이(들) 같은 파일 속성을 얻는다. 파일시스템 인식 저장 컨트롤러(2721)는 각 파티션의 부트 섹터 LBA, 비트맵 레코드(들)의 LBA(들), 및 실제 비트맵(들)의 LBA(들)로 BLT들을 프로그램하고, 즉각적인 파싱을 요구하도록 비트맵 레코드 LBA(들) 및 부트 섹터 LBA(들)을 플래깅하고 즉각적인 파싱을 요구하지 않도록 실제 비트맵(들)을 플래깅한다. 파일시스템 인식 저장 컨트롤러(2721)가 LBA 0에서 파티션 테이블을 찾을 수 없다면, 파일시스템 인식 저장 컨트롤러(2721)는 BLT들에 부가의 위치를 부가하지 않고 종료한다.

정상 상태 동작 동안, 모든 기입은 HRM(3220)으로부터 BBUM(3211)로의 호출을 통해 BLT들(3212)에 대하여 상호참조될 것이다. LBA 0로 어드레싱될 것으로 발견되는 임의의 기입은 그 액션을 지시하는 플래그마다 즉각적으로(동기하여) 파싱될 것이다. 후속의 액션은 업데이트의 성격에 의존한다.

파티션이 부가되고 있고, 파티션이 인식된 유형이면, 새로운 파티션의 제1 LBA는 BLT(3212)에 부가될 것이고, 업데이트가 항상 즉각적인 파싱을 요구하는 위치로서 플래깅될 것이다. DST(3215)는, 클러스터 재사용을 구동할 일련의 업데이트를 구비하는 비트맵이 곧 있을 것이라고 예상하면서, 새로운 파티션 내에 있는 임의의 LBA 범위에서 제거될 것이다. 한가지 관심사는, 파티션이 파티션 테이블 업데이트에 앞서 기록될 것이었다면, 이 정보는 잠재적으로 DST(3215)의 블록에 기입되고, 스캐빈저 쓰레드에 의해 부정확하게 재사용될 수 있다. 이것은, 예를 들면, DST(3215)의 범위와의 일치를 위해 수신된 모든 기입을 체크하고, DST(3215)로부터 임의의 기입된 블록(written-to block)을 제거함으로써 완화될 수 있다.

윈도우 디폴트로부터 NTFS로 파티션 식별자를 변경하기 위해 파티션이 업데이트되고 있으면, BBUM(3211)은, 식별자 변경이 파티션 부트 섹터가 기입된 후에 발생하는 경향이 있으므로, 파티션 부트 섹터의 위치에서 LUN을 즉시 재검사할 것이다. 이것이 파티션 부가의 바로 그 부분이다.

기존 파티션이 제거중이면, BLT는 삭제된 파티션에 관련된 레코드들이 넘치게(flushed)될 것이고, 그 파티션에 대한 BBUB(3213)는 삭제될 것이고, 클러스터의 비동기식 재사용을 위해 DST(3215)에 LBA 범위가 부가될 것이다.

기존 파티션이 재배치 중이면, BLT(3212)에 있는 기존 부트 섹터 레코드는 모니터에 대하여 새로운 부트 섹터 LBA로 업데이트될 것이다. 잠재적으로, 이미 기입된 경우 새로운 위치에서 LUN이 즉각적으로 재검사될 것이지만, 이는 일반적으로 행해지는 것은 아니다.

기존 파티션이 종료되는 중이면, DST(3215)에 삭제된 LBA 범위가 부가될 것이다. 잠재적으로, 새로운 부트 섹터가 이미 기입된 경우 파티션 부트 섹터의 위치에서 LUN이 즉각적으로 재검사될 것이지만, 이는 일반적으로 행해지는 것은 아니다.

기존 파티션이 확장 중이면, DST(3215)는 새로운 파티션 내에 있는 임의의 LBA 범위에서 제거될 것이다. 잠재적으로, 새로운 부트 섹터가 이미 기입된 경우 파티션 부트 섹터의 위치에서 LUN이 즉각적으로 재검사될 것이지만, 이는 일반적으로 행해지는 것은 아니다.

파티션의 제1 LBA에 어드레싱될 것으로 발견되는 임의의 기입은 그 액션을 지시하는 플래그마다 즉각적으로(동기하여) 파싱될 것이다. 비트맵 레코드의 시작 LBA가 결정되고, BLT(3212)에 부가되며, 업데이트가 항상 즉각적인 파싱을 요구하는 위치로서 플래깅될 것이다.

도 34는 본 발명의 예시적 실시예에 따른, BBUM(3211)에 대한 고레벨 의사 코드이다. BBUM(3211)이 클라이언트 요청을 수신하는 경우, ClientRequest로부터 LUN를 얻고 그 LUN에 기초하여 올바른 BLT를 찾는다. BBUM(3211)이 ClientRequest로부터 LBA를 얻고, BLT에서 이 LBA를 찾으며, 이 LBA에 대하여 즉각적인 액션이 필요한지를 알기 위해 "immediate action" 필드를 체크한다. 즉각적인 액션이 필요하면, BBUM(3211)은 클라이언트 요청을 동기하여 처리한다. 그러나, 즉각적인 액션이 필요하지 않으면, BBUM(3211)은 비동기 처리를 위해 LBA에 대응하는 BBUB 비트를 설정한다.

도 35는 본 발명의 예시적 일 실시예에 따른, 새로운 파티션을 생성하는 LBA ) 업데이트의 동기식 처리를 위한 고레벨 의사 코드이다. 특히, 즉각적인 액션이 요구되고 블록이 파티션 테이블이면, BBUM(3211)은 새로운 데이터에 있는 파티션을 BLT에 있는 파티션과 비교한다. 새로운 파티션이 부가되고 있는 중이면, BBUM(3211)은 새로운 데이터로부터 파티션의 시작부(start) 및 종료부(end)를 얻고, 임의의 중첩하는 LBA 범위에 대하여 DST들(3215)을 체크하여, 이들을 제고하고, BLT에 파티션의 시작부를 부가하고, 즉각적인 액션을 위해 엔트리를 플래깅한다.

도 36은 본 발명의 예시적 실시예에 따른, 파티션을 (재)포맷팅하는 LBA 0 업데이트의 동기식 처리를 위한 고레벨 의사 코드이다. 특히, 즉각적인 액션이 필요하고 블록이 파티션 부트 섹터이면, BBUM(3211)은 새로운 데이터로부터 MFT의 시작부를 얻고, 비트맵 레코드의 위치를 계산한다. 이 파티션에 대하여 BLT에 이미 동일한 비트맵 레코드가 있으면, 아무것도 필요하지 않다. 그러나, 비트맵 레코드가 BLT 버전으로부터 서로 다른 위치에 있으면, BBUM(3211)은 BLT를 업데이트하고, 디스크로부터 새로운 위치를 판독한다. 그 위치가 비트맵 레코드처럼 보이지 않는다면(즉, ＄bitmap 스트링을 갖지 않는다면), 아무것도 필요하지 않다. 그러나, 그 위치가 비트맵 레코드처럼 보인다면, BBUM(3211)은 새로운 비트맵 위치(들)를 얻고, 이들을 BLT와 비교한다. 새로운 비트맵 위치(들)가 동일하면, 아무것도 필요하지 않다. 새로운 비트맵들이 서로 다른 위치에 있다면, BBUM(3211)은 모든 BBUB 비트를 설정하고, BBUB 매핑을 업데이트하며, BLT에서 LBA 범위를 제거한다.새로운 비트맵이 기존의 비트맵보다 작으면, BBUM(3211)은 BBUB를 단축시키고, 매핑되지 않은 LBA를 DST에 부가하며, BLT에 LBA 범위를 단축시킨다. 새로운 비트맵이 기존 비트맵보다 더 크면, BBUM(3211)은 모든 부가의 BBUB 비트를 설정하고, BBUB를 확대하며, BLT에 LBA 범위를 확대한다.

도 37은 본 발명의 예시적 실시예에 따른, 파티션을 삭제하는 LBA 0 업데이트의 동기식 처리를 위한 고레벨 의사 코드이다. 특히, 즉각적인 액션이 필요하고 블록이 파티션 테이블이면, BBUM(3211)은 새로운 데이터에 있는 파티션을 BLT에 있는 파티션들과 비교한다. 파티션이 삭제 중이면, BBUM(3211)은 BBUB를 삭제하고, BLT로부터 부트 섹터를 삭제하며, BLT로부터 비트맵 레코드를 삭제하고, BLT로부터 비트맵 범위를 삭제하며, 파티션 범위를 DST에 부가한다.

도 38은 본 발명의 예시적 실시예에 따른, 비동기식 작업(3214)을 위한 고레벨 의사 코드이다. 비동기식 작업(3214)는 BBUB를 파싱한 다음, BBUB에 있는 각 비트 세트에 대하여, 비동기식 작업(3214)은 대응하는 클러스터가 호스트 파일시스템에 의해 사용되지 않은 것으로 마킹되는지를 체크한다. 클러스터가 호스트 파일시스템에 의해 사용되지 않은 것으로 마킹되면, 비동기식 작업(3214)은 클러스터가 저장 컨트롤러에 의해 사용되는 것으로 마킹되는지를 체크한다. 클러스터가 저장 컨트롤러에 의해 사용되는 것으로 마킹되면, 비동기식 작업(3214)은 DST에 LBA 범위를 부가한다. 비동기식 작업(3214)은 또한 DST에 있는 각 LBA 범위에 대하여 저장 공간을 재사용한다.

부트 섹터 업데이트 후에, 비트맵 레코드가 이미 디스크에 기입될 수 있기 때문에, 비트맵 레코드의 기을 대기하는 것은 일반적으로 충분하지 않다(일반적으로 NTFS 포맷이 무슨 순서로 발생하는지 알지 못하고, 어쨌든 미소 패치에 변경이 있을 수 있다). 확장 BPB 전에 비트맵 레코드가 기입되면, BBUM(3211)은 위치가 BLT(3212)에 제공되지 않기 때문에 그것을 캐치하지 못할 것이다; 이에 대한 예외는 비트맵 레코드의 위치가 변경되지 않을 때이다. 예외에도 불구하고, BBUM(3211)은 일반적으로 비트맵 레코드가 제공되는지를 알기 위해 이 포인트에서 디스크로부터 비트맵 레코드 위치를 즉시 판독해야 하고, 초기화된 비트맵 레코드로부터 랜덤 잡음을 구별할 수 있는 것이 일반적으로 필요하다(＄bitmap Unicode 스트링에 대한 체크가 가능하다). 기입되지 않았다면, 기입을 대기할 수 있다. 디스크 상에 이미 있다면, 일반적으로 즉시 파싱해야 한다. 파싱은 일반적으로 레코드가 비트맵의 위치(들)에 대하여 디코딩될 필요가 있고, 그들 위치가 BLT(3212)에 부가되고 즉각적인 파싱을 요구하지 않는 것으로서 플래깅된다. 파싱은 일반적으로 또한, 비트맵의 크기가 변경되었다면, 새로운 BBUB(3213)가 비트맵의 위치(들) 및 새로운 크기에 기초하여 예시될 필요가 있고; 그렇지 않다면, 일반적으로 기존 BBUB(3213)를 새로운 위치로 업데이트하는 것으로 충분하다. 또한, 호스트가 비트맵 레코드 기입 전후에 새로운 비트맵을 기입하는지를 알지 못하기 때문에 모든 비트를 설정하는 것이 적절할 수 있다(그 가능성은 그 후에 있지만, 발생한다면, 비트맵 기입이 들어옴에 따라 비트가 몇 초내의 제2 시간에 단지 무해하게 설정될 것이다).

위험은 기입이 발생한다면 그 전에 있는데, 이 경우, 기입은 서로 다른 위치에 있는 것에 기인하여 분실되었을 것이다; 모든 비트를 설정하게 되면 그 비트맵이 파싱된다는 것을 보장한다.

(예를 들면, 파티션의 재포맷에 기인한) 부트 섹터 업데이트의 경우에, 비트맵은 동일 크기이고 동일한 위치를 점유할 수 있어, 일반적으로 BLT(3212) 또는 BBUB(3213)로의 변경은 없을 것이다. 새로운 비트맵은 아마도 대부분의 블록이 모두 제로로되면서 재기입될 것이고, 따라서, 비동기식 작업(3214)은 CAT로부터 미할당 클러스터를 재사용하기 위해 그들 처리를 진행시킬 수 있어야 한다. 부트 섹터의 볼륨 시리얼 넘버를 체크하여 업데이트가 재포맷의 결과였는지를 결정한다.

비트맵 레코드는 또한 부트 섹터와는 독립적인 이유로 언제라도 업데이트될 수 있다. 스캐빈저(3210)는 진행 중에 크기를 변경하거나 이동하는 비트맵을 복제할 수 있어야 한다; 비트맵이 서로 다른 크기로 된 파티션을 생성하지 않고 크기를 변경할 수 있는지는 명확하지 않지만, 미래의 NTFS 버전은 무슨 이유에서든 그러한 것을 지원할 수 있다. 이 상황에서, 비트맵의 새로운 위치(들)는 일반적으로, 구 엔트리는 제거하고 새로운 것은 부가하면서, BLT(3212)로 프로그래밍되어야 한다. BBUB(3213)는 적절히 확대되거나 단축되어야 한다. 단축에 의해 자유로워진 임의의 LBA 범위에는, 엄격히는 그들이 여전히 파티션에 매핑됨에도 불구하고, DST(3215)에 부가될 수 있다.

또 다른 관심사는, 비트맵 레코드의 마지막 업데이트 필드의 시간이 빈번하게 수정되어 진행중인 비트맵의 수정을 반영한다면, 그 결과가 실질적인 인라인 파싱의 양이 될 것이라는 점이다.

비트맵 자체로의 모든 후속 기입은 BBUB(3213)를 거쳐 비동기식 작업(3214)으로 푸시된다.

여기에서 기본적인 전략은 모든 할당된 클러스터가 BBUB(3213) 또는 DST(3215)에 표현될 것이고, 어느 것이든, 할당되지 않은 것들은 재사용될 것이라는 것이다. 대체 솔루션은, 각각의 기입이 BBUM(3211)에 의해 볼륨에 매핑되고 CAT 관리자로 진행하기 전에 식별자로 태깅되도록 BBUM(3211)과 CAT에 모두 공지된, 각 볼륨에 대한 볼륨 식별자를 가져야 할 것이고, 여기에서 볼륨 식별자는 CAT 레코드에 저장될 것이다. 새로운 볼륨은 전형적으로 덮어쓰기하고 있는 구 볼륨으로부터 서로 다른 식별자를 얻고, 따라서, 비동기식 작업(3214)는 새로운 볼륨으로부터의 데이터로 덮어쓰기된 클러스터를 재사용하는 위험없이 구 볼륨 식별자로 레코드를 재사용할 수 있다. 분명하게도 이것은 CAT 레코드의 공간을 소모할 수 있다. 그것은 또한 재포맷의 기입 순서에도 의존한다. 시스템은 일반적으로 새로운 볼륨 시리얼 번호가 부트 파티션에 보일 때까지 새로운 볼륨에 관한 것을 알수 없기 때문에, 그 이전에 진행되는 볼륨으로의 임의의 다른 기입이 구 볼륨 식별자로 태깅될 것이다.

대다수의 작업은 명목상 1분을 분기하고(wake up), BBUB(3213)으로부터 몇몇 작업을 수집하고, 그것을 캐시를 통해 페이징-인(paging-in) 비트맵 블록에 의해 실행하고 비트를 CAT와 비교하는 전용 스캐빈저 작업(3214)에 의해 행해질 것이다. 예시적 실시예에서, BBUB(3213)는 각 세그먼트에 대한 카운터가 그 세그먼트에 대한 업데이트 수를 보여주면서 논리적으로 분할되고(1k 세그먼트 크기), 임의의 카운터에 의해 홀드되는 최고값을 반영하는 글로벌 카운터; 이들 카운터는 작업 생성자(BBUM(3211))에 의해 증분될 것이고 작업 소모자(스캐빈저 작업(3214))에 의해 감분될 것이다. 스캐빈저 작업(3214)은, 분기시에, 글로벌 카운터를 체크하고 그 안에 있는 값이 페이징-인 비트맵을 정당화하는데 충분히 높은지를 결정한다. 그렇다면, 작업(3214)은 그 값이 대응하는 세그먼트를 결정한 다음(예를 들면, 카운터 어레이를 반복함으로써), 적절한 BBUB 세그먼트의 비트를 통해 반복을 시작한다. 설정 비트를 찾는 때에는 비트맵의 브록을 페이징-인할 것이고 그것을 CAT와 비교한다.

전술한 바와 같이, 스캐빈저 작업(3214)의 동작은, 예를 들면, 실행하는 빈도수 또는 몇몇 작업을 행하도록 결정하는 임계값을 변경함으로써 유동적으로 조정될 수 있다. 그러나, 본 발명의 예시적 실시예에서, 그러한 유동적 조정은 일반적으로, 아키텍처는 스캐빈저가 실행되는 빈도수에 어느 정도 연결되기 때문에 행해지지 않는다. 특히, 제안된 아키텍처는 호스트 파일시스템(2711)이 최대 시간 윈도우(예를 들면, 1분) 내에 메타데이터를 업데이트한다고 가정하여 설계되었기 때문에, 제안된 아키텍처는 최대 시간 윈도우보다 더 빈번하게 스캐빈저 작업(3214)을 실질적으로 실행할 수 없다. 제안된 아키텍처는 규칙을 실질적으로 어기지 않고 보다 덜 빈번하게 실행할 수 있지만, 몇몇 클러스터 업데이트를 실제보다 더 최근인 것으로 보이게 함으로써 클러스터 재사용을 보다 덜 효율적으로 할 수 있다(예를 들면, 실행이 매분마다 발생하지만, 그들은 실제로, 말하자면, 매 3분마다 발생한다고 가정하여 시기 계산이 설계된다면, 시기 계산은 3의 인자만큼 오프될 것이다). 또한, 작업 우선순위는 일반적으로 컴파일 시간에 고정되고 따라서 일반적으로 시스템 동작 동안 변경되지 않는다.

본 발명의 예시적 실시예에서, 저장 시스템은 크기 4K인 클러스터를 구현한다는 것을 유의하자. 따라서, 파일시스템이 4K와는 다른 크기의 클러스터로 포맷된다면, 파일시스템 비트맵의 비트는 저장 시스템에 있는 클러스와 깔끔하게 상관되지 않을 수 있다. 예를 들면, 파일시스템 클러스터 크기가 4K보다 작으면, 비트맵의 다수의 비트가 일반적으로 클리어되어야 함으로써 CAT와의 상호참조를 번거롭게할 것이다. 그러나, 파일시스템 클러스터 크기가 4K보다 크면, 비트맵의 하나의 클리어 비트는 일반적으로 각각의 4K에 대하여 하나씩 CAT로의 다수의 룩업을 필요로 할 것이다.

또 다른 관심사는 재사용하기에 너무 미숙한 클러스터와 만나는 상황을 어떻게 조정하느냐 하는 것이다. 그러한 상황에서, 스캐빈저는 BBUB에 설정된 비트를 남겨둠으로써, 전체 512 비트를 다시 파싱하기 위해 하나 이상의 후속 스캔을 요구할 수 있다(예를 들면, 다음 스캔은 클러스터가 재사용하기에는 여전히 미숙하다는 것을 단지 발견하기 위해 512 비트를 진행할 수 있다). 대안으로, 스캐빈저는 비트를 클리어하고 클러스터에 재체크에 필요한 미숙한 블록/비트오프셋의 리스트를 부가할 수 있다. 구현의 관점에서, 후자의 접근법은 리스트가 완전히 작게 유지될 수 있다면 실용적일 수 있다.

구현의 관점에, 스캐빈저와 BBUB는 CAT 관리자를 통해 디스크로부터 모두 판독할 것이다. 클러스터 재사용은 CAT 관리자에 의해 제공되는 특별한 API를 통해 수행될 것이다.

가상 핫 스페어(VIRTURE HOT SPARE)

위에서 논의된 바와 같이, 많은 저장 시스템들에서, 가상 핫 스페어는 다른 저장 디바이스가 고장난 경우에 신속히 온라인으로 될 수 있도록 준비 상태로 유지될 것이다. 본 발명의 특정 실시예들에서는, 물리적으로 별도의 핫 스페어를 유지하는 것이 아니라, 복수의 저장 디바이스들에 걸쳐서 미사용 저장 용량으로부터 가상 핫 스페어가 생성된다. 물리적 핫 스페어와 달리, 이 미사용 저장 용량은 한 저장 디바이스가 나머지 저장 디바이스(들)로부터 복구된 데이터의 저장에 실패하는 경우에 이용 가능하다.

가상 핫 스페어 특징은 디스크 고장의 경우에 데이터가 리던던트하게 재배치될 수 있도록 어레이 상에 충분한 공간이 이용 가능할 것을 요구한다. 따라서, 진행중 체제로(on a ongoing basis), 저장 시스템은 전형적으로 가상 핫 스페어의 구현을 위해 요구될 미사용 저장 용량을 결정하고(예컨대, 저장 디바이스의 수, 각종 저장 디바이스들의 용량, 저장된 데이터의 양, 및 데이터가 저장되는 방식에 기초하여) 가상 핫 스페어를 위해 추가 저장 용량이 필요하다면 신호를 생성한다(예컨대, 위에서 설명된 바와 같이 사실상, 상태 및 슬롯을 지시하기 위해 녹색/황색/적색 라이트들을 이용하여). 존들이 할당될 때, 디스크마다 그 존을 재배치하기 위해 얼마나 많은 영역들이 요구되는지에 대한 레코드가 유지된다. 다음 표는 4개의 드라이브가 이용될 때의 가상 핫 스페어를 설명한다:

존	타입	디스크 상의 저장	설명(Comments)	디스크가 고장나면 요구되는 영역들
존	타입	디스크 상의 저장	설명(Comments)	디스크 0	디스크 1	디스크 2	디스크 3
2	2중 드라이브 미러	0,1	0 또는 1이 고장나면 디스크 2 또는 3에 재구성	12	12	0	0
3	2중 드라이브 미러	0,3	1 또는 2가 고장나면 디스크 1 또는 2에 재구성	12	0	0	12
5	3중 드라이브 스트라이프	1,2,3	1, 2, 또는 3이 고장나면 디스크 0에 재구성	0	6	6	6
10	4중 드라이브 스트라이프	0,1,2,3	다른 3개의 드라이브에 걸쳐서 3중 드라이브 스트라이프로 변환	2,2,2	2,2,2	2,2,2	2,2,2

다음 표는 3개의 드라이브가 이용될 때의 가상 핫 스페어를 설명한다.

존	타입	디스크 상의 저장	설명	디스크가 고장나면 요구되는 영역들
존	타입	디스크 상의 저장	설명	디스크 0	디스크 1	디스크 2
2	2중 드라이브 미러	0,1	디스크 3에 재구성	12	12	0
3	2중 드라이브 미러	0,3	디스크 1에 재구성	12	0	12
5	3중 드라이브 스트라이프	1,2,3	2중 드라이브 미러로 변환	6,6	6,6	6,6

이 예시적 실시예에서, 가상 핫 스페어는 단지 1개 또는 2개 드라이브를 갖는 어레이에서는 이용 가능하지 않다. 어레이 내의 디스크들의 수 및 각 존에 대한 정보에 기초하여, 어레이는 각각의 가능한 디스크 고장에 대한 재배치 시나리오를 결정하고 각 시나리오에 대하여 각 드라이브에서 충분한 공간이 이용 가능하도록 한다. 생성된 정보는, 데이터가 데이터 저장과 핫 스페어 특징 사이에 정확히 균형이 잡힐 수 있도록 재배치 엔진 및 존 관리자에 피드백될 수 있다. 핫 스페어 특징은 재배치가 일어날 수 있도록 존 레이아웃 데이터로부터 계산된 영역들 외에 충분한 스페어 작업 공간 영역들을 필요로 한다는 것에 유의하자.

도 22는 본 발명의 예시적인 실시예에 따른 가상 핫 스페어를 관리하기 위한 예시적인 논리를 보여주는 논리 흐름도이다. 블록 2102에서, 논리는 각각의 가능한 디스크 고장에 대한 재배치 시나리오를 결정한다. 블록 2104에서, 논리는 최악의 경우 시나리오에서 리던던트하게 데이터를 재배치하기 위해 각 드라이브에서 요구되는 공간의 양을 결정한다. 블록 2106에서, 논리는 최악의 경우 시나리오에서 리던던트하게 데이터를 재배치하기 위해 요구되는 스페어 작업 공간 영역들의 양을 결정한다. 블록 2108에서, 논리는 최악의 경우 시나리오에서 리던던트하게 데이터를 재배치하는 것을 허용하기 위하여 각 드라이브에서 요구되는 공간의 총량을 결정한다(본질적으로 재배치를 위해 요구되는 공간의 양과 요구되는 스페어 작업 공간 영역들의 양의 합). 블록 2110에서, 논리는 저장 시스템이 충분한 양의 이용 가능한 저장을 포함하는지를 결정한다. 만일 충분한 양의 이용 가능한 저장이 있다면(블록 2112에서 '예'), 논리 반복은 블록 2199에서 종료한다. 그러나, 불충분한 양의 이용 가능한 저장이 있다면(블록 2112에서 '아니오'), 논리는 블록 2114에서 어느 드라이브/슬롯이 업그레이드를 필요로 하는지를 결정한다. 그 후, 블록 2116에서, 논리는 추가 저장 공간이 요구된다는 것을 신호하고 어느 드라이브/슬롯이 업그레이드를 필요로 하는지를 지시한다. 논리 반복은 블록 2199에서 종료한다.

도 23은 본 발명의 예시적인 실시예에 따른, 도 22의 블록 2102에서와 같이, 각각의 가능한 디스크 고장에 대한 재배치 시나리오를 결정하기 위한 예시적인 논리를 보여주는 논리 흐름도이다. 블록 2202에서, 논리는 존을 할당한다. 그 후, 블록 2204에서, 논리는 디스크마다 해당 존을 재배치하기 위해 얼마나 많은 영역들이 요구되는지를 결정한다. 논리 반복은 블록 2299에서 종료한다.

도 24는 본 발명의 예시적인 실시예에 따른 가상 핫 스페어 기능을 호출(invoke)하기 위한 예시적인 논리를 보여주는 논리 흐름도이다. 블록 2302에서, 논리는 최악의 경우 시나리오의 경우에 리던던트하게 데이터를 재배치하는 것을 허용하기 위해 충분한 양의 이용 가능한 저장을 유지한다. 블록 2304에서, 드라이브의 분실(예컨대, 제거 또는 고장)이 결정되면, 논리는 블록 2306에서 데이터에 대한 내장애성을 복원하기 위해 하나 이상의 남아 있는 드라이브들을 자동으로 재구성한다. 논리 반복은 블록 2399에서 종료한다.

도 25는 본 발명의 예시적인 실시예에 따른, 도 24의 블록 2306에서와 같이, 데이터의 내장애성을 복원하기 위해 하나 이상의 남아 있는 드라이브들을 자동으로 재구성하기 위한 예시적인 논리를 보여주는 논리 흐름도이다. 블록 2402에서, 논리는 4개 이상의 저장 디바이스들에 걸쳐 있는 제1 스트라이프 패턴(striped pattern)을 3개 이상의 남아 있는 저장 디바이스들에 걸쳐 있는 제2 스트라이프 패턴으로 변환할 수 있다. 블록 2404에서, 논리는 3개의 저장 디바이스들에 걸쳐 있는 스트라이프 패턴을 2개의 남아 있는 저장 디바이스들에 걸쳐 있는 미러 패턴(mirrored pattern)으로 변환할 수 있다. 물론, 논리는 드라이브의 분실에 이어서 리던던트하게 데이터를 재배치하기 위하여 다른 방식으로 패턴들을 변환할 수도 있다. 논리 반복은 블록 2499에서 종료한다.

다시 도 21을 참조하여, 저장 관리자(2504)는 전형적으로 상술한 바와 같이 가상 핫 스페어 기능을 구현하기 위한 적당한 컴포넌트들 및 논리를 포함한다.

동적인 업그레이드

저장의 동적인 확장 및 수축을 핸들링하기 위해 위에서 설명된 논리는 동적으로 업그레이드 가능한 저장 시스템을 제공하도록 확장될 수 있고, 이 동적으로 업그레이드 가능한 저장 시스템에서는 저장 디바이스들이 필요에 따라 더 큰 저장 디바이스들로 교체될 수 있고, 기존의 데이터는 리던던시가 유지되거나 향상되는 방식으로 저장 디바이스들에 걸쳐서 자동으로 재구성될 수 있고 더 큰 저장 디바이스들에 의해 제공된 추가 저장 공간은 복수의 저장 디바이스들에 걸쳐서 이용 가능한 저장 공간의 풀에 포함될 것이다. 따라서, 작은 저장 디바이스가 더 큰 저장 디바이스로 교체될 때, 추가 저장 공간은 이미 저장된 데이터에 대한 리던던시를 향상시킬 뿐만 아니라 추가 데이터를 저장하는 데 이용될 수 있다. 더 많은 저장 공간이 요구될 때마다, 적절한 신호가 사용자에게 제공되고(예컨대, 위에서 설명된 바와 같이 사실상 녹색/황색/적색 라이트들을 이용하여), 사용자는 단순히 저장 디바이스를 제거하고 그것을 더 큰 저장 디바이스로 교체할 수 있다.

도 26은 본 발명의 예시적인 실시예에 따른, 저장 디바이스를 업데이트하기 위한 예시적인 논리를 보여주는 논리 흐름도이다. 블록 2602에서, 논리는 제1 저장 디바이스에 저장된 데이터가 다른 저장 디바이스들에서 리던던트하게 보이도록 제1 저장 디바이스에 데이터를 저장한다. 블록 2604에서, 논리는 제1 저장 디바이스보다 더 큰 저장 용량을 갖는 교체 디바이스로의 제1 저장 디바이스의 교체를 검출한다. 블록 2606에서, 논리는 제1 디바이스에 저장되었던 데이터를 다른 디바이스들에 리던던트하게 저장된 데이터를 이용하여 교체 디바이스 상에 자동으로 복사(reproduce)한다. 블록 2608에서, 논리는 교체 디바이스 상의 추가 저장 공간을 새로운 데이터를 리던던트하게 저장하는 데 이용 가능하게 한다. 블록 2610에서, 논리는 새로운 데이터에 대한 리던던시를 제공하기 위해 충분한 양의 이용 가능한 저장 용량을 갖고 있는 다른 디바이스가 없다면 교체 디바이스 상의 추가 저장 공간 내에 리던던트하게 새로운 데이터를 저장할 수 있다. 블록 2612에서, 논리는 적어도 하나의 다른 디바이스가 새로운 데이터에 대한 리던던시를 제공하기 위해 충분한 양의 이용 가능한 저장 용량을 갖고 있다면 다수의 저장 디바이스들에 걸쳐서 리던던트하게 새로운 데이터를 저장할 수 있다.

다시 도 21을 참조하여, 저장 관리자(2504)는 전형적으로 상술한 바와 같이 동적인 업그레이드 기능을 구현하기 위한 적당한 컴포넌트들 및 논리를 포함한다.

기타

본 발명의 실시예들은 Geoffrey S. Barrall의 명의로 2004년 11월 5일에 출원되었고, 그 전체 내용이 본 명세서에 참조로 통합되는 미국 가 특허 출원 60/625,469호에 기술된 방식으로, 예컨대, 주변 접속 프로토콜을 이용하여 호스트 컴퓨터에 저장 용량을 제공하기 위해 이용될 수 있다.

해시 알고리듬은 엄격히 유일한 해시 값들을 생성하지 않을 수도 있다는 것에 유의해야 할 것이다. 따라서, 해시 알고리듬이 동일하지 않은 콘텐츠를 갖는 2개의 데이터 청크들에 대하여 동일한 해시 값을 생성하는 것을 생각할 수 있다. 해시 함수(일반적으로 해시 알고리듬을 통합함)는 전형적으로 유일성(uniqueness)을 확인하기 위한 메커니즘을 포함한다. 예를 들면, 위에서 설명된 발명의 예시적 실시예에서, 하나의 청크에 대한 해시 값이 다른 청크의 해시 값과 다르다면, 이들 청크들의 콘텐츠는 동일하지 않은 것으로 간주된다. 그러나, 만일 하나의 청크에 대한 해시 값이 다른 청크의 해시 값과 동일하다면, 해시 함수는 2개의 청크들의 콘텐츠를 비교하거나 또는 어떤 다른 메커니즘(예컨대, 상이한 해시 함수)을 이용하여 그 콘텐츠가 동일한지 동일하지 않은지를 결정할 수 있다.

본 명세서에서 논리 흐름도들은 발명의 각종 양태들을 설명하기 위해 사용되고 있고, 본 발명을 임의의 특정 논리 흐름 또는 논리 구현으로 제한하도록 해석되어서는 안 된다는 것에 유의해야 할 것이다. 설명된 논리는 전체 결과를 변경하거나 또는 다른 방법으로 본 발명의 진정한 범위에서 벗어나지 않고 상이한 논리 블록들(예컨대, 프로그램, 모듈, 함수, 또는 서브루틴들)로 분할될 수도 있다. 종종, 전체 결과를 변경하거나 또는 다른 방법으로 본 발명의 진정한 범위에서 벗어나지 않고 논리 소자들이 추가되거나, 변경되거나, 생략되거나, 상이한 순서로 수행되거나, 상이한 논리 구성들(예컨대, 논리 게이트, 루핑 프리미티브, 조건부 논리, 및 다른 논리 구성들)을 이용하여 구현될 수도 있다.

본 발명은 프로세서(예컨대, 마이크로프로세서, 마이크로컨트롤러, 디지털 신호 프로세서, 또는 범용 컴퓨터)와 함께 이용되는 컴퓨터 프로그램 논리, 프로그램 가능한 논리 디바이스(예컨대, FPGA(Field Programmable Gate Array) 또는 다른 PLD)와 함께 이용되는 프로그램 가능한 논리, 이산(discrete) 컴포넌트들, 집적 회로(예컨대, ASIC(Application Specific Integrated Circuit)), 또는 그것들의 임의의 조합을 포함하는 임의의 다른 수단을 포함하지만 결코 이들에 제한되지 않는 다수의 상이한 형태들로 구현될 수 있다.

본 명세서에서 앞에서 설명된 기능의 전부 또는 일부를 구현하는 컴퓨터 프로그램 논리는, 소스 코드 형태, 컴퓨터 실행 가능 형태, 및 각종 중간 형태(예컨대, 어셈블러, 컴파일러, 링커, 또는 로케이터에 의해 생성된 형태들)를 포함하지만 결코 이들에 제한되지 않는 다양한 형태들로 구현될 수 있다. 소스 코드는 각종 운영 시스템 또는 운영 환경과 함께 이용되는 각종 프로그램 언어들(예컨대, 오브젝트 코드, 어셈블리 언어, 또는 포트란(Fortran), C, C++, 자바(JAVA), 또는 HTML) 중의 임의의 프로그램 언어로 구현된 일련의 컴퓨터 프로그램 명령들을 포함할 수 있다. 소스 코드는 각종 데이터 구조 및 통신 메시지를 정의 및 사용할 수 있다. 소스 코드는 컴퓨터 실행 가능 형태로 되어 있을 수도 있고(예컨대, 인터프리터를 통하여), 또는 소스 코드는 컴퓨터 실행 가능 형태로 변환될 수도 있다(예컨대, 번역기(translator), 어셈블러, 또는 컴파일러를 통하여).

컴퓨터 프로그램은 반도체 메모리 디바이스(예컨대, RAM, ROM, PROM, EEPROM, 또는 플래시-프로그래머블 RAM), 자기 메모리 디바이스(예컨대, 디스켓 또는 고정된 디스크), 또는 광학 메모리 디바이스(예컨대, CD-ROM), PC 카드(예컨대, PCMCIA 카드), 또는 다른 메모리 디바이스와 같은 실체적인 저장 매체에 영구적으로 또는 일시적으로 임의의 형태(예컨대, 소스 코드 형태, 컴퓨터 실행 가능 형태, 또는 중간 형태)로 고정될 수 있다. 컴퓨터 프로그램은 아날로그 기술, 디지털 기술, 광학 기술, 무선 기술(예컨대, 블루투스), 네트워킹 기술, 및 인터네트워킹 기술을 포함하지만 결코 이들에 제한되지 않는 각종의 통신 기술들 중 임의의 통신 기술을 이용하여 컴퓨터에 전송 가능한 신호에 임의의 형태로 고정될 수 있다. 컴퓨터 프로그램은 동반하는 인쇄 또는 전자 문서와 함께 이동 가능한 저장 매체로서 임의의 형태로 배포되거나(예컨대, 수축 포장된(shrinked wrapped) 소프트웨어), 컴퓨터 시스템에 사전 로딩(preloaded)되거나(예컨대, 시스템 ROM 또는 고정된 디스크 상에), 또는 통신 시스템을 통하여 서버 또는 전자 게시판으로부터 배포될 수도 있다(예컨대, 인터넷 또는 월드 와이드 웹).

본 명세서에서 앞에서 설명된 기능의 전부 또는 일부를 구현하는 하드웨어 논리(프로그램 가능한 논리 디바이스와 함께 이용되는 프로그램 가능한 논리를 포함함)는 전통적인 수동식 방법을 이용하여 설계될 수도 있고, 또는 CAD(Computer Aided Design), 하드웨어 기술 언어(예컨대, VHDL 또는 AHDL), 또는 PLD 프로그래밍 언어(예컨대, PALASM, ABEL, 또는 CUPL)와 같은 각종 도구를 이용하여 전자적으로 설계, 캡처, 시뮬레이트, 또는 문서화될 수도 있다.

프로그램 가능한 논리는 반도체 메모리 디바이스(예컨대, RAM, ROM, PROM, EEPROM, 또는 플래시-프로그래머블 RAM), 자기 메모리 디바이스(예컨대, 디스켓 또는 고정된 디스크), 또는 광학 메모리 디바이스(예컨대, CD-ROM), 또는 다른 메모리 디바이스와 같은 실체적인 저장 매체에 영구적으로 또는 일시적으로 고정될 수 있다. 프로그램 가능한 논리는 아날로그 기술, 디지털 기술, 광학 기술, 무선 기술(예컨대, 블루투스), 네트워킹 기술, 및 인터네트워킹 기술을 포함하지만 결코 이들에 제한되지 않는 각종의 통신 기술들 중 임의의 통신 기술을 이용하여 컴퓨터에 전송 가능한 신호에 고정될 수 있다. 프로그램 가능한 논리는 동반하는 인쇄 또는 전자 문서와 함께 이동 가능한 저장 매체로서 배포되거나(예컨대, 수축 포장된 소프트웨어), 컴퓨터 시스템에 사전 로딩되거나(예컨대, 시스템 ROM 또는 고정된 디스크 상에), 또는 통신 시스템을 통하여 서버 또는 전자 게시판으로부터 배포될 수도 있다(예컨대, 인터넷 또는 월드 와이드 웹).

본 출원은 다음의 미국 특허 출원들에 관련되어 있는데, 그 전체 내용이 본 명세서에 참조로 통합된다:

대리인 사건 번호 2950/104, 발명의 명칭 Dynamically Upgradeable Fault-Tolerant Storage System Permitting Variously Sized Storage Devices and Method;

대리인 사건 번호 2950/105, 발명의 명칭 Dynamically Expandable and Contractible Fault-Tolerant Storage System With Virtual Hot Spare; 및

대리인 사건 번호 2950/107, 발명의 명칭 Storage System Condition Indicator and Method.

본 발명은 발명의 진정한 범위에서 벗어나지 않고 다른 특정 형태로 구현될 수 있다. 설명된 실시예들은 모든 점에서 제한적인 것이 아니라 단지 예시적인 것으로서 간주되어야 할 것이다.

Claims

호스트 파일시스템의 제어 하에 데이터를 저장하고, 상기 호스트 파일시스템과는 독립적으로 실행되는 스토리지 컨트롤러를 포함하는 블록-레벨 스토리지 시스템에 의해 데이터 스토리지를 관리하는 방법으로서,

상기 스토리지 컨트롤러에 의해, 상기 블록-레벨 스토리지 시스템에서 상기 호스트 파일시스템을 위해 저장된 호스트 파일시스템 데이터 구조를 찾는 단계;

상기 스토리지 컨트롤러에 의해, 상기 호스트 파일시스템의 스토리지 용도를 결정하기 위해 상기 호스트 파일시스템 데이터 구조를 분석하는 단계; 및

상기 스토리지 컨트롤러에 의해, 상기 호스트 파일시스템의 스토리지 용도에 기초하여 상기 블록-레벨 스토리지 시스템에서의 스토리지를 관리하는 단계

를 포함하는 데이터 스토리지 관리 방법.
제1항에 있어서,

상기 호스트 파일시스템 데이터 구조를 분석하는 단계는 상기 호스트 파일시스템 데이터 구조를 분석하여 상기 호스트 파일시스템에 의해 릴리스된(released) 블록들을 식별하는 단계를 포함하고, 상기 블록-레벨 스토리지 시스템에서의 스토리지를 관리하는 단계는 상기 호스트 파일시스템에 의해 릴리스된 블록들을 재사용하는 단계를 포함하는 데이터 스토리지 관리 방법.
제2항에 있어서,

상기 호스트 파일시스템에 의해 릴리스된 블록들을 재사용하는 단계는, 상기 호스트 파일시스템에 의해서는 사용되지 않는 것으로 마킹되지만 상기 블록-레벨 스토리지 시스템 내에서는 사용되는 것으로 마킹되는 블록들을 식별하는 단계; 그러한 블록들을 재사용하는 단계; 및 부가의 스토리지를 위해 그러한 블록들을 이용가능하게 하는 단계를 포함하는 데이터 스토리지 관리 방법.
제1항에 있어서,

상기 호스트 파일시스템 데이터 구조를 분석하는 단계는 상기 호스트 파일시스템 데이터 구조를 분석하여 저장될 데이터와 관계된 데이터 유형을 식별하는 단계를 포함하고, 상기 블록-레벨 스토리지 시스템에서의 스토리지를 관리하는 단계는 상기 데이터 유형을 기초로 선택되는 저장 기법을 사용하여 그러한 데이터를 저장하는 단계를 포함하고, 이에 의해 서로 다른 데이터 유형을 갖는 데이터는 상기 데이터 유형을 기초로 선택되는 서로 다른 저장 기법을 사용하여 저장될 수 있는 데이터 스토리지 관리 방법.
제4항에 있어서,

상기 데이터 유형을 기초로 선택되는 저장 기법을 사용하여 상기 데이터를 저장하는 단계는, 상기 데이터 유형을 기초로 선택되는 저장 레이아웃을 사용하여 상기 데이터를 저장하는 단계를 포함하는 데이터 스토리지 관리 방법.
제5항에 있어서,

상기 데이터 유형을 기초로 선택되는 저장 레이아웃을 사용하여 상기 데이터를 저장하는 단계는, 빈번하게 액세스되는 데이터를 저장하는 단계를 포함하는 데이터 스토리지 관리 방법.
제6항에 있어서,

상기 빈번하게 액세스되는 데이터를 저장하는 단계는, 상기 빈번하게 액세스되는 데이터를 압축하지 않고 순차 저장으로 저장하는 단계를 포함하는 데이터 스토리지 관리 방법.
제5항에 있어서,

상기 데이터 유형을 기초로 선택되는 저장 레이아웃을 사용하여 상기 데이터를 저장하는 단계는, 빈번하지 않게 액세스되는 데이터를 저장하는 단계를 포함하는 데이터 스토리지 관리 방법.
제8항에 있어서,

상기 빈번하지 않게 액세스되는 데이터를 저장하는 단계는, 데이터 압축 및 비순차 저장 중 적어도 하나를 사용하여 상기 빈번하지 않게 액세스되는 데이터를 저장하는 단계를 포함하는 데이터 스토리지 관리 방법.
제4항에 있어서,

상기 데이터 유형을 기초로 선택되는 저장 기법을 사용하여 상기 데이터를 저장하는 단계는, 상기 데이터 유형을 기초로 선택되는 인코딩 기법을 사용하여 상기 데이터를 저장하는 단계를 포함하는 데이터 스토리지 관리 방법.
제10항에 있어서,

상기 인코딩 기법은 데이터 압축 및 암호화 중 적어도 하나를 포함하는 데이터 스토리지 관리 방법.
제1항에 있어서,

스토리지에서 호스트 파일시스템 데이터 구조를 찾는 단계는,

파티션 테이블을 유지하는 단계;

오퍼레이팅 시스템 파티션을 찾기 위해 상기 파티션 테이블을 파싱하는 단계;

오퍼레이팅 시스템을 식별하고 오퍼레이팅 시스템 데이터 구조를 찾기 위해, 상기 오퍼레이팅 시스템 파티션을 파싱하는 단계; 및

상기 호스트 파일시스템을 식별하고 상기 호스트 파일시스템 데이터 구조를 찾기 위해 상기 오퍼레이팅 시스템 데이터 구조를 파싱하는 단계

를 포함하는 데이터 스토리지 관리 방법.
제12항에 있어서,

상기 오퍼레이팅 시스템 데이터 구조는 수퍼블록을 포함하고, 상기 오퍼레이팅 시스템 데이터 구조를 파싱하는 단계는 상기 수퍼블록을 파싱하는 단계를 포함하는 데이터 스토리지 관리 방법.
제12항에 있어서,

상기 호스트 파일시스템 데이터 구조를 파싱하는 단계는,

호스트 파일시스템 데이터 구조의 작업 사본을 작성하는 단계; 및

상기 작업 사본을 파싱하는 단계

를 포함하는 데이터 스토리지 관리 방법.
호스트 파일시스템의 제어 하에 데이터를 저장하는 블록-레벨 스토리지 시스템으로서,

상기 호스트 파일시스템을 위해 호스트 파일시스템 데이터 구조가 저장되는 블록-레벨 스토리지; 및

상기 호스트 파일시스템과는 독립적으로 실행되는 스토리지 컨트롤러 - 상기 스토리지 컨트롤러는, 상기 블록-레벨 스토리지에 저장된 상기 호스트 파일시스템 데이터 구조를 찾고, 상기 호스트 파일시스템 데이터 구조를 분석하여 상기 호스트 파일시스템의 스토리지 용도를 결정하며, 상기 호스트 파일시스템의 스토리지 용도에 기초하여 상기 블록-레벨 스토리지를 관리하기 위해, 상기 블록-레벨 스토리지에 동작상 접속됨 -

를 포함하는 블록-레벨 스토리지 시스템.
제15항에 있어서,

상기 스토리지 컨트롤러는, 상기 호스트 파일시스템에 의해 릴리스된 블록들을 식별하고 상기 호스트 파일시스템에 의해 릴리스된 상기 블록들을 재사용하도록 동작상 접속되어 있는 블록-레벨 스토리지 시스템.
제16항에 있어서,

상기 스토리지 컨트롤러는, 상기 호스트 파일시스템에 의해서는 사용되지 않는 것으로 마킹되지만 상기 블록-레벨 스토리지 시스템 내에서는 사용되는 것으로 마킹되는 블록들을 식별하고, 그러한 블록들을 재사용하며, 부가의 스토리지를 위해 그러한 블록들을 이용가능하게 하도록 동작상 접속되어 있는 블록-레벨 스토리지 시스템.
제15항에 있어서,

상기 스토리지 컨트롤러는, 저장될 데이터와 관계된 데이터 유형을 식별하고 상기 데이터 유형을 기초로 선택되는 저장 기법을 사용하여 상기 데이터를 저장함으로써, 서로 다른 데이터 유형을 갖는 데이터가, 상기 데이터 유형을 기초로 선택되는 서로 다른 저장 기법을 사용하여 저장될 수 있도록 동작상 접속되어 있는 블록-레벨 스토리지 시스템.
제18항에 있어서,

상기 스토리지 컨트롤러는 상기 데이터 유형을 기초로 선택되는 저장 레이아웃을 사용하여 상기 데이터를 저장하도록 동작상 접속되어 있는 블록-레벨 스토리지 시스템.
제19항에 있어서,

상기 스토리지 컨트롤러는 빈번하게 액세스되는 데이터를 저장하도록 동작상 접속되어 있는 블록-레벨 스토리지 시스템.
제20항에 있어서,

상기 스토리지 컨트롤러는 빈번하게 액세스되는 데이터를 압축하지 않고 순차 저장으로 저장하도록 동작상 접속되어 있는 블록-레벨 스토리지 시스템.
제19항에 있어서,

상기 스토리지 컨트롤러는 빈번하지 않게 액세스되는 데이터를 저장하도록 동작상 접속되어 있는 블록-레벨 스토리지 시스템.
제22항에 있어서,

상기 스토리지 컨트롤러는 빈번하지 않게 액세스되는 데이터를 데이터 압축 및 비순차 저장 중 적어도 하나를 사용하여 저장하도록 동작상 접속되어 있는 블록-레벨 스토리지 시스템.
제18항에 있어서,

상기 스토리지 컨트롤러는 상기 데이터 유형을 기초로 선택되는 인코딩 기법을 사용하여 상기 데이터를 저장하도록 동작상 접속되어 있는 블록-레벨 스토리지 시스템.
제24항에 있어서,

상기 인코딩 기법은 데이터 압축 및 암호화 중 적어도 하나를 포함하는 블록-레벨 스토리지 시스템.
제15항에 있어서,

상기 스토리지 컨트롤러는, 파티션 테이블을 유지하고, 상기 파티션 테이블을 파싱하여 오퍼레이팅 시스템 파티션을 찾고, 상기 오퍼레이팅 시스템 파티션을 파싱하여 오퍼레이팅 시스템을 식별하고 오퍼레이팅 시스템 데이터 구조를 찾고, 상기 오퍼레이팅 시스템 데이터 구조를 파싱하여 상기 호스트 파일시스템을 식별하고 상기 호스트 파일시스템 데이터 구조를 찾고, 상기 호스트 파일시스템 데이터 구조를 파싱하여 데이터 유형을 식별하도록 동작상 접속되어 있는 블록-레벨 스토리지 시스템.
제26항에 있어서,

상기 오퍼레이팅 시스템 데이터 구조는 수퍼블록을 포함하고, 상기 스토리지 컨트롤러는 상기 수퍼블록을 파싱하도록 동작상 접속되어 있는 블록-레벨 스토리지 시스템.
제26항에 있어서,

상기 스토리지 컨트롤러는, 호스트 파일시스템 데이터 구조의 작업 사본을 작성하고 상기 작업 사본을 파싱하도록 동작상 접속되어 있는 블록-레벨 스토리지 시스템.