KR101137081B1 - 실시간 파일 시스템 수리 - Google Patents
실시간 파일 시스템 수리 Download PDFInfo
- Publication number
- KR101137081B1 KR101137081B1 KR1020050027129A KR20050027129A KR101137081B1 KR 101137081 B1 KR101137081 B1 KR 101137081B1 KR 1020050027129 A KR1020050027129 A KR 1020050027129A KR 20050027129 A KR20050027129 A KR 20050027129A KR 101137081 B1 KR101137081 B1 KR 101137081B1
- Authority
- KR
- South Korea
- Prior art keywords
- repair
- scan
- file
- file system
- damage
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0727—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a storage system, e.g. in a DASD or network based storage system
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11C—STATIC STORES
- G11C29/00—Checking stores for correct operation ; Subsequent repair; Testing stores during standby or offline operation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1435—Saving, restoring, recovering or retrying at system level using file system or storage system metadata
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Debugging And Monitoring (AREA)
Abstract
파일 시스템은 온-디스크(on-disk) 데이터의 탐지된 손상의 실시간 교정을 하게 한다. 한 파일 시스템의 개선점은 실행중의 볼륨에서 탐지된 파일 시스템 손상에 실시간으로 응답하고, 파일 시스템이 그들을 탐지한 지점에서 손상들을 교정한다. 파일 시스템에 의한 손상의 탐지 시에, 시스템의 개선점은 손상의 성격을 서술하는 정보를 기록한다. 수리 스캔은 직면되는 각각의 유형의 손상에 대해 정의된다. 수리 스캔은 손상이 탐지된 현재 스레드 실행의 최상위 레벨에서 실행될 수 있거나, 그들은 수리 동작을 서비스하기 위해 전용 스레드를 요구할 것이다.
실시간 파일 시스템 수리
Description
도 1은 실행 볼륨에서 탐지되는 손상들의 실시간 및 온라인 수리를 제공하는 개선된 파일 시스템을 구현하기에 적합한 컴퓨팅 환경의 예.
도 2는 실행 볼륨에서 탐지되는 손상들의 실시간 및 온라인 수리를 제공하는 개선된 파일 시스템을 구현하기 위해 구성되는 컴퓨터 구현의 예.
도 3 내지 도 5는 실행 볼륨에서 탐지되는 손상들의 실시간 및 온라인 수리를 제공하는 개선된 파일 시스템을 구현하는 방법들의 예를 도시하는 흐름도.
<주요 도면 부호 설명>
200 프로세서(들)
202 운영 시스템
204 응용 프로그램들
206 메모리
208 파일 시스템
210 하드 디스크(볼륨)
212 실시간 수리 모듈
본원은 2004년 4월 30일 출원된 미국 가출원 번호 60/566,662의 우선권을 주장한다.
본 발명은 일반적으로 파일 시스템에 관한 것이고, 더 구체적으로는, 실행 볼륨에서 탐지된 손상들의 실시간 교정을 지원하는 파일 시스템에 관한 것이다.
컴퓨터의 파일 시스템은 데이터 파일들이 컴퓨터의 저장 볼륨(예를 들어, 하드 디스크)에 저장되는 방식, 및 파일들이 그 볼륨으로부터 검색되는 방법을 명시한다. 예를 들어, 윈도우즈, OS/2, 매킨토시, 및 UNIX-기반 운영 시스템은 파일들을 관리하기 위한 계층적(hierarchical)이나 트리(tree) 구조를 이용하는 파일 시스템들을 갖는다. 파일 시스템들은 또한 얼마나 많은 문자들을 파일 이름에 사용할 수 있는지, 어떤 문자들이 파일 이름에 사용될 수 있는지, 및 얼마나 많은 문자들이 파일 이름의 확장자에 허용되는지 등의 파일 명명의 규정을 명시한다.
"파일 시스템"이라는 용어는 종종 파일 시스템 구조, 규정들(convetions), 및 관련 작업들을 관리하는 파일 시스템 드라이버, 프로그램, 또는 운영 시스템의 일부를 가르키는 것으로 사용된다. 그러므로, 파일 시스템은 다른 사용자/응용 프로그램 요구들에 응답하여 파일들을 열고, 판독하고, 기록하고, 재명명하고, 닫는 등의 파일 동작들을 수행한다. 파일 시스템 트랜잭션을 관리하는 중요 양태 중 하나가 파일 시스템 내에서 내부 무결성(integrity)을 유지하는 것이다. 일반적으로, 파일 시스템은 하드 디스크(즉, 저장 볼륨)의 데이터 구조들이 일관적 이고 일반 파일 시스템 포맷을 유지하도록 기대한다. 예를 들어, 데이터가 특정 포맷으로 디스크에 기록되면, 파일 시스템은 데이터가 동일 포맷으로 디스크로부터 다시 판독될 수 있어야 함을 기대한다. 그러나, 디스크의 데이터 손상을 일으킬 수 있는 다양한 상황들이 있다. 디스크(즉, 물리적 저장 매체)의 문제는, 예를 들어, 데이터 비트들을 유실하는 결과를 가져올 수 있다. 데이터가 디스크에 정확하게 기록되지 않거나 디스크로부터 정확하게 다시 판독되지 않는 결과를 가져오는 하드 디스크와 컴퓨터 간의 연결성 문제가 있을 수 있다. 데이터가 메모리의 랜덤 위치에 기록되는 결과를 가져오는 운영 시스템이나 드라이버에서의 프로그래밍 버그가 있을 수 있다. 그러므로, 데이터 트랜잭션의 다양한 문제들과 기타 쟁점들이 파일 시스템의 데이터 구조들의 손상의 원인이 될 수 있다.
파일 시스템들은 통상적으로 부정확하거나 불완전한 트랜잭션에 의한 손상들을 검사하고 수리하기 위한 프로세스를 채택한다. 예를 들어, 와싱톤주 레드몬드시의 Microsoft사의 다양한 Windows 상표의 운영 시스템들에서 사용되는 NTFS(New Technology File System) 파일 시스템은 데이터 구조들이 일관적이고 아무런 손상을 입지 않았음을 확실히 하기 위해 볼륨을 스캔하는 Autochk/Chkdsk 유틸리티를 채택한다. NTFS 볼륨들이 시스템에 설치될 때마다 Autochk/Chkdsk 유틸리티가 NTFS 볼륨들 상에서 실행되고, 이것은 시스템이 부트되거나 재부트될 때 가장 일반적으로 일어난다. NTFS가 실행 볼륨에서 손상 문제를 발견할 때, 그것은 그 볼륨을 '더티(dirty)'로 표시하고, 사용자에게 손상 오류를 나타낸다. 그 다음, 시스템이 재부트될 때, NTFS가 '더티' 볼륨이나 다른 불일치를 발견하면, Autochk/Chkdsk는 자동으로 실행되고, 볼륨을 설치하라는 부트 요구는 지연되거나 거절된다. Chkdsk 유틸리티는 또한, 예를 들어, 유틸리티가 실행할 시간들을 제어하기를 원하는 대형 컴퓨터 시스템의 시스템 관리자에 의해 수동으로 시작될 수도 있다. Chkdsk가 볼륨에 대해 실행할 동안에(예를 들어, 수리를 위해 볼륨을 스캔함), 사용자는 그 볼륨을 액세스할 수 없다. 발견된 손상의 유형들에 따라, Chkdsk는 특정 교정 액션들을 취하여 그 손상들을 수리할 것이다. 예를 들어, 어디에 파일이 할당되었는지를 지시하게 되어있는 디스크 상의 정보가 일관성이 없거나 손상되어 있으면, Chkdsk는 그 파일을 삭제할 것이다. 판독불가이거나 손상된 파일 디렉토리가 존재하면, Chkdsk는 그 디렉토리를 재구성할 것이다.
그런 파일 복구 유틸리티들(예를 들어, Chkdsk)이 일반적으로 파일 시스템 손상들의 수리에 성공하지만, 그들은 단점들을 갖고 있다. 한 가지 단점은, 상술된 바와 같이, 그들이 사용자들에게 방해가 될 수 있다는 점이다. Chkdsk는 실행하기에 긴 시간이 소요될 수 있고, 그것이 스캔하고 수리하는 볼륨(예를 들어, 하드 디스크)으로의 독점적 액세스가 필요하다. 그러므로, 컴퓨터를 부팅할 때, 사용자는 그 볼륨(들)을 액세스할 수 없고, 그 대신에 Autochk/Chkdsk는 부트 프로세스가 완료될 수 있기 전에 그것의 수리를 종료할 때까지 기다려야만 한다. 예를 들어, 기업체 시스템을 서비스하는 대형 서버에서, Autochk/Chkdsk를 실행시키는데 걸리는 시간은 상당할 수 있다. 대형 서버들은 Autochk/Chkdsk로 프로세스하기에 많은 시간(예를 들어, 10-15 시간)이 소요될 수 있는 수 백만 개의 파일들을 가질 수 있다. 그러므로, 관리자가 Autochk/Chkdsk 유틸리티가 실행되는 시간에 대해 부주의하면 많은 사용자들이 불편해질 수 있다.
따라서, 볼륨으로의 액세스를 방해하거나 막지 않고 그 볼륨 상의 파일 시스템 손상들을 수리하는 방법이 필요하다.
본 발명의 시스템 및 방법은 파일 시스템 손상의 실시간 교정을 가능케 한다. 파일 시스템의 한 가지 개선점은 실행 볼륨에서 탐지된 파일 시스템 손상들에 실시간으로 응답하고, 파일 시스템이 그 볼륨 전체를 잠그지 않고 손상들을 탐지하는 지점에서 손상들을 수리하여 볼륨에 대한 다른 동작들이 계속될 수 있게 한다. 파일 시스템에 의한 손상을 탐지할 때, 그 시스템 개선점은 손상의 성격을 서술하는 정보를 기록한다. 발견되는 손상의 각각의 유형에 대해 수리 스캔이 정의된다. 수리는, 그것의 복잡성에 따라, 손상을 탐지한 사용자 요구에 동기하거나 비동기하여 발생할 수 있다. 비동기의 경우, 응용 프로그램에는 진행 중의 수리에 대한 정보가 통지될 것이다.
동일 참조 부호들은 도면들에서 동일 컴포넌트들과 특징들을 참조하기 위해 사용된다.
다음의 논의는 실행 볼륨에서 탐지된 손상들의 실시간 및 온라인 수리를 제공하는 개선된 파일 시스템 및 방법에 관한 것이다. 파일 시스템은 거의 인터럽트되지 않는 방식으로 파일 시스템 동작들을 관리하기를 계속하면서, 손상들을 탐지하고, 그 손상들을 교정하기 위한 적절한 수리들을 결정하고, 그 수리들을 실행하 는 자체-교정형(self-correcting)이다. 볼륨은 수리 동작 동안, 온라인이고 활성화되어 있다.
개선된 파일 시스템은 부트 시간이나 관리자에 의해 설정된 특정 시간에 실행하는 수리 유틸리티에 의해 한 번에 수리되기 보다는, 손상들이 발생될 때 수리되기 때문에, 컴퓨터 사용자들에게의 방해가 감소된다는 장점을 포함한다.
컴퓨팅 환경의 예
도 1은 실행 볼륨 상에서 탐지된 손상들의 실시간과 온라인 수리를 제공하는 개선된 파일 시스템을 구현하기에 적절한 컴퓨팅 환경의 예를 도시한다. 도 1에 한 개의 특정 구성이 도시되지만, 그런 컴퓨팅 디바이스들은 다른 컴퓨팅 구성들로도 구현될 수 있다.
컴퓨팅 환경(100)은 컴퓨터(102)의 형태의 범용 컴퓨팅 시스템을 포함한다. 컴퓨터(102)의 컴포넌트들은 한 개 이상의 프로세서들이나 프로세싱 유닛들(104), 시스템 메모리(106), 및 시스템 메모리(106)로 프로세서(104)를 포함하는 다양한 시스템 컴포넌트들을 결합하는 시스템 버스(108)를 포함하지만, 이에 제한되지는 않는다.
시스템 버스(108)는 메모리 버스나 메모리 제어기, 주변기기 버스, 가속화된 그래픽 포트, 및 다양한 버스 아키텍쳐들 중의 임의의 것을 사용하는 프로세서나 로컬 버스를 포함하는 여러 유형들의 버스 구조들 중의 임의의 것들 중에 한 개 이상의 유형들을 나타낸다. 시스템 버스(108)의 일 예는, 또한 메자닌 버스라고도 알려진, 주변 컴포넌트 상호접속(Peripheral Component Interconnects(PCI)) 버스 일 것이다.
컴퓨터(102)는 다양한 컴퓨터 판독가능 매체를 포함한다. 그런 매체는 컴퓨터(102)에 의해 액세스가능하고 휘발성과 비휘발성, 분리형과 비분리형 매체 모두를 포함하는 임의의 가용성 매체일 수 있다. 시스템 메모리(106)는, 랜덤 액세스 메모리(RAM)(110)와 같은, 휘발성 메모리 및/또는, 읽기용 메모리(ROM)(112)와 같은, 비휘발성 메모리의 형태로 컴퓨터 판독가능 매체를 포함한다. 스타트업 동안 같은 때에, 컴퓨터(102) 내의 소자들 간의 정보 전송을 돕는 기본 루틴들을 포함하는 기본 입/출력 시스템(BIOS)(114)은 ROM(112)에 저장된다. RAM(110)은 즉시 액세스가능하고 및/또는 프로세싱 유닛(104)에 의해 현재 동작 중의 데이터 및/또는 프로그램 모듈들을 포함한다.
컴퓨터(102)는 또한 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 예를 들어, 도 1은 비분리형 비휘발성 자기 매체(도시 안됨)로 읽고 쓰는 하드 디스크 드라이브(116), 분리형 비휘발성 자기 디스크(120)(예를 들어, "플로피 디스크")에 읽고 쓰는 자기 디스크 드라이브(118), 및 CD-ROM, DVD-ROM, 또는 기타 광 매체와 같은 분리형 비휘발성 광 디스크(124)에 읽고 쓰는 광 디스크 드라이브(122)를 도시한다. 하드 디스크 드라이브(116), 자기 디스크 드라이브(118), 및 광 디스크 드라이브(122)는 한 개 이상의 데이터 미디어 인터페이스들(125)에 의해 시스템 버스(108)에 각각 접속된다. 다른 경우에, 하드 디스크 드라이브(116), 자기 디스크 드라이브(118), 및 광 디스크 드라이브(122)는 SCSI 인터페이스(도시 안됨)에 의해 시스템 버스(108)에 접속될 수 있다.
디스크 드라이브들과 그들의 관련 컴퓨터 판독가능 매체는 컴퓨터(102)에 대한 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 및 기타 데이터의 비휘발성 저장을 제공한다. 예는 하드 디스크(116), 분리형 자기 디스크(120), 및 분리형 광 디스크(124)를 도시하지만, 자기 카세트나 기타 자기 저장 디바이스, 플래쉬 메모리 카드, CD-ROM, 디지탈 다용도 디스크(DVD)나 기타 광 저장장치, 랜덤 액세스 메모리(RAM), 읽기용 메모리(ROM), 전기적으로 삭제가능한 프로그램할 수 있는 읽기용 메모리(EEPROM) 등과 같은 컴퓨터에 의해 액세스가능한 데이터를 저장할 수 있는 다른 유형들의 컴퓨터 판독가능 매체는 또한 컴퓨팅 시스템과 환경의 예를 구현하기 위해 사용될 수 있음을 이해할 것이다.
임의의 수의 프로그램 모듈들은, 예를 들어, 운영 시스템(126), 한 개 이상의 응용 프로그램들(128), 기타 프로그램 모듈들(130), 및 프로그램 데이터(132)를 포함하는, 하드 디스크(116), 자기 디스크(120), 광 디스크(124), ROM(112), 및/또는 RAM(110) 상에 저장될 수 있다. 그런 운영 시스템(126), 한 개 이상의 응용 프로그램들(128), 기타 프로그램 모듈들(130), 및 프로그램 데이터(132)(또는 그들의 어떤 조합)의 각각은 사용자 통신망 액세스 정보를 위한 캐쉬 스킴(caching scheme)의 구현을 포함할 수 있다.
컴퓨터(102)는 통신 매체라고 식별된 다양한 컴퓨터/프로세서-판독가능 매체를 포함할 수 있다. 통신 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 또는 반송파나 기타 전송 메카니즘과 같은 변조된 데이터 신호의 기타 데이터를 구현하고, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용 어는 신호에 정보를 인코딩하는 방식으로 그것의 특징들 중의 한 개 이상이 세트되거나 변경되는 신호를 의미한다. 예를 들어, 통신 매체는 유선 통신망이나 직접 유선 연결과 같은 유선 매체, 및 음향, RF, 적외선, 및 기타 무선 매체와 같은 무선 매체를 포함하지만, 이에 제한되지는 않는다. 상술된 것들 중의 임의의 것의 조합들은 또한 컴퓨터 판독가능 매체의 범위 내에 포함된다.
사용자는 키보드(134)와 포인팅 디바이스(136)(예를 들어, "마우스")와 같은 입력 디바이스들을 통해 컴퓨터 시스템(102)으로 커맨드와 정보를 입력할 수 있다. 기타 입력 디바이스들(138)(특별히 도시되지 않음)은 마이크로폰, 조이 스틱, 게임 패드, 위성 접시, 직렬 포트, 스캐너 등을 포함할 수 있다. 이들과 다른 입력 디바이스들은 시스템 버스(108)에 결합된 입/출력 인터페이스들(140)을 통해 프로세싱 유닛(104)에 접속되지만, 병렬 포트, 게임 포트, 또는 범용 직렬 버스(USB)와 같은 다른 인터페이스와 버스 구조들에 의해 접속될 수도 있다.
모니터(142)나 기타 유형의 디스플레이 디바이스는 또한, 비디오 어댑터(144)와 같은, 인터페이스를 통해 시스템 버스(108)에 접속될 수 있다. 모니터(142)에 추가하여, 다른 출력 주변 디바이스들은 입/출력 인터페이스들(140)을 통해 컴퓨터(102)에 접속될 수 있는 스피커들(도시 안됨)과 프린터(146)와 같은 컴포넌트들을 포함할 수 있다.
컴퓨터(102)는, 원격 컴퓨팅 디바이스(148)와 같은, 한 개 이상의 원격 컴퓨터들에 논리 접속을 사용하여 통신망 환경에서 동작할 수 있다. 예를 들어, 원격 컴퓨팅 디바이스(148)는 개인용 컴퓨터, 휴대용 컴퓨터, 서버, 라우터, 통신망 컴 퓨터, 피어 디바이스나 기타 일반 통신망 노드 등일 수 있다. 원격 컴퓨팅 디바이스(148)는 컴퓨터 시스템(102)에 관련하여 본 명세서에 기재된 다수의 또는 전체 소자들과 특징들을 포함할 수 있는 휴대용 컴퓨터로서 도시된다.
컴퓨터(102)와 원격 컴퓨터(148) 간의 논리 접속은 구내 통신망(LAN)(150)과 광역 통신망(WAN)(152)으로 도시된다. 그런 통신망 환경은 사무실, 기업체 컴퓨터 통신망, 인트라넷, 및 인터넷에서 일반적이다. LAN 통신망 환경에서 구현될 때, 컴퓨터(102)는 통신망 인터페이스나 어댑터(154)를 통해 로컬 통신망(150)에 접속된다. WAN 통신망 환경에서 구현될 때, 컴퓨터(102)는 광역 통신망(152)을 통해 통신을 개통하는 모뎀(156)이나 기타 수단을 포함한다. 컴퓨터(102)의 내부나 외부에 있을 수 있는 모뎀(156)은 입/출력 인터페이스(140)나 기타 적합한 메카니즘들을 통해 시스템 버스(108)에 접속될 수 있다. 설명된 통신망 접속은 예일 뿐이고, 컴퓨터들(102, 148) 간의 통신 링크(들)을 개통하는 다른 수단이 채택될 수 있음을 이해할 것이다.
컴퓨팅 환경(100)에서 도시된 바와 같이, 통신망 환경에서, 컴퓨터(102),또는 그 일부, 에 관련되어 도시된 프로그램 모듈들은 원격 메모리 저장 디바이스에 저장될 수 있다. 예를 들어, 원격 응용 프로그램들(158)은 원격 컴퓨터(148)의 메모리 디바이스에 상주한다. 예를 들어, 응용 프로그램들과, 운영 시스템과 같은, 다른 실행가능 프로그램 컴포넌트들은, 그런 프로그램들과 컴포넌트들이 다양한 시간에 컴퓨터 시스템(102)의 상이한 저장 컴포넌트들에 상주하고 컴퓨터의 데이터 프로세서(들)에 의해 실행됨이 인식되지만, 본 명세서에서 개별 블럭들로서 도시된 다.
실시예
도 2는 실행 볼륨에서 탐지되는 손상들의 실시간 온라인 수리를 제공하는 개선된 파일 시스템을 구현하기 위해 구성된 컴퓨터(102)의 실시예를 도시한다. 컴퓨터(102)는 메모리(206)에 저장된 운영 시스템(202)과 다양한 응용 프로그램들(204)를 실행하기 위해 구성된 한 개 이상의 프로세서들(200)을 포함한다. 이 개시를 통해 사용되는 바와 같이, 볼륨이라는 용어는 일반적으로 식별가능한 데이터 저장장치를 가리키는 것으로 의도된다. 그러므로, 볼륨은 하드 디스크(210)와 같은 물리적 저장장치 상의 몇 개의 독립적으로 식별가능한 볼륨들 중의 하나일 수 있다.
파일 시스템 드라이버(208)(이후에 파일 시스템(208)으로서 언급됨)는 또한 컴퓨터(102)의 메모리(206)에 저장된다. 일반적으로, 파일 시스템, 또는 파일 관리 시스템은 디렉토리들이 그 아래에 파일들과 서브디렉토리들을 갖는 계층적 시스템과 같은, 컴퓨터(102)의 볼륨(210)(즉, 하드 디스크) 상에 파일들을 저장하기 위한 구조나 규정이다. 그러므로, 파일 관리 시스템은 데이터 파일들이 컴퓨터의 하드 디스크에 저장되는 방식, 파일들이 그 볼륨으로부터 검색되는 방법, 파일들을 명명하는 규약 등을 명시한다. "파일 시스템"이라는 용어는 종종 파일 시스템 드라이버, 프로그램, 또는 파일 관리 시스템을 지원하고 관리하는 운영 시스템의 일부를 가리키는 것으로 사용된다. 파일 시스템 드라이버는 온-디스크 포맷을 해석하여 파일 시스템 구조와 규약들을 관리하고, 다양한 사용자/응용 프로그램 요구들 에 응답하여 파일들을 열고, 판독하고, 기입하고, 재명명하고, 닫는 것과 같은 파일 동작들을 수행한다. 이것에 관련되어 본 명세서 전체를 통해 메모리(206)에 저장된 파일 시스템 드라이버/코드(208)에 대해 논의된다. 즉, 파일 시스템(208)은 상술된 바와 같이 보다 일반적인 파일 관리 시스템을 지원하고 관리하는 프로그램 또는 운영 시스템의 일부(예를 들어, 실행 코드)를 가리키는 것으로 의도된다.
따라서, 파일 시스템(208)은 컴퓨터(102) 내의 하드 디스크(210)의 한 개 이상의 볼륨들 상의 파일들의 관리와 연관된 다양한 동작들을 수행하기 위해 구성된다. 예를 들어, 파일 시스템(208)은 상이한 사용자/응용 프로그램 요구들에 응답하여 파일들을 열고, 판독하고, 기록하고, 재명명하고, 닫는 것과 같은 파일 트랜잭션들을 수행한다. 파일 시스템(208)은 통상적으로 도 2에 도시된 바와 같이 운영 시스템(202)에 통합된다. 그러나, 파일 시스템(208)은 운영 시스템(202)의 일체부로서만 제한되는 것이 아니라, 자립형 응용 프로그램이나 프로그램 모듈일 수 있다. 더욱이, 메모리(206)나 하드 디스크(210)가 도 2에 독립적으로 도시되지만, 메모리(206)는 부분적으로 또는 전체적으로 하드 디스크(210)의 일부일 수 있음을 주목한다. 하드 디스크(210)와 메모리(206)는 단지 설명을 위해 도 2에 독립적으로 도시하였다. 그러므로, 운영 시스템(202)과 다양한 응용 프로그램들(204)이 메모리(206)에 저장되는 것으로 도시되는 한편, 그들은 하드 디스크(210)의 한 개 이상의 볼륨들에 저장될 수 있다.
본 실시예에서, 파일 시스템(208)은 와싱톤주 레드몬드시의 Microsoft사로부터의 다양한 Windows 상표의 운영 시스템들에 의해 사용되는 NTFS(New Technology File System) 파일 시스템에 관해서 논의된다. 그러나, 파일 시스템의 예로서 NTFS의 사용은 상술된 파일 시스템 개선점이 적용가능한 기타 파일 시스템들과 운영 시스템들에 대한 제한으로서 의도되지 않는다. 그러므로, 본 명세서에서 기재된 실시간 파일 시스템 수리를 위한 파일 시스템 개선점은, 예를 들어, OS/2, 매킨토시, 및 UNIX-기반 운영 시스템과 같은 다양한 운영 시스템들에서 사용되는 다양한 파일 시스템들에 적용가능할 것이다.
상술된 바와 같이, 파일 시스템 트랜잭션을 관리하는 한 가지 중요한 양태는 파일 관리 시스템 내에서의 내부 무결성을 유지하는 것이다. 디스크(210)의 한 볼륨 상의 데이터 손상들은 디스크(210) 상의 물리적 변형(physical anomaly), 컴퓨터(102)와 하드 디스크(210) 간의 연결성 문제, 또는 데이터가 메모리의 랜덤 위치에 기록되는 결과를 가져오는 운영 시스템이나 드라이버의 프로그래밍 버그와 같은 다양한 문제들에 의해 기인될 수 있다.
실시간 수리 모듈(212)은 파일 시스템(208)의 일부로서 구성되어 컴퓨터(102)의 파일 관리 시스템의 무결성을 유지하는 것을 돕는다. 실시간 수리 모듈(212)은 일반적으로 파일 시스템(208)에 의해 탐지되는 손상들의 실시간 온라인 수리를 제공하기 위해 구성된다. 본 명세서의 본 섹션의 나머지 부분에서는 실행 시스템의 볼륨 상에서 탐지된 손상들에 응답하여 파일 시스템(208)에 관련된 실시간 수리 모듈(212)의 동작을 기재하고, 수리 프로세스의 탐지, 스케쥴링, 보고, 및 관리를 위한 기본 과정의 개요를 기술한다. 이들 논제들의 각각에 대한 추가 세부사항들은 부록이라 표제된 후속 섹션에서 다뤄진다.
실시간 수리 모듈(212)은 파일 시스템(208)이 손상 상태 표시/오류를 제기한 현재 코드 지점들에 응답하도록 구성된다. 그 때, 파일 시스템(208)은 필요한 만큼의 정보를 기록하여 그 특정 고장에 대한 수리 과정을 시작할 것이다. 수리 스캔은 현재 스레드(thread)에서 최상위 실행 레벨에서 다시 수행될 것이다. 그러나, 더 복잡한 수리 스캔들은 전용 스레드를 필요로 할 것이다.
많은 수리들은 실행 시스템에서 현재 파일을 조작하는 모든 사용자들에게 호환가능할 수 있고, 그러므로 완전히 투명하게 수리될 수 있다. 수리들이 실행 시스템의 파일들을 조작하는 사용자들에게 호환적이지 않은 경우에, 사용자들은 그 수리들과 관련된 부작용들을 인지하게 될 것이다. 예를 들어, 실시간 수리 모듈(212)은 스트림을 액세스하는 유효한 핸들들이 여전히 있는 동안에 그 스트림을 0의 길이로 절단할 수 있다. 그런 파일 시스템 수리는 기록기들과 공유하는 핸들들과는 호환성이 있지만, 다른 것들과는 호환적이지 않다. 비호환적인 핸들들은 무효화되어야 하고, 비호환적인 핸들들에의 이후 동작들은 실패할 것이다.
일부 형태의 손상으로 완료될 수 없는 파일 시스템(208)에의 최상위 레벨 요구는 오류 상태로 실패될 것이고, 단기 수리가 완료될 때까지 블럭킹될 것이다. 현재 파일 시스템 요구에 대해 탐지된 손상은 초기에 현재 요구 자체에서 탐지될 수 있거나, 이미 이전 요구와 관련된 초기 탐지의 결과로서 탐지되어 현재 수리 중에 있을 수 있다. 어느 측면에서든, 취해져야 할 적절한 교정 액션을 지시하는 수리 복잡성(repair complexity)의 레벨이 정의된다.
파일 시스템(208)과 수리 모듈(212)은 손상 탐지들에 응답하여 스케쥴된 수 리 동작들에 우선권을 부여한다. 이것은 컴포넌트들 간의 종속성을 감소시켜 이후 기능들의 설계를 단순화한다.
손상들의 탐지에서, 파일 시스템(208)은 하드 디스크(210)로부터 읽고 프로세스되는 현재 그대로의 메타데이터를 검증한다. 파일 시스템(208)은 메타데이터 손상들을 직접적으로 탐지하고, 각각의 손상을 지시하는 오류 상태를 제기한다. 손상이 탐지된 지점에서, 파일 시스템(208)과 수리 모듈(212)은 필요한 수리 범위를 결정하고, 현재 스레드의 최상위 레벨 파일 시스템 컨텍스트 구조에 이것을 기록한다. 통상적으로 파일 시스템(208)은 이미 손상입은 메타데이터 스트림을 잠근 상태로 유지하고 있고, 관련 데이터 구조들에 필요한 상태 정보를 그들이 무효한 상태에 있거나 수리중임을 지시하도록 설정할 수 있다. 이로써, 수리 모듈(212)은 수리 동작을 이들 동일 파일들에 대한 미해결 및 추후 요구들과 동기시킨다.
파일 시스템(208)과 수리 모듈(212)은 또한 다른 컴포넌트들의 고장들로 인한 손상들을 처리한다. 그런 손상들의 2 가지 주요 원인들은 로그(log) 파일의 데이터 유실 및 실패한 파일 시스템 트랜잭션 중단들이다. 로그 파일 실패들은 통상적으로 볼륨 재시작 시에 발생한다. 손상 상태가 제기되어, 파일 시스템(208)은 볼륨(예를 들어, 디스크(210))을 설치하기를 실패한다. 수리 모듈(212)은 이 오류를 캡쳐링하고, 로그 파일을 재초기화시킨다. 파일 시스템(208)은 이 시점에서 가능한 볼륨 손상을 무시하기로 결정해서, 실행 시스템에서 손상을 탐지하는 정규 메카니즘에 종속할 것이다.
실시간 수리 모듈(212)은 탐지된 손상들의 리스트를 프로세스하는 한 개의 루틴을 통해 수리를 수행하고, 수리 완료를 기다리는 파일 시스템 사용자 요구들의 리스트를 갖는다. 복잡한 수리 스캔들은 수리 동작을 서비스하기 위한 전용 스레드를 요구할 것이다. 전용 스레드는 필요할 때만 생성(spawn)되고, 그것은 동일한 일반 수리 루틴을 콜할 것이다. 소규모의 수리 루틴들은 스택의 최상위 레벨 실행 지점에서 인라인(inline)으로 실행된다. 그들은 통상적으로 길이 1의 수리 큐(queue) 및 길이 1의 계류중의 IRP 큐를 처리한다. 이에 의해, 복수의 수리들이 병렬로 진행되도록 한다. 이 경우에서, 이들 로컬 수리 동작들 중의 하나가 종속성(cascading)이거나 보다 복잡한 손상에 직면하면, 로컬 작업 큐와 IRP 큐는 글로벌 작업 큐로 이동될 수 있다. 이것은 또한 다른 로컬 수리 동작들이 취소되거나 글로벌 작업 큐로 전송되도록 할 수 있다.
손상들은 재귀적 파일 시스템 요구 내에서 탐지될 수 있다. 이 경우에, 파일 시스템(208)은 수리를 수행하기 위해 최상위 레벨의 요구로 복귀(unwind)한다. 이것은 수리가 수행되는 동안 어떠한 자원도 콜러(caller)에 의해 파일 시스템(208)에 보유되지 않음을 보장한다. 파일 시스템(208)이 어떠한 자원도 보유되지 않은 최상위 레벨로 복귀할 수 없으면, 작업 큐에 수리를 포스트(post)하고 현재 스레드에서 요구를 실패한다. 어째든, 손상 상태 오류로 인해 모든 재귀적 파일 시스템 요구들은 실패할 것이다. 이것은 상이한 요구의 컨텍스트 내에 요구들을 시작할 수 있는 파일 시스템 필터들에 영향을 줄 수 있다.
일부 경우들에서, 파일 시스템(208)은 손상된 부트 섹터 또는 MFT(master file table) 파일의 단절 때문에 볼륨(예를 들어, 디스크(210))을 설치할 수 없을 것이다. 손상된 부트 섹터가 있는 경우에, 파일 시스템이 실제로 그 볼륨을 "소유"하는지에 대한 확실성이 없다. 그러므로, 파일 시스템(208)은 디스크(210)를 스캔하여 메타데이터를 재구성하고 부트 섹터를 수리하기 위해 일방적(unilateral) 액션을 취할 수 없다. 이것은 볼륨에 나머지 파일 시스템 메타데이터가 있을 수 있지만, 볼륨이 다른 파일 시스템으로 빨리 포맷팅될 수 있기 때문이다. 이들 상황하에서, NTFS 볼륨과 같은, 특정 파일 시스템 볼륨으로서 볼륨이 다뤄지도록 강제할 수 있는 관리자에 의해 오프라인(offline) 툴이 실행될 필요가 있다. 그런 오프라인 툴은 볼륨을 스캔하여 부트 섹터를 재구성할 수 있다. 일단 부트 섹터가 제자리에 있으면, 파일 시스템(208)은 그 자체의 볼륨 스캔을 하여 파일 시스템 메타데이터의 나머지를 재구성할 수 있다. 이 전체 스캔은 손상된 부트 섹터 문제의 수리 프로세스를 완료할 것이고, 그것은 또한 MFT 파일의 단절의 문제를 처리한다.
파일 시스템(208)(실시간 수리 모듈(212)과 연계하여)은 그것이 손상을 탐지하는 시간에 발견된 손상의 성격을 기술하는 키 정보를 기록한다. 파일 시스템(208)과 수리 모듈(212)은 탐지된 손상들의 유형들에 대응하는 일련의 수리 스캔들을 정의한다. 손상 탐지 시에 정의된 수리 스캔에 대응하는 작업 항목이 생성된다. 특정한 복잡한 수리 스캔들은 저 레벨 스캔들과 추가 검사들의 집합이다. 저 레벨 스캔들의 집합인 복잡한 수리 스캔의 완료는 저 레벨 스캔들의 정확성을 보장한다(파일 검사는 속성들이 정확함을 보장함). 다른 수리 스캔들은 현재 실행중의 스캔이 그것이 성공적으로 실행할 수 있기 전에 다른 파일 시스템 메타데이터의 정확성에 종속할 수 있다는 점에서 계층적이다(즉, 디렉토리의 재구성은 그 디렉토리 에 포함된 파일의 파일명 검사를 블럭킹할 수 있음).
파일 시스템(208)은 손상 탐지와 현재 진행중의 수리들과 계류중의 수리들 동안에 생성되는 작업 항목들 간의 관계를 유지한다. 더 복잡한 스캔들 내에 포함된 수리 스캔들은 더 복잡한 스캔으로 폴드(fold)될 것이다. 복잡한 스캔이 완료되면, 컴포넌트 스캔들의 각각은 완료되는 것으로 간주된다. 계층적 수리 스캔들은 그들이 종속하는 스캔이 완료될 때 트리거(trigger)된다. 이들 관계를 유지하기 위해, 파일 시스템(208)은 진행중의 수리 스캔을 취소하여 더 높은 우선권의 스캔들을 수행하도록 지원한다.
수리 스캔들의 일부 예들은 다음을 포함한다:
실시간 수리 모듈(212)과 함께 파일 시스템(208)은 또한 수리 스캔을 수행하는 동안 추가 손상이 발견되는 경우를 처리한다. 명료한 아키텍쳐 모델을 유지하기 위해, 현재 수리 스캔과 발견된 손상의 유형 간의 관계는 상술된 관련된 수리 스캔들의 2개의 유형들 중의 하나에 들어맞는다. 현재 수리 스캔은 포함된 메타데이터 객체의 수리로 폴드되거나(즉, 속성을 수리하는 동안 탐지된 추가 파일 손상), 또는 그것은 새 수리 스캔이 완료될 때까지 보류된다(즉, 디렉토리 내의 파일의 파일 레코드가 수리될 때까지 디렉토리 검증은 보류됨). 이것은 개별 작업 항목들의 조심스런 정의를 요구하여, 수리하는 동안 발견된 임의의 가능한 손상은 원래 수리에의 임의의 종속성이 없이 스케쥴될 수 있거나 고쳐질 수 있다.
실시간 수리 모듈(212)과 함께 파일 시스템(208)은 실행 시스템에서 응용 프로그램들에의 최소 영향으로 수리를 수행하고, 수리 동안 행해진 변경들의 특성에 대해 전체적 보고를 제공한다. 그러나, 클라이언트 응용 프로그램들(204)은, 수리의 엄격함과 개방된 핸들들의 모드들에 종속하여, 파일 시스템 손상들의 수리 때문에 영향을 받게 될 것이다. 수리가 신속하면, 응용 프로그램에 의해 생성된 임의의 최상위 레벨의 IRP는 수리가 진행되는 동안 대기하도록 되어질 것이다. 그런 경우들에서, 수리 동작들은 응용 프로그램(204)에 투명해야 한다. 그러나, 수리가 사소하지 않으면, 파일 시스템(208)으로의 응용 프로그램 요구는 손상 상태 오류로 실패할 것이다.
응용 프로그램들(204)은, 응용 프로그램(204)을 포함하는 실행파일과 사용중의 임의의 데이터 파일들의 수리를 포함하는 수리 동작의 결과를 관리할 필요가 있을 것이다. 가능하면, 파일 시스템(208)은 USN과 통지 이벤트들을 통해 변경들을 보고할 것이다. 변경들이 현재 액세스와 호환적이고 파일 모드를 공유하면, 응용 프로그램(204)은 무리없이 진행될 수 있어야 한다. 그러나, 수리가 응용 프로그램(204)과 호환적이 아니면, 응용 프로그램(204)은 무효 핸들 상태 오류를 수신할 것이다. 응용 프로그램들(204)은 그들의 핸들들이 파일을 액세스하기 위해 더 이상 사용될 수 없는 경우들을 관리할 필요가 있을 것이다. 일반적으로, 파일 시스템 (208)과 수리 모듈(212)에서, 파일들은 설치제거(dismount)와 수리없이 액세스가능하도록 될 수 있다.
파일 시스템(208)은 현재 수리되는 중이거나 수리를 위해 큐된 모든 손상을 온-디스크에 기록하려고 시도하지 않는다. 파일 시스템(208)은 실행 시스템에서 다시 손상들을 발견해야 하거나 수리해야 하므로, 모든 손상들이 보존됨을 보장해야 하는 복잡한 온-디스크 표현의 개발이 거의 이점이 없다. 그러나, 장기 실행 스캔이 진행중이고 실행 시스템의 마지막 지점에 도달했음을 기록하는 것은 이점이 있다. 파일 시스템(208)은 디스크(210) 상의 볼륨 파일 레코드에 이 정보를 입력할 것이다. 그러나, 그것이 또한 그 자체를 손상시킬 수 있으므로, 이 데이터가 디스크 상에서 정확함을 보장하기는 불가능하다. 파일 시스템(208)은 또한 실행 시스템에서 볼륨 파일 레코드를 수리하는 프로세스 중일 수 있어서, 이 때 이 레코드에 기록할 수 없을 수 있다.
파일 시스템(208)은 상태 파일 손상 오류 코드와 상태 디스크 손상 오류 코드를 사용하여 일부 손상에 관련된 오류 때문에 현재 동작이 언제 실패할지를 지시한다. 이들 상태 코드들로 실패할 수 있는 세 가지 종류의 실패들이 있다:
수리 작업 때문에 이제 무효화된 핸들 - 파일 시스템은 공유 모드, 원하는 액세스, 파일의 파일 락 홀드(lock held), 또는 오프락 홀드(oplock held)와 비호환적인 어떤 방식으로 파일을 수리함
파일 시스템(208)은 또한 승인된 사용자들이 수리 프로세스와 대화하도록 하는 기능을 제공한다. 시스템 관리자들은 파일 시스템 메타데이터에 유효 스캔을 시작할 수 있다. 파일 시스템(208)은 관리자가 유효화(validation) 범위를 명시할 수 있도록 유연성을 제공한다. . 이것은 다음을 포함할 수 있다:
파일 시스템(208)은 또한 현재 복잡한 수리 동작과 진행 상태를 보고하기 위한 메카니즘을 제공한다. 사용자가 손상이 존재하기 때문에 파일 시스템 요구 실패를 전혀 알아차리지 못하므로, 사소한 수리 동작들에 대한 임의의 정보를 보고하는 것은 필요하지 않다. 그러나, 사소한 수리가 개방된 핸들들을 무효화시킬 수 있음을 주목한다.
파일 시스템(208)은 또한 수리 동작에 뒤떨어져 블럭킹할 수 있는 통지 메카니즘을 제공한다. 시스템 관리자는 볼륨 핸들을 사용하여 진행중의 임의의 복잡한 수리 또는 검증 스캔을 기다릴 수 있다. 이를 위해, 파일 시스템(208)은 손상 때문에 열린 볼륨을 버리지 않는다. 그 핸들에 상태 손상 오류를 얻은 사용자들은 그 핸들을 사용하여 그 핸들에 대한 수리가 완료되기를 기다릴 수 있다.
볼륨 설치제거는 수리가 진행중이면 크게 블럭킹되지 않는다. 임의의 단기(short term) 수리들이 완료될 수 있다. 장기 실행 수리 스캔은 사용자에 의해 재시작될 필요가 있다. 수리 큐에 있는 다른 사소한 오류들의 수리는 그들이 다음 볼륨 설치 동안 발견되면 취소되고 재시도될 것이다.
실시간 수리 모듈(212)과 함께 파일 시스템(208)은, 그것이 수리 동작들을 수행하는 볼륨을 완전히 스캔하므로, IO, CPU, 또는 메모리 집약적(intensive)일 수 있다. 이런 오버헤드는 일부 중대한 환경들에서는 수용할 수 없을 수 있다. 그런 경우들에, 파일 시스템들(208)은 장기 실행 스캔들에 대한 자동 수리를 중지하기 위한 방법을 제공하고, 관리자가 그 스캔을 직접 시작할 것을 요구한다. 일방적 단기 수리 동작들은 여전히 파일 시스템(208)에 의해 시작될 것이다.
실시간 수리 모듈(212)과 함께 파일 시스템(208)은 수리들을 수행하는 동안 반복되거나 산발적인 하드웨어 오류들에 직면할 것이다. 산발적 오류들은 수리를 불가능하게 만들 수 있다. 이 경우에, 파일 시스템(208)(수리 모듈(212))은 수리를 하지 못하여 볼륨을 손상 상태로 방치시킨다. 가능하면, 파일 시스템(208)은 사용자가 하드웨어 쟁점들을 해결해야 한다는 의도로 이벤트 로그에 이것을 기록한다. 되풀이가능한 오류들의 경우에, 파일 시스템(208)은 악성 클러스터 파일로 클러스터들을 회수하여 그 데이터를 유실된 것으로 다룬다.
실시간 수리 모듈(212)과 함께 파일 시스템(208)은 또한 실행 시스템의 상태 때문에 오류들을 인지하게 될 것이다. 오류들의 주요 출처는 일부 동작을 수행하기에 불충분한 풀(pool) 메모리일 것이다. 이 경우, 파일 시스템(208)은 가능하면 이벤트 로그에 그 고장을 기록하고, 수리를 종료한다. 그 수리는 손상에 다시 직면하게 될 미래의 한 시점에 다시 시도된다.
방법 예
실행 볼륨에서 탐지된 손상들의 실시간 온라인 수리를 제공하는 개선된 파일 시스템을 구현하는 방법들의 예가 도 3 내지 도 5의 흐름도들을 기본적으로 참조하여 이제 기재될 것이다. 방법들은 일반적으로 도 1과 도 2에 대해 상술된 실시예들에 적용된다. 한 개 이상의 방법들이 흐름도들과 그 흐름도들의 블럭들과 연관된 텍스트에 의해 개시되는 한편, 기재된 방법들의 소자들은 그들이 나타난 순서로 수행될 필요는 없고, 다른 순서들도 유사한 장점들로의 결과를 가져올 것임을 이해할 것이다. 더욱이, 방법들은 배타적이 아니며, 단독으로 또는 서로 조합하여 수행될 수 있다. 기재된 방법들의 소자들은, 예를 들어, ASIC의 하드웨어 로직 블럭들 또는 프로세서-판독가능 매체 상에 정의된 프로세서-판독가능 명령어들의 실행을 포함하는 임의의 적합한 수단에 의해 수행될 수 있다.
본 명세서에서 사용된 바와 같이, "프로세서-판독가능 매체"는 프로세서에 의해 사용되거나 실행되는 명령어들을 포함하고, 저장하고, 통신하고, 전파(propagation)하고, 또는 전송할 수 있는 임의의 수단일 수 있다. 프로세서-판독가능 매체는 전자, 자기, 광, 전자기, 적외선, 또는 반도체 시스템, 장치, 디바이스, 또는 전파 매체일 수 있지만, 이에 제한되지는 않는다. 프로세서-판독가능 매체의 더 구체적 예들로는, 다른 것들 중에서도, 한 개 이상의 유선들을 갖는 전기 접속(전자), 휴대용 컴퓨터 디스켓(자기), 랜덤 액세스 메모리(RAM)(자기), 읽기용 메모리(ROM)(자기), 삭제가능의 프로그램가능한 읽기용 메모리(EPROM 또는 플래쉬 메모리), 광 섬유(선택적), 재기록가능한 컴패트 디스크(CD-RW)(선택적), 및 휴대용 컴팩트 디스크 읽기용 메모리(CDROM)(광)를 포함한다.
방법(300)의 블럭(302)에서, 저장 볼륨의 데이터에 대해 손상이 탐지된다. 파일 시스템(208)은 손상을 탐지한다. 손상은 현재 파일 시스템 요구 동안 또는 현재 파일 시스템 요구에 대해 탐지될 수 있거나, 또는 그것은 이전 파일 시스템 요구 동안 탐지될 수 있다. 파일 시스템(208)은, 블럭(304)에서 도시된 바와 같이, 손상이 탐지되는 시간에 손상을 기술하는 정보를 기록한다. 블럭(306)에서, 파일 시스템은 손상이 탐지되었음을 지시하는 오류 상태를 발생시킨다. 블럭(308)에서, 파일 시스템은 손상의 존재를 지시하는 오류 상태에 응답하여 현재 파일 시스템 요구의 실행을 선택적으로 보류시킨다.
파일 시스템은 블럭(308)에서 기록된 정보를 사용하여 탐지된 손상에 기초한 수리 스캔을 정의한다. 수리 스캔들의 예로는 속성 스캔, 파일 스캔, 인덱스 스캔, 볼륨 비트맵 재구성, 및 보안 서술자 파일 스캔을 포함한다. 수리 스캔을 정의하는 것은 저 레벨 스캔들의 집합을 포함하는 복잡한 수리 스캔을 정의하는 것을 포함할 수 있다.
블럭(312)에서, 수리 스캔은 파일 시스템에 의해 구현된다(즉, 실시간 수리 모듈(212), 도 2). 수리 루틴은 수리 스캔을 구현하기 위해 실행된다. 수리 루틴은 현재 스레드 내에서 실행의 최상위 레벨 지점에서 실행될 수 있거나, 개별/전용 스레드는 수리 스캔을 서비스하기 위해 시작될 수 있다(즉, 수리는 전용 스레드가 수리를 픽업(pickup)하고 수행하는 큐에 포스트(post)됨). 수리 스캔이 복잡한 수리 스캔이면(즉, 저 레벨 스캔들의 집합을 포함함), 복잡한 수리 스캔은 임의의 연관된 저 레벨 스캔들을 포함하여 구현된다. 파일 시스템 요구가 재귀적 요구이면, 파일 시스템은 재귀적 요구들의 최상위 레벨 요구로 언와인드(unwind)하고, 최상위 레벨 요구에 대해 수리 스캔을 구현한다.
방법(300)은 블럭(314)에서 도 3에서 도 4로 계속된다. 블럭(314)에서, 현재 파일 시스템 요구는 수리 스캔이 완료된 후에 실행을 재개한다. 파일 시스템 요구의 재개는 통상적으로 의도된 바와 같이 그 요구를 완료하는 것을 포함한다. 그러나, 수리 스캔이 사소하지 않은 수리 스캔이고, 그러므로 아직 완료되지 않았으면, 파일 시스템 요구는 실패할 것이고, 파일 시스템은 손상 상태 오류를 발생시킬 것이다. 동기적 요구는 수리가 재개되기 전에 완료될 때까지 대기할 것이다. 또한, 수리 스캔이 요구를 하는 응용 프로그램의 액세스 핸들과 비호환적이면, 요구는 실패할 것이고, 파일 시스템은 무효 핸들 상태 오류를 발생시킬 것이다.
블럭(316)에서, 현재 수리 스캔에 종속하는 파일과 연관된 제2 파일 시스템 요구가 수신된다. 현재 수리 스캔이 장기 실행 수리 스캔이면, 블럭(318)에 도시된 바와 같이, 시스템 요구는 실패할 것이다. 현재 수리 스캔이 단기 실행 수리 스캔이면, 블럭(320)에 도시된 바와 같이, 제2 파일 시스템 요구는 현재 수리 스캔이 완료될 때까지 블럭킹된다.
블럭(322)에서, 현재 수리 스캔을 중지시키는 파일 시스템 제어(fsctl) 커맨드(즉, 통지 시스템)가 수신된다. 그런 fsctl 커맨드들은 사용자/관리자 입력으로 부터 수신된다. 현재 수리 스캔이 장기 실행 수리 스캔이면, 수리 스캔은 블럭(324)에 도시된 바와 같이 중지된다. 그렇지 않으면, 현재 수리 스캔이 완료된다.
블럭(326)에서, 추가 손상은 수리 스캔을 구현하는 동안 탐지된다. 이 경우, 블럭(328)에 도시된 바와 같이, 수리 스캔은 새 수리 스캔이 완료될 때까지 보류될 수 있다.
블럭(330)에서, 산발적 하드웨어 오류는 수리 스캔을 구현하는 동안 탐지된다. 블럭(332)에 도시된 바와 같이, 수리 스캔들은 산발적 하드웨어 오류들이 탐지될 때 실패된다. 산발적 하드웨어 오류들 때문에 실패되는 수리 스캔들은, 블럭(334)에 도시된 바와 같이, 이벤트 로그에 로그된다. 그 다음, 사용자는 그 로그를 검토할 수 있고, 하드웨어 오류를 고친다.
블럭(336)에서, 유효화 스캔은 수리 스캔 동안 파일 시스템 데이터에서 시작된다. 유효화 스캔들의 예는 전체 볼륨 스캔, 보안 스캔, 파일 스캔, 스트림 스캔, 디렉토리 스캔, 및 뷰 인덱스 스캔을 포함한다.
부록
이 부록은, 파일 시스템(208)과 실시간 수리 모듈(212)에 대해 상술된 바와 같이, 손상 탐지, 수리 스케쥴링, 손상과 수리 보고, 및 수리 프로세스의 관리의 추가 세부사항들을 제공한다. 상술된 바와 같이, NTFS 파일 시스템이 파일 시스템의 예로서 제공되지만, 임의의 특정 파일 시스템으로 기재된 파일 시스템 개선점의 적용을 제한하려는 의도는 아니다.
응용 프로그램 호환성
수리의 심각성과 열린 핸들들의 모드에 따라, 클라이언트 응용 프로그램들은 NTFS 손상의 수리 때문에 영향을 받을 수 있다. 수리가 신속하면, 응용 프로그램에 의해 시작된 임의의 파일 시스템 요구는 수리가 진행되는 동안 대기하도록 되어질 것이다. 이들 경우들에서, 수리 동작은 그 응용 프로그램에게 명백해야 한다. 수리가 사소하지 않으면, 요구는 STATUS-CORRUPT-XXX 클래스의 오류로 실패할 것이다.
응용 프로그램들은 그들이 조작중인 기반 파일들의 무효화된 핸들들 및/또는 변경들을 포함할 수 있는 수리 동작의 결과를 처리할 필요가 있을 것이다. 수리들은 응용 프로그램(204)을 포함하는 실행파일과 사용중의 임의의 데이터 파일들에 영향을 미칠 것이다. 가능한 NTFS는 USN과 DirNotification 이벤트들을 통해 변경들을 보고할 것이다. 변경들이 파일의 현재 액세스 및 공유 모드와 호환적이면, 응용 프로그램은 무리없이 진행될 수 있어야 한다. 그러나, 수리가 응용 프로그램과 호환적이지 않으면, 그것은 STATUS-INVALID-HANDLE을 볼 것이다. 응용 프로그램들은 그들의 핸들이 그 파일을 액세스하기 위해 더 이상 사용될 수 없는 경우를 처리할 필요가 있을 것이다. 이것은 손상이 파일을 액세스불가능 하도록 할 수 있지만, 자체수리(self-healing) NTFS에서 파일은 설치제거와 수리없이 액세스가능 하도록 될 수 있는 현재 동작과 유사하다.
복수의 데이터 파일들을 사용하고 그들 간의 데이터 일관성에 따르는 잘 작성된 응용 프로그램들은 그들이 파일을 액세스하기 위해 사용하는 핸들의 무효화를 동반하는 파일들 중의 한 개의 변경에 의해 영향을 받을 것이다. 이것은 autochk 또는 chkdsk가 볼륨 설치들 간에 그들의 데이터 파일들 중의 하나를 수정할 수 있는 현재 모델에 유사해 보일 것이다.
실행 파일들은 수리될 수 있고, 그들 내의 데이터는 변경될 수 있다. NTFS는 그것이 스트림의 바이트들에 영향을 미치는 임의의 변경을 하면 이미지로서 현재 매핑되는 임의의 스트림을 무효화할 필요가 있을 것이다. 이미지의 실행은 이미지가 여전히 메모리에 있을 동안은 아무런 오류에 직면하지 않을 것이다. 임의의 요구가 NTFS의 무효한 것으로 표시된 파일 핸들이나 스트림에 도달하는 지점에서, NTFS는 STATUS-INVALID-HANDLE로 현재 요구를 실패할 것이다. 특정 파일들로 되어진 수리들은 응용 프로그램이나 운영 시스템 조차도 죽게 될 수 있다.
동시 파일 액세스
자체수리 NTFS는 현재 실행 중이거나 스케쥴된 수리 동작 때문에 열리고 있거나 생성되고 있는 파일이 수정되거나 삭제될 수 있는지를 검사해야 할 것이다.
이 수리는 통상적으로 파일 자체에 대해 수행되지만, 부모의 디렉토리 스캔이나 보안 파일의 재구성과 같은 타겟 파일에 영향을 미치는 다른 경우들이 존재한다. 이 파일에 영향을 미칠 수 있는 임의의 수리가 실행중이면, 판독기, 기록기, 및 삭제기들과 공유하는 공유 모드를 갖는 열린 파일만이 성공할 것이다. 비호환적 열린 파일들은 진행중의 수리의 복잡성에 따라 블럭킹되거나 실패할 것이다. 일 실시예에서, 모든 사용자의 열린 파일들은 수리가 진행되는 동안 블럭킹된다.
새 파일 생성
새 파일 생성은 콜러(caller)가 모두와 공유하기를 원한다는 가정하에, 다음 수리들을 블럭킹할 것이다. 그렇지 않으면, 그것은 적절한 오류로 실패할 것이다:
타겟 생성의 조상(ancestor)에의 디렉토리 스캔. 이것은 새 파일을 생성하는 프로세스에서 트래버스되는 임의의 디렉토리를 포함한다.
보안 스트림의 수리
기존의 열린 파일들
기존의 열린 파일들은, 콜러가 다른 모두와 공유하기를 원한다는 가정하에, 다음 수리들을 블럭킹할 것이다. 그렇지 않으면, 그것은 적절한 오류로 실패할 것이다:
열려있는 파일에의 임의의 스캔.
이것을 열기 위해 트래버스된 부모에의 디렉토리 스캔.
기존 오픈
핸들들
자체수리 NTFS는 항상 수리들의 수행에서 우선권을 가질 것이다. 이것은 그 수리가 항상 읽기, 쓰기, 및 삭제 액세스가 부여됨을 의미한다. 일단 이 액세스가 부여되면, 이 액세스와 비호환적인 임의의 기존 핸들들은 무효화되어야 한다. NTFS는 파일에 대한 CCB들을 무효하다고 표시할 것이고, 요구들을 실패할 것이다. 일부 경우들에서, 스트림의 모든 존재하는 핸들들은 무효화되어야 한다. 이들 경우들에서, NTFS는 파일을 지원하는 SCB를 오펀화(orphan)하고, 그 스트림으로의 추후 액세스를 위해 새 SCB를 생성할 것이다.
매핑된
파일들
매핑된 파일들의 현재 NT 구현은 활성화된 사용자 매핑된 섹션이 있으면 파 일이 절단되는 것을 막는다. 사용자들은 또한 이 섹션을 통해 파일 데이터에 직접 액세스를 하고, NTFS는 이 액세스를 직결화하는 아무런 방법이 없다. 자체수리 NTFS는 매핑된 섹션을 갖는 스트림의 데이터를 수정할 어떤 이유도 없지만, 그 스트림을 절단하거나 또는 삭제조차도 할 필요가 있을 수 있다. 그것은 매핑된 섹션과 비호환적인 수리 절단 동작이다. NTFS는 동일 섹션을 사용하는 모든 객체들을 의미하는 이 경우의 데이터 섹션을 오펀화할 필요가 있다. 캐쉬 관리자는 또한 동일 섹션을 사용한다. 현재 스트림 상의 모든 핸들들과 섹션들은 무효화될 필요가 있고, 이들 핸들에의 임의의 액세스는 STATUS_INVALID_HANDLE을 리턴할 것이다.
간단한 예 - 사용자가 이 핸들을 사용하여 파일을 매핑하는 경우. 매핑하기 위해 콜을 검사하고, 그것이 파일 시스템 콜백(callback)에서 실패할 수 있는지를 본다.
이벤트
로깅
(logging)
모든 손상들의 발견들과 NTFS 수리 스레드에 의해 되어지는 후속 수리들은 시스템 이벤트 로그 및/또는 수리 로그에 로그된다. 모든 이벤트 로그 엔트리들은 다음 데이터의 일부 또는 전체를 포함한다:
이벤트 로그 및/또는 수리 로그 자체가 손상될 수 있음을 주목한다.
오펀화된
클러스터들의 보전
오펀화된 클러스터들의 보전은 없을 것이다. 오펀화된 클러스터들은 비트맵에 할당되고 표시되지만 아무런 파일에도 속하지는 않는 것들이다.
오펀화된
파일들의 보전
chkdsk 동작과 동일하게 동작한다.
매핑된
파일들 및 이미지들
메모리 관리자는 데이터 섹션 또는 이미지 섹션을 지원하는 파일이 절단되도록 허용하지 않는다. 수리가 매핑된 섹션이나 이미지 섹션을 지원하는 스트림을 절단하거나 삭제할 필요가 있으면, NTFS는 그 속성을 무효화할 것이다. 지원하는 속성을 읽거나 쓰려는 임의의 시도는 STATUS_INVALID_HANDLE로 실패할 것이다: 응용 프로그램이 이미 메모리에 있는 데이터로 실행하기를 계속할 수 있으므로, 이 오류가 즉시 나타나는 것은 아니다. NTFS가 실제 속성을 무효화시켜야 하므로, 이것은 속성의 핸들들이, 수리 동작들과 호환적인 것들 조차도, 무효화될 것임을 의미한다.
오프락들(
oplocks
)
오프락들은 콜러가 다른 로컬 위치에 파일들을 캐쉬할 수 있음을 제안한다. 오프락이 해제된 때 NTFS 저장소에 다시 기록되는 그 위치에서의 계류중의 변경들이 있을 수 있다. 자체수리 NTFS는 어떤 핸들들이 수리 중에 비호환적인 동작들이 발생하는 것을 막기 위해 무효화될 수 있는지를 먼저 결정할 것이다. 그 다음, 그것은 오프락들을 해제하고, 수리를 시작한다. NTFS는 수리를 시작하기 전에 오프 락 해제 수신확인을 기다리지 않을 것이다. 이것은 수리 모델을 간단하게 하기 위해서이고, 수리가 진행될 수 있기 전에 사용자 액션을 기다리는 시스템을 블럭킹하지 않는다.
배타적 오프락들은 항상 FILE_OPLOCK_BROKEN_TO_NONE으로 해제될 것이다. 핸들 호환성을 검사하기 위한 초기 스캔이 성공하는 한, NTFS는 오프락을 홀딩하는 핸들이 쓰기 동작들을 수행하도록 할 것이다. 파일 락 해제는 한 범위의 파일들을 보호한다. 파일 시스템 필터들은 단지 최상위 레벨에서만 수리된다. 사용자가 핸들을 가지면, 필터가 항상 다른 파일에 액세스를 매핑하는 것이 가능하다. 이것은 사용자의 파일이 수리 중이면 아마도 쟁점화되지 않을 것이다. IO 레벨에서 이것을 실패할 필요는 없다.
특수 파일들
하이버파일(hiberfile), 페이지파일, 등록 하이브(registry hives), TxT TOPS 스트림, 및 크래쉬덤프(crashdump) 파일들과 같은 특수 파일들은 수리에 고유한 문제를 제기한다. 그들은 파일 시스템에 가깝게 연관되고, 그들의 판독기들과 기록기들은 그들의 클러스터 레이아웃에 대한 가정을 한다. 통지 메카니즘은 이들 응용 프로그램의 사용자들이 그들의 파일에 더 이상 속하지 않고 디스크를 손상시키는 클러스터들을 사용하기를 계속하는 것을 중지시키기 위해 제공될 것이다.
MARK_HANDLE에 의해 정해진 파일들에 대해서도 동일하게 적용된다. 핸들을 열 필요없이, 그들은 클러스터들에 직접 I/O를 수행하므로(그들은 그 파일을 참조하는 파일 객체를 가짐?), 이들은 처리하기에 특히 더 힘들다. 페이지파일의 손상 들은 허용가능하지 않을 것이다. 처리해야 하는 페이지 풀(paged pool) 쟁점들이 있을 것이다. 더 나쁜 것은, 우리 자신의 코드가 페이지화될 필요가 있을 것이라는 점이다.
트랜잭션 NTFS(
TxF
)
타겟 파일이 TxF 트랜잭션의 일부이면, 실제로 변경에 영향을 미치기 전에 수리는 TxF를 통지할 필요가 있다. 이것은 파일 핸들들이 무효화되는 동일 시간 부근에 홀드된 자원들로 발생하는 동기적 콜이다. (사실상, TxF는 그들 자체로 모든 핸들 무효화를 시행할 것임) TxF는, 그 자신의 부분에서, TxF 파일 락을 제외한, 트랜잭션(버젼 히스토리, STOP 스트림 등)에 대한 모든 그것의 인메모리(in memory) 상태들을 해제시킬 것이다. 일단 수리가 완료되면 수리는 또한 TxF를 콜하여, 그것은 필요하면 그것의 트랜잭션 취소를 진행할 수 있다. 이들 콜들의 세분화가 문제시 된다. 수리는 그들로 인해 너무 부담이 되지 않아야 한다. 모든 기존 트랜잭션들의 취소는 볼륨을 스팬(span)하는 특히 파괴적인 수리들에 대한 실용적인 해결책일 것이다.
TxF는 또한, 특히 고장(crash) 이후나 취소 동안에, 파일들이 있어야 하는 상태들에 있지 않는 파일들에 대한 더 일반적 쟁점을 처리할 필요가 있을 것이다. TxF는 수리가 그것의 동작들을 방해할 때마다 이벤트 로그에 기록할 것이다. 수리가 트랜잭션의 무결성에 유해하면, 트랜잭션은 취소될 것이다. 이것은 트랜잭션 동작들의 영속성을 보장하기 위해서이고, 언제 어떤 이유로 특정 변경이 되어지지 않았음을 사용자가 알도록 한다. 모든 기존의 트랜잭션 핸들들은 무효화될 것이 다.
TOPS 스트림과 일반 로그 파일들은 수리될 수 없는 특수 파일들로서 취급될 것이다. 그러나, TxF와 일반 로그는 그들 각각의 영역에서 손상들을 처리하는 방법을 알 필요가 있다. 그러나, 그들이 그렇지 않으면 단순히 손상된 채로 있을 것이므로 수리되도록 하면 이상적일 것이다.
마운트 동안에 발견된 손상된 초기 시스템 파일 레코드들
일단 볼륨이 유효 버젼을 갖는 NTFS 볼륨으로서 인식되면, 파일 시스템은 초기 시스템 파일 레코드들의 각각을 유효화할 것이다. 이 내부 파일 유효화는 손상이 탐지되면 전체 볼륨 스캔으로 쉽게 확장될 수 있을 것이다.
NTFS
재시작 실패
NTFS는 재시작을 실행할 동안 LOG_FILE_FULL이 일어날 수 있다. 이론적으로 이것은 보전 전략(preservation strategy)이 정확하다면 불가능하다. 이것은 설치를 재시도하지만 재시작을 실행시키지는 않아서 처리된다. 이것은 NTFS가 백그라운드에서 전체 스캔을 실행하도록 요구할 것이지만, 한편 볼륨은 이용가능해야 한다.
속성들
이들은 저 레벨 동작들을 기재하고, 특히 디스크에 무슨 액션들이 행해져야 하는지를 기재한다.
기본 속성(Basic Attribute)
기본 속성은 파일 레코드의 한 속성이다. 그것은 상주 속성, VCN 0에서 비 상주 속성, 또는 비상주 스트림의 단편을 기재하는 임의의 속성일 수 있다.
온-디스크 내부 속성 불일치 - VCN 0에서의 사용자 데이터 속성을 제외한 임의의 비상주 속성을 삭제한다. 이들을 0 길이로 만든다. 사용자 데이터 속성을 제외한 임의의 상주 속성을 삭제한다. 이들을 0 길이로 만든다. 속성 리스트가 업데이트됨을 보장할 필요가 있다. 속성 리스트가 업데이트됨을 보장할 필요가 있다. 나머지 파일이 여전히 유효함을 유효화할 필요가 있다. 속성이 포함될 수 있는 임의의 인덱스로부터 속성을 삭제한다.
SCB와 불일치하는 온-디스크 - 온-디스크 속성을 먼저 유효화하고, 필요한 변경들을 한다. 그 다음, SCB와 FCB를 정확한 온-디스크 변경들로써 업데이트한다.
인메모리 구조만에서의 불일치 - 디스크로부터 다시 SCB와 FCB를 업데이트한다.
지원된 값보다 더 긴 할당 길이 - 이 값은 매핑 쌍들과 가장 높은 VCN 값들에 대해 검증될 수 있다.
복잡한 속성(Complex Attribute)
복잡한 속성은 전체 NTFS 속성을 만드는 전체 기본 속성들의 세트이다.
내부 속성 유효화는 속성의 단편들 전체가 자체일관적(self-consistent)임을 검사한다. 그렇다면, NTFS는 SCB와 FCB를 업데이트하여 이것을 반영할 것이다. 외부 속성 유효화는 속성의 전체 단편들에 대해 MFT을 스캔하는 것과 관련이 있다. 이것은 MFT의 전체 스캔과 관련있으므로, 실제로 대신 외부 파일 유효화를 하지 않 을 어떤 이유도 없다.
다음 오류들은 복잡한 속성의 손상을 지시한다:
할당 크기를 초과하는 파일의 단편에 대한 기본 속성이 존재한다 - 불필요한 단편을 삭제한다.
복잡한 속성 내의 생략된 속성 - 먼저 내부 속성 유효화를 행한다. 이것이 일관적 속성으로 해결하면, SCB를 업데이트하여 이것을 반영한다. 그렇지 않으면, 외부 파일 유효화로 이동한다.
불일치의 SCB 값들 - 내부 속성 유효화를 행한다.
MCB는 길이 0의 범위를 갖는다 - 내부 속성 유효화를 행한다.
속성 내용
자체수리 NTFS는 NTFS 메타데이터를 갖는 속성들 또는 NTFS 메타데이터를 갖는 속성들의 일부의 내용을 유효화할 것이다. 예를 들어, 리파스(reparse) 지점들은 고정 데이터와 사용자 정의된 데이터를 포함한다. NTFS는 임의의 속성의 사용자 부분을 보전하거나 유효화하려는 임의의 시도를 하지 않을 것이다.
NTFS 메타파일들의 특정 속성들의 내용 유효화는 다른 곳에서 기재된다.
비상주
속성들
부트 파일이 아닌 파일의 LCN 0 - 속성은 무효하고, 0의 길이로 세트되거나 삭제되어야 한다. 이 이후에 내부 파일 유효화를 행한다.
$STANDARD-INFORMATION
무효한 $STANDARD-INFORMATION - 내부 파일 유효화를 행한다. 표준 정보를 재구성한다.
$ATTRIBUTE-LIST
속성 리스트 길이는 기존 속성들을 절단한다 - 외부 파일 유효화를 행한다.
속성 리스트 엔트리는 0의 길이를 갖는다 - 외부 파일 유효화를 행한다. 속성 리스트는 파일에 있지 않은 엔트리를 갖는다 - 내부 파일 유효화를 행한다.
속성 리스트는 파일 레코드에 있는 엔트리를 생략한다 - 외부 파일 유효화를 행한다.
$DATA
$DATA 속성들 - NTFS는 손상된 사용자 데이터 스트림들을 수리할 때 특정 액션들만을 취할 것이다. 그것은 존재하도록 요구되면 0의 길이의 속성을 생성하거나, 현재 존재하고 손상되었으면 0으로 절단하거나, 또는 완전히 삭제할 것이다.
$
REPARSE
-POINT
무효 $REPARSE-POINT - 파일과 리파스 인덱스로부터 속성을 삭제한다. FCB/SCB를 업데이트하여 리파스 포인트가 없음을 지시한다.
$Reparse 속성 - 접합 지점들은 디렉토리 상에만 있을 수 있고, 디렉토리들은 비어 있어야 한다. $Reparse 속성들과 $EA 속성들은 동일 파일이나 디렉토리에 모두 존재할 수 없다. 리파스 태그는 DUPLICATED-INFORMATION의 일부이다.
$
EA
및 $
EA
-INFORMATION
$EA 및 $EA-INFORMATION는 그 중 하나가 존재하면 둘 다 모두 존재해야 한다. EA 정보는 또한 파일에 대해 DUPLICATED-INFORMATION에 존재한다. 파일에 대 한 EA들은 디렉토리 엔트리들의 EA 정보와 일관적일 필요가 있다. 내부 EA 유효화는 EA 및 EA-INFORMATION이 유효 속성들이고 EA들이 잘 구성되었고, 디렉토리 정보의 EA 정보가 매치함을 검증한다. 추가로, 파일에 $REPARSE 속성이 없다.
EA 속성이 생략되었다 - 내부 EA 유효화를 행한다.
인덱스
속성들에 대한 인덱스들은 파일의 속성에 대응하는 인덱스의 엔트리를 갖는다. 예들로는 파일명, 리파스 포인트, 및 객체 ID가 있다. 아래 일부 오류들은 모든 인덱스들에 적용되지만, 인덱스 고유의 오류들은 속성들에 대한 인덱스에만 적용된다.
이들 인덱스들의 내부 유효화는 인덱스가 잘 형성되고 적절히 정렬됨을 검증하는 것과 관련있다. 추가로, 인덱스들의 엔트리들은 파일에서 대응하는 속성을 갖는다.
외부 유효화는 이 인덱스에 대응하는 엔트리들을 탐색하는 MFT의 전체 스캔을 수행하는 것과 관련있다.
인덱스 헤더
인덱스 헤더는 버퍼 외부의 지점을 오프세트(offset)한다 - 전체 MFT 스캔을 통해 인덱스를 재구성한다.
헤더가 아무런 엔트리를 가리키지 않는다 - 전체 MFT 스캔으로 인덱스를 재구성한다. 비트리(btree)의 뒤섞기 또는 전체 인덱스 버퍼들을 조사하고(walk) 구성중인 새 인덱스에 엔트리들을 추가하여 제자리에 그것을 재구성하는 것에 기초하 는 최적화를 고려한다.
마지막 인덱스 엔트리 전에 최종 레코드를 만난다 - 전체 MFT 스캔으로 인덱스를 재구성한다. 최적화는 가짜 최종 레코드를 지난 엔트리들만을 오펀화하는 것이나 다른 최종 레코드가 있는지를 테스트하는 것을 포함한다.
인덱스 버퍼
상위 32비트들은 인덱스블럭(IndexBlock)에 세트된다 - 이 인덱스를 버리고, MFT 스캔으로 인덱스를 재구성한다. 무효 비트들을 무시하는 것을 찾는 것을 고려하고, 내부 검사가 인덱스 엔트리들이 유효함을 지시하면 0으로 리세트(reset)한다.
인덱스블럭 번호의 낮은 32비트들의 부정확한 값들 - 전체 MFT 스캔을 통해 인덱스를 재구성한다. 인덱스블럭 필드만에서의 손상에 기초한 최적화를 고려한다. 이것은 이것을 기대되는 값으로 세트한 후에 내부 인덱스 유효화에 의해 수행될 수 있다.
무효 헤더 사인(signature) - 전체 MFT 스캔을 통해 인덱스를 재구성한다. 사인만에서의 손상에 기초한 최적화를 고려한다.
무효 USA 헤더와 배열 - 전체 MFT 스캔을 통해 인덱스를 재구성한다.
빈 리프(leaf) 노드를 갖는 인덱스 버퍼 - 내부 인덱스 유효화를 행한다.
인덱스 엔트리
내부 인덱스 엔트리 길이들은 엔트리 길이를 초과하여 확장된다 - 엔트리를 삭제하고, 내부 인덱스 유효화를 행하고, 그 다음, 오펀들을 탐색하는 전체 MFT 스 캔을 행한다. NTFS가 인덱스로부터 파일 참조를 회복할 수 있으면, MFT 스캔은 동작되지 않을 수 있다.
이미 존재하는 엔트리를 추가하려는 시도를 하는 것 - 이것은 아마도 논리상에서 버그를 지시할 것이다. 엔트리가 존재하는지를 보는 검사가 이미 있어야 한다. 실제 문제가 있으면, 인덱스의 내부 유효화를 하고, 그 다음, 오펀화된 엔트리들을 찾기 위한 MFT 스캔을 행하여 고친다.
NODE 값의 미스매치(mismatch) - 인덱스 버퍼 내의 모든 엔트리들은 값들을 매칭 값들이 필요하다. 전체 MFT 스캔을 통해 인덱스를 재구성한다. 버퍼의 한 엔트리의 노드 비트의 손상에 기초한 최적화를 고려한다. 현재 엔트리가 삭제될 수 있는지, 내부 유효화가 수행될 수 있는지를 또한 고려한다. 이것은 MFT 스캔이 오펀들을 찾는 동안 사용가능 상태에 인덱스를 남겨둘 것이다.
길이 0을 포함하는 무효 인덱스 엔트리 길이들 - 전체 MFT 스캔을 통해 인덱스를 재구성한다. 한 개의 악성 엔트리를 추출하기 위한 방법들을 고려한다. 이것이 리프이면, 이것은 인덱스 버켓(bucket)의 남은 엔트리들을 버리고 오펀들만을 찾는 MFT 스캔을 하여 수행될 수 있다.
기대된 인덱스 비트맵이 생략됨 - 모든 다른 인덱스 속성들이 존재하면 비트맵은 비트리를 조사하여 재구성될 수 있다. 이것이 실패하면, 전체 MFT 스캔이 필요하다.
인덱스 버퍼가 최종 엔트리만을 포함한다 - 전체 MFT 스캔으로 인덱스를 재구성한다. 비트리를 뒤섞거나, 전체 인덱스 버퍼들을 조사하고 구성되는 새 인덱 스에 엔트리들을 추가하여 제자리에 그것을 재구성하는 것에 기초한 최적화를 고려한다.
불균형의 비트리 - 전체 MFT 스캔으로 인덱스를 재구성한다. 비트리를 뒤섞거나, 전체 인덱스 버퍼들을 조사하고 구성되는 새 인덱스에 엔트리들을 추가하여 제자리에 그것을 재구성하는 것에 기초한 최적화를 고려한다.
레코드 할당 비트맵들
비트가 세트하려고 할 때 이미 세트됨 - 레코드 할당 패키지를 비초기화하고, 디스크로부터 다시 읽는다. 이 손상 비트가 레코드 할당 패키지를 재초기화하는 동일 루틴에서 발견되면 하드 오류(hard error).
비트가 삭제하려고 할 때 이미 삭제됨 - 오류는 없지만 다시 비트를 삭제한다는 로그 동작
기본 파일 레코드
기본 파일 레코드는 현재 IN-USE로 표시된 임의의 파일 레코드이다. 그것은 전체 파일 또는 파일 속성들의 일부만을 나타낼 수 있다.
속성이 파일 레코드 경계를 스팬한다 - 최종 유효 속성을 지나 SEND 속성을 삽입한다. 이것 이후에 전체 파일 유효화를 할 필요가 있다.
CheckFileRecord로부터 발견된 손상 레코드 - 각각의 속성을 유효화하고, 속성들이 정확하게 놓여 있음을 확실히 하고, 헤더 값들을 유효화한다. 그 결과가 한 개의 속성도 포함하지 않으면, 파일 레코드를 IN-USE가 아님으로 표시한다. 이것이 참조하는 파일의 내부 파일 유효화를 행한다.
세트가 안된 In-Use 비트 - 이 파일 레코드에 외부 참조들이 있으면, MFT 비트맵 비트가 세트되었는지를 검사한다. 비트가 세트되었거나 다른 지시들이 이 파일 레코드가 사용중(in-use)임을 제시하면, 그 파일 레코드의 비트를 리세트한다. 그렇지 않으면 그 레코드를 사용중이 아님으로 표시하고 내부 파일 유효화를 행한다. 필요하며 외부 파일 유효화로 확장한다.
파일 사인(signature) 손상 - 이 파일 레코드의 모든 속성들을 삭제한다. 파일이 공지되었으면 전체 파일 유효화를 행한다. 파일이 공지되지 않았으면, 이것을 참조하는 인덱스 엔트리들을 찾는 전체 스캔을 행할 필요가 있을 것이다. 발견되면, 파일의 공지된 단편들을 재구성하고 통지들을 발생시킨다. 파일 사인으로 손상을 제한하는 것에 기초한 최적화를 고려한다.
악성 파일 사인, 악성 USA 헤더, 악성 오프세트 필드들 - 이 파일 레코드의 모든 속성들을 삭제한다. 파일이 공지되었으면 전체 파일 유효화를 행한다. 파일이 공지되지 않았으면, 이것을 참조하는 인덱스 엔트리들을 찾는 전체 스캔을 할 필요가 있을 것이다. 발견되면, 공지된 파일의 단편들을 재구성하고 통지들을 발생시킨다.
악성 파일 레코드 검사 - 이 파일 레코드의 모든 속성들을 삭제한다. 파일이 공지되었으면, 전체 파일 유효화를 행한다. 파일이 공지되지 않았으면, 이것을 참조하는 인덱스 엔트리들을 찾는 전체 스캔을 할 필요가 있을 것이다. 발견되면, 공지된 파일의 단편들을 재구성하고 통지들을 발생시킨다.
완전(complete) 파일
완전 파일은 기본 파일 레코드들, 비상주 속성들에 대한 외부 할당, 및 외부 참조들 전부이다. 디스크의 대부분의 파일들은 사용자 파일들이거나 사용자 디렉토리들이다. 시스템 파일들의 특정 특징들은 다른 곳에 기재된다. 파일들과 디렉토리들은 다음 특징들을 갖는다.
MFT 비트맵은 파일의 각각의 파일 레코드에 대해 대응하는 비트 세트를 갖는다.
파일에 대한 모든 파일 레코드들은 잘 형성되고 IN-USE 비트 세트를 갖는다.
베이스(Base) 레코드는 그것의 베이스 레코드에 대해 0을 갖는다.
다른 레코드들은 베이스 레코드를 참조한다.
VIEW-INDEX 비트는 세트되지 않았다.
FILE-NAME-INDEX는 이것이 사용자 디렉토리임을 지시한다.
파일은 다음의 요구된 속성들을 갖는다($STANDARD-INFORMATION, $FILE-NAME).
$FILE-NAME은 DOS 또는 NTFS 비트와 존재하고, 다른 플래그와 대응하는 $FILE-NAME이 존재해야 한다.
사용자 파일들은 한 개의 명명되지 않은 $DATA 스트림을 가져야 한다. 사용자 디렉토리들은 다른 필수 인덱스 속성들과 함께 파일명 $INDEX-ROOT를 가져야 한다. 이들 중에 단지 하나만이 임의의 사용자 파일 또는 디렉토리에 존재할 수 있다.
다음 속성들이 존재할 수 있다($ATTRIBUTE-LIST, $OBJECT-ID, $SECURITY- DESCRIPTOR, $REPARSE, $EA-INFORMATION, $EA, 명명된 $DATA, $LOGGED-STREAM). 중복 이름들을 갖는 $DATA 스트림들은 허용되지 않을 것이다.
내부 파일 유효화는 NTFS가 베이스 파일 레코드와 속성 리스트, 존재하면, 를 조사하여 발견할 수 있는 파일 레코드들에 파일에 대한 모든 정보가 있음을 가정한다. 그것은 그 자체가 다시 이 파일로의 외부 참조들을 염두에 두지 않는다(즉, 이 파일로의 디렉토리 엔트리).
다음 레벨의 검사들은 인덱스된 속성들의 각각과 보안 참조는 유효한 대응하는 외부 데이터를 가짐을 검증한다.
외부 파일 유효화는 이 파일에 속한 파일 레코드들을 찾아 전체 MFT를 조사한다.
다음 오류들은 파일들에 고유한 것들이다.
파일이 디렉토리로서 표시되지만, $INDEX-ROOT 속성이 생략됨 - 명명되지 않은 데이터 스트림 및/또는 다른 $INDEX 속성들을 찾아서 디렉토리 비트가 부정확한지를 검사하고, 그것이 여전히 디렉토리 같으면, 빈 디렉토리를 생성하고 디렉토리의 다른 파일들에 대해 MFT를 스캔한다. 다른 $INDEX 속성들을 삭제한다.
사용자 파일을 위한 유효 링크가 없음 - 유효한 사적인 링크들이 있는지를 검사할 필요가 있다. 이름을 삽입할 필요가 있으면, 그것을 루트(root)의 FOUND 디렉토리에 넣는다.
$STANDARD-INFORMATION 속성이 없음 - 대부분의 값들은 파일의 나머지 부분으로부터 추론될 수 있다. 그것을 시간 스탬프, 속성, 및 보안을 업데이트하는 것 과 같이 다룬다.
속성이 파일에 존재하지만, 인덱스에는 없다 - 대응하는 엔트리를 인덱스에 넣는다. 인덱스에 이미 충돌하는 이름이(즉, 파일명) 있음이 가능하다. 그 경우에, 파일에 대한 링크는 'Found' 디렉토리에 생성되어야 한다.
다른 곳에서 인덱스된 기대되는 속성을 발견할 수 없다 - 가능하면, 속성이 파일의 기존 상태와 충돌하지 않는다는 가정하에 대응하는 속성을 삽입한다. 그렇지 않으면 인덱스에서 엔트리를 삭제한다. 파일에 내부 검사를 행한다.
기대되는 속성(다른 곳에서 인덱스되지 않음)을 발견할 수 없음 - 내부 파일 유효화를 행하고, SCB/FCB를 업데이트하여 변경들을 매치시킨다.
생략된 필수 속성 리스트 - 전체 외부 파일 유효화를 행한다.
긴/짧은 이름 쌍의 한 속성이 생략됨 - 오펀화된 구성원을 갖는 디렉토리를 먼저 스캔하고, 거기에 다른 하니의 이름이 존재하는지를 본다. 그렇다면, 그것을 파일에 병합시킨다. 긴 이름이 존재하고 유효한 짧은 이름이 있으면, 긴/짧은 이름의 파일명으로 변환한다. 긴 이름이 존재하고 유효한 짧은 이름이 없으면, 하나를 생성한다. 짧은 이름이 있으면, 단순히 그것을 긴/짧은 이름으로 만든다.
로그 파일 손상
로그 시작 실패
재시작 동안 읽기 실패
하드웨어 실패 vs. 데이터 손상 오류
루트
디렉토리
루트 디렉토리는 다른 디렉토리들의 모든 특징들에 추가하여 아래 특징을 더 갖는다:
그것은 그 자신을 위한 엔트리를 포함한다.
그것은 시스템 파일들 각각에 대한 엔트리를 갖는다.
그것은 SYSTEM과 HIDDEN 비트들 모두 세트시킨다.
그것 자체의 이름은 "."이다.
그것은 항상 디렉토리이다.
볼륨 비트맵
이미 세트된 비트들을 세트하려고 시도한다 - 비트들이 캐쉬된 정보로부터 오면 NTFS가 이미 재시도를 할 때, 이것은 하드(hard) 실패이다.
LCN 0을 해제하려고 시도한다 - 파일에 대한 내부 파일 유효화를 행한다. 속성이 LCN 0를 가질 수 없으면 그것을 길이 0으로 세트한다.
보안 파일
손상 서술자들(corrupt descriptors) - 백업(backup) 서술자를 검사한다. 여전히 손상되었으면, 손상 서술자를 삭제하여 매칭 파일들을 찾기 위해 MFT를 조사할 필요가 있다. 정확한 순서는 우선 MFT를 조사하고, 보안을 변경하는 것이다. 손상 서술자들의 표를 유지하고, 이 유형에 매치를 허용하지 않는다.
오펀화된 서술자들 - 삭제될 수 있지만, TXF와 그것이 이 엔트리를 필요로 하지 않는다는 확인을 할 필요가 있다.
구체적 오류들은 다음을 포함한다:
키 길이가 보안 ID 인덱스의 SECURITY-ID의 크기가 아니다.
데이터 길이가 보안 해쉬 인덱스의 SECURITY-DESCRIPTOR-HEADER의 크기가 아니다.
속성 정의 파일
$DATA 속성이 생략됨 - 속성 표를 재작성한다. 이것은 포스팅이 없이 제자리에서 수행될 수 있다. 그러나, NTFS는 먼저 수리될 필요가 있는 캐스캐이드 손상에 직면하는 이벤트에서 이것이 진행 중임을 트랙킹할 필요가 있다.
리파스 포인트 파일
리파스 포인트 파일은 한 개의 인덱스 "$R"로 구성된다. 이 인덱스는 리파스 포인트 태그들을 Ntfs 파일 ID들에 매핑한다. 파일은 모든 잘 형성된 속성들과 파일 레코드들을 가져야 한다. 리파스 포인트는 다음 특징들을 갖는다:
헤더의 VIEW-INDEX 비트가 세트된다. FILE-NAME-INDEX 비트가 세트되지 않아야 한다. SYSTEM-FILE 비트가 세트된다.
파일명은 $Reparse이고, $Extend 디렉토리에 포함된다.
그것은 청구된 할당액(quota)이 없다.
그것은 시스템/관리자 보안 서술자를 갖는다.
그것은 다음 속성들만을 갖는다($STANDARD-INFORMATION, 필요하면 $ATTRIBUTE-LIST, $FILE-NAME, $R에 대한 $INDEX-ROOT, $R에 대한 $INDEX-ALLOCATION, 및 $R에 대한 $BITMAP).
$INDEX-ROOT 속성은 이것이 뷰 인덱스이고 대조(collation) 값들이 정확함을 지시해야 한다.
내부 리파스 파일 유효화는 상술된 것들이 존재하고 단지 이들만이 존재함을 검사한다. 인덱스는 잘 형성되고 정확하게 정렬되어야 한다. 그것은 또한 $R 인덱스의 리파스 태그 키들은 유효하고 그들이 가리키는 파일 ID들은 MFT의 유효한 부분 내에 놓여있음을 유효화한다. 인덱스가 손상되었다고 알려지면(실제 수리가 진행 중임) 그 인덱스를 액세스하기 위한 요구들은 블럭킹되거나 실패할 것이다. 유효화가 진행중이지만 손상이 전혀 발견되지 않았으면, 그 인덱스를 액세스하기 위한 요구들은 정상적 동기화 제한하에서 진행될 것이다.
검사의 다음 레벨은 인덱스의 각각의 엔트리를 취하여 참조된 파일 ID가 실제로 사용중의 사용자 파일인지 및 그것이 대응하는 리파스 속성을 갖고 그 속성은 유효 리파스 포인트를 포함하는지를 검증할 것이다. 파일의 리파스 태그는 리파스 포인트의 태그와 매치해야 하고, SR 인덱스의 태그와 매치해야 한다.
검사의 최종 레벨은 인덱스에서 대응하는 엔트리들을 갖지 않는 파일들의 오펀화된 리파스 포인트 속성들을 찾는 전체 MFT 스캔이다.
다음 오류들은 적절한 수리와 함께 $Reparse 파일에 고유한 것들이다:
$Reparse 파일의 대응하는 엔트리를 발견할 수 없음 - 오펀화된 리파스 포인트를 갖는 파일의 내부 유효화를 행한다. 그 다음, $Reparse 파일의 내부 유효화를 행한다. 마지막으로 필요하면 리파스 포인트를 리파스 인덱스에 삽입한다.
페이징
파일들
페이징 파일에 IO를 수행하는 임의의 실패는 시스템에 치명적일 수 있다. 여기서 수행될 수 있는 수리들이 제한되어 있다.
완전히 로드되지 않은 매핑 쌍들 - 현재 요구를 실패하고, 작업 항목을 포스트한다. 파일의 내부 유효화를 행하고, 그 다음, 디스크로부터 MCB로 할당 정보를 조심스럽게 로드한다. 이것은 시스템이 실패하게 할 수 있다.
MFT
구성
파일 레코드 0이 이용가능하도록 나타난다 - MFT 비트맵을 재구성하기 위해 MFT 스캔을 행한다.
MFT의 홀(hole)의 참조 - 홀에 대한 클러스터들을 생성한다. 초기화되지 않은 파일 레코드들을 가리키는 임의의 파일을 유효화한다.
MFT
와
MCB
의
MFT
매핑
제1 매핑을 발견할 수 없음 - MFT와 미러(mirror) 모두의 초기 파일 레코드를 읽어서 매핑을 검증한다. 유효한 엔트리들을 발견하지 못하면, 전체 디스크 스캔을 행한다.
MFT
비트맵
$BITMAP이 존재하지 않는다 - MFT 스캔을 행하고 비트맵을 재구성한다. 이것을 $MFT 파일에 삽입한다.
실패한 취소
실패한 취소는 볼륨을 손상에 남아있게 할 수 있다. 트랜잭션에 관련된 개별 스트림들은 식별될 수 있으면, 그들에게만 수리 스캔을 실행시키는 것은 가능할 것이다. 그렇지 않으면 전체 볼륨 스캔을 하는 것이 필요할 것이다. 일부 오류들 은 사용자가 다시 그들을 액세스할 때 NTFS가 그 문제를 탐지하므로 무시하는 것이 안전할 것이다.
다음의 특정 오류들은 취소를 프로세싱할 때 발생할 수 있다.
무효한 로그 레코드 검사
재시작 실패
재시작 실행의 실패는 볼륨을 무효 상태에 남아 있게 할 것이다. NTFS는 설치를 완료하지만 볼륨을 더티로 표시하여 두거나 전체 볼륨 수리를 스케쥴링하여 이것을 회복할 수 있다. 또한 단순히 볼륨을 손상 상태에 남겨두고, 개별 오류들이 탐지되고 직면되었을 때 고쳐지도록 하는 것이 가능하다.
재시작 상태의 초기화
다음 특정 오류들은 재시작 상태를 초기화할 때 발생할 수 있다:
로그의 LFS 구조들의 내부 불일치. LFS는 현재 이들 경우들에서 손상 상태를 발생시킨다.
NTFS 재시작 레코드를 읽는 오류.
NTFS 재시작 레코드의 재시작 표들에 대한 로그 레코드들 중의 임의의 것을 읽는 오류.
디스크에 작성된 재시작 표들 중의 임의의 것에 대한 무효한 NTFS 레코드 헤더.
로그 레코드 내에 작성된 재시작 표들의 손상
속성 이름 엔트리는 기반되는 열린 속성 엔트리에 대한 무효한 인덱스를 갖 는다.
분석 패스(pass)의 실행
다음 특정 오류들은 분석 패스를 실행할 때 발생할 수 있다: 디스크로부터 로그 레코드를 읽기 실패. 디스크로부터 읽힌 무효한 로그 레코드.
더티
(dirty) 페이지 표의 초기화
다음의 특정 오류들은 더티 페이지 표를 초기화할 때 발생할 수 있다:
더티 페이지 엔트리는 무효한 속성 인덱스를 참조한다.
더티 페이지 엔트리는 존재하지 않는 속성을 참조한다.
재시도 패스(redo pass)의 실행
다음 특정 오류들은 재시도 패스를 실행할 때 발생할 수 있다:
디스크로부터 로그 레코드를 읽기 실패.
디스크로부터 읽힌 무효 로그 레코드.
로그 레코드는 무효 속성 인덱스를 참조한다.
로그 레코드는 대응하는 속성이 존재하지 않는 속성 인덱스를 참조한다.
여기에 구조적 구현을 기재한다. 추가 손상이 발견되면 락킹(locking)과 액션들을 포함한다.
로깅(logging) 변경의 가장 간단한 방법은 전체 파일 레코드들, 인덱스 버퍼들, 비상주 속성들을 로그하는 것이다.
인덱스가 재구성 중이면, 그것의 엔트리들은 유효한 것으로 취급될 수 있다. 정상적 프로세싱에서 오펀이 발견되면, 그것은 전체 스캔이 진행되는 동일 시간에 단순히 추가될 수 있다. 그러나, 한편 사용자 생성된 엔트리들이 추가되는 것을 블럭킹해야 한다.
MFT
재구성
전체 MFT 재구성은 MFT 파일 레코드들을 탐색하는 볼륨 상에 클러스터들의 전체 스캔을 하는 것과 관련된다.
NTFS는 언제 이 탐색이 일어날 수 있는지 및 어떤 '파일 레코드들'이 인식될 것인지에 대한 다수의 제한사항들을 부가할 것이다. 다른 NTFS 볼륨의 이미지가 현재 볼륨에 파일로서 저장될 때 NTFS는 한 상황에 직면하게 될 것이다. 또한, 현재 볼륨은 디프래그(defrag) 동작들로부터 스냅샷 정보 또는 상한 MFT 레코드들을 포함할 수 있다.
볼륨들은 NTFS 버젼 4.0 볼륨들 이후의 버젼들이어야 한다. 이것은 새 파일 레코드들이 항상 헤더에 구현된 파일 레코드 수를 가질 것임을 의미한다.
NTFS는 정확한 파일 레코드 수와 볼륨 식별자를 각각의 사용중의 파일 레코드에 저장하기 위해 업그래드 프로세스의 일부로서 스캔을 완료할 것이다. 일단 이 스캔이 완료되면, 플래그(flag)는 전체 MFT 재구성이 가능함을 지시하기 위해 볼륨 DASD 파일 레코드에 세트된다.
MFT 재구성은 다음 단계들로 구성된다:
NTFS를 파일 시스템 유형으로서 식별하는 부트 섹터 유효화. 주목 - 클러스터 크기가 부트 섹터로부터 결정될 수 없으면, NTFS는 디폴트 크기에 기초하여 매핑을 구성해야 할 것이고, 나중에 실제 클러스터 크기를 결정할 것이다. 백업 부 트 섹터는 초기 인식 단계에서 사용되어 가능한 검증 또는 MFT 위치와 클러스터 크기들의 정확한 백업 복사본을 제공하기 위해 사용될 수 있다.
부트 섹터에 의해 지시되는 MFT 레코드들을 통해 전체 매핑 쌍들을 구성하려는 시도를 한다. MFT가 이 방식으로 재구성될 수 없으면, 이것은 아무것도 발견되지 않은 것으로의 결과를 가져올 수 있다. 이것은 NTFS가 무(scratch)에서부터 MFT를 재구성하는 경우에 기대되는 오류이다.
매핑 쌍들이 상술된 단계로부터 불완전하면 디스크 스캔을 시작한다. 가능한 파일 레코드들을 찾는 디스크 읽기를 시작한다. 잠재적 파일 레코드의 USA 사인, 파일 레코드 수, 및 볼륨 식별자가 사용된다. 가능한 오류들은 다음을 포함할 것이다:
NTFS가 이들 레코드들에 도달하면, 그것은 그들을 볼륨 식별자 필드에 의해 볼륨 후보자들로 그룹화할 것이다. 그것은 가능한 볼륨들의 개별 복사본들을 구성할 것이고, 가능할 때 그들을 없앨 것이다. 각각의 레코드가 발견되면, 디폴트 클 러스터 크기를 사용하는 그것의 위치는 그 볼륨 식별자에 대한 MCB에 저장된다. 충돌의 이벤트에서(MCB의 그 위치에 이미 엔트리가 있음), NTFS는 페이지의 LSN을 조사하여 더 높은 LSN을 갖는 페이지를 사용할 것이다. MFT 미러의 파일 레코드들은 유효한 것으로 나타날 것이지만, 그들이 MFT의 일부라고 가정할 때 잘못된 위치에 상주하게 될 것이다. NTFS는 이 지점에 도달한 각각의 후보 볼륨의 처음 0x10 파일 레코드들에 대한 매핑들의 2개의 복사본들을 유지할 것이다. MFT 자체를 기재하는 파일 레코드를 만나면, NTFS는 $DATA 속성들을 찾는 파일 레코드를 스캔할 것이고, 개별 MCB에서 발견된 부분 매핑을 기억할 것이다.
볼륨 스캔을 완료하면, NTFS는 해결할 복수의 볼륨 후보들을 가질 것이다. 각각의 후보에 대해, NTFS는 볼륨 스캔으로부터 다음을 저장한다:
그 다음, NTFS는 이들 후보들의 각각을 분석하여 이 볼륨에 대해 실제 MFT일 수 있는 이것들을 발견할 필요가 있다. NTFS가 MFT나 MFT 미러에 대한 파일 레코드를 발견할 수 있었다면, 그들은 그들 자체의 매핑 쌍들에 의해 기재된 오프세트에 있는지를 유효화할 수 있다. 이것은 인증의 제1 레벨이다. 단지 한 개의 볼륨 후보만이 존재하면, NTFS는 발견된 모든 유효한 파일 레코드들은 그 볼륨에 속한다고 가정할 수 있다.
MFT 또는 시스템 파일들의 일부를 재구성하는 동안, NTFS는 이용가능한 프리(free) 클러스터들에 대한 일부 정보가 필요할 수 있다. 볼륨 비트맵 스트림에 유효한 $DATA 속성이 있지 않는 시간에 한 지점에 있을 수 있다. 볼륨의 크기는 메모리에 비트맵의 전체 복사본을 저장하는 것을 불가능하도록 할 수 있다. 대신에, NTFS는 공지된 파일 레코드들을 스캔할 수 있고, 볼륨 비트맵의 서브세트에 속하는 할당된 클러스터들을 찾을 수 있다. 이 부분 정보는 MFT, 볼륨 비트맵, 및 로그 파일에 새 클러스터들을 할당하기 위해 사용될 수 있다.
충분한 프리 클러스터들을 할당하여 MFT의 임의의 홀들을 채운다. 이들 클러스터들을 MFT에 대한 매핑 정보에 추가하고, 비초기화된 파일 레코드들로 실제 클러스터들을 초기화시킨다.
MFT
비트맵 재구성
MFT 비트맵 속성이 유실되면, NTFS는 무에서 그것을 재구성할 수 있다. MFT에 대한 매핑 쌍들을 구성하는 NTFS 스캔이 되어진 후에 이것은 수행될 것이다. MFT 비트맵에 속하는 클러스터들이 유실되는 이벤트에서, NTFS는 다음 단계들을 취한다.
MFT 비트맵은 전체 온라인 chkdsk의 스캔의 일부로서, 이제 정상적 검증 패스를 위해 준비가 된다.
MFT
미러
재구성
MFT 미러 파일이 유실되면, 그것은 MFT가 완전히 재구성된 후에 MFT로부터 재구성된다.
로그파일 재구성
NTFS 로그파일은 NTFS 메타데이터를 수정할 때 사용된다. 로그파일은 초기화되어 로깅을 필요로하는 수리들을 할 때 이용가능할 필요가 있다. 로그파일이 손상되면, 그것은 그 로그를 사용하는 임의의 수리들을 진행하기 전에 수리되어야 한다. 필요한 것은 로그를 위한 매핑 정보와 디스크 상의 유용한 위치로의 SCB 포인트임을 주목한다. 로그를 위한 파일 레코드는 이것 이후에 수리될 수 있다.
로그 파일에 여러 유형들의 손상이 있다. 이들은 내부적 및 외부적 모두 일 수 있다:
로그파일을 기재하는 손상된 메타데이터(외부) - 이것은 NTFS가 로그파일에 대한 파일 레코드를 유실하거나 그 로그를 기재하는 메타데이터가 손상될 때이다. 이들 각각의 경우에, NTFS는 로그파일을 위해 사용하기 위한 충분한 클러스터들을 발견할 필요가 있다. 그 다음, NTFS는 이 매핑으로 Scb를 구성하고, 로그를 위해 클러스터들을 초기화한다.
로그파일 내의 손상된 데이터(내부) - 이것이 설치 또는 재시작 중에 발생하면, NTFS는 전체 로그를 손상된 것으로 취급할 수 있고, 그것을 재초기화시킨다. 볼륨이 이미 활성화되었으면, NTFS는 오류를 무시할 수 있지만, 현재 트랜잭션의 일부인 임의의 파일을 손상된 것으로 표시하여 그들에 검증 스캔을 수행한다.
로그 파일의 재초기화는 다음과 관련이 있다:
전체 볼륨 수리
이것은 chkdsk가 현재 수행하는 전체 스캔에 대응한다.
볼륨 이용성(availability)
관리자가 설치된 볼륨에 이 요구를 시작하는 경우들에서 NTFS 볼륨은 가능한 정도까지 이용가능할 것이다. NTFS가 설치 경로에 심각한 손상을 탐지하는 경우들에서, 설치는 볼륨이 사용가능한 상태에 있을 때까지 블럭킹할 수 있다.
사용자가 임의의 수리 스캔이 진행중인 볼륨에서 활성화되면, 그는 그의 동작이 완료되는 것을 막는 손상에 직면할 수 있다. 이용가능한 대책이 있으면 사용자 요구는 완료될 수 있다. 그렇지 않으면, 그의 요구는 전체 스캔 뒤에서 블럭킹될 것이다.
초기 상태
NTFS는 전체 스캔을 수행하기 위해 특정 자원들을 가져야 한다. 다음 것들은 전체 스캔이 시작될 수 있기 전에 제자리에 있어야 한다:
초기
MFT
스캔(들)
NTFS는 매핑 쌍들에 의해 기재된 MFT 레코드들을 통해 스캔한다. NTFS가 얼마나 많은 정보를 메모리에 보유할 수 있는지의 제한들 때문에 여러 번의 패스들을 하는 것이 필요할 것이다. 제1 스캔은 각각의 파일 레코드에 대해 상세한 작업을 행할 것이다. 후속 스캔들은 필요한 정보의 유형에 적합한 데이터를 찾는 각각의 MFT 레코드를 통해 조사할 필요만이 있어야 한다. 이 단계의 결론으로서, 다음의 것들은 사실이어야 한다:
MFT 비트맵이 MFT의 파일 레코드들의 상태에 대응함을 검증한다. 이것은 모든 IN-USE 파일 레코드들 및 손상되었을 수 있는 요구된 시스템 파일 레코드들에 대한 비트들이 MFT 비트맵에서 세트됨을 의미한다. 이것은 MFT 비트맵의 크기에 따라 복수 스캔들에서 수행될 필요가 있을 것이다.
속성들의 내용이 여전히 정확하지 않을 수 있지만, 시스템 파일들은 기본 적으로 요구된 속성들을 포함한다. 그 시스템 파일들에 대한 무효한 속성들이 존재하면 삭제된다(즉, MFT는 EA들을 갖지 않음).
파일들은 내부적으로 일관적이다. 이것은 DOS 스타일 파일 속성들이 개별 속성들에의 NTFS 속성 비트들과 매치함을 의미한다. EA와 리파스 비트들은 이들 속성들의 내용과 매치하고, EA와 EA-INFORMATION은 일관적이다.
할당된 클러스터들의 정확한 스냅샷은 볼륨 비트맵에 반영된다. 이것은 단지 전체 비트맵의 부분범위일 수 있다. 이것은 전체 비트맵을 재구성하기 위해 MFT를 통해 여러개의 패스들을 택할 수 있다.
인덱스 수리 스캔
이것은 INDEX 비트가 세트된 기본 파일 레코드들을 찾아서 MFT를 조사하는 것과 관련있다. 그 다음, 인덱스들은 유효화된다. 이 스캔 후에, 다음의 것들이 사실이어야 한다:
오펀
스캔
NTFS가 상술한 전체 볼륨 스캔을 행하면서 인덱스된 속성들의 카운트를 유지할 것이다. 인덱스들이 유효화되면, 개별 엔트리들이 인덱스에서 직면되면 카운트가 감소된다. 사용자가 이 시스템에서 활성화되고 인덱스에 엔트리들을 추가하면, 전체 인덱스 카운트는 정확하게 바이어스(bias)될 필요가 있음을 주목한다. 전체 인덱스 스캔은 인덱스들을 찾아 순차적으로 MFT를 조사하여 통과한다. 이것은 NTFS가 모든 인덱스 엔트리들이 유효화된 지점을 유지할 수 있음을 의미한다. 사용자가 MFT에서 초기에 디렉토리를 변경시키면, 인덱스 카운트는 업데이트할 필요가 없다. 그들이 이 지점 이후에 디렉토리의 엔트리들을 변경하면, 인덱스 카운트는 수행되는 동작에 따라 증가하거나 감소할 필요가 있다.
이 스캔은 상술된 처음 2개의 스캔들 이후에 남아있는 미해결된 인덱스된 속 성들이 있기만 하면 필요된다. 이것은 MFT를 다시 조사하는 것 및 인덱스된 속성들을 탐색하는 것과 관련된다. 발견된 각각의 엔트리에 대해, NTFS는 관련 인덱스를 살필 것이고 대응하는 인덱스 엔트리가 있음을 검증할 것이다. NTFS가 오펀들의 매치하는 수를 발견하는 지점에서 이 스캔은 단절될 수 있다.
시스템에서 활성화된 사용자는 또한 오펀을 만날 수 있다. 예를 들어, 삭제 파일 동작 중에, NTFS는 대응하는 인덱스 엔트리가 없이 속성을 발견할 수 있을 것이다. 전체 볼륨 스캔이 진행중이면, 오펀화된 속성은 삭제될 수 있고 볼륨 스캔에 의해 유지되는 인덱스된 속성들의 카운트는 감소될 수 있다.
NTFS는 이 릴리스(release)에 대한 버젼 번호에 대면하게 될 것이다. 후방 호환적(backwards compatible) NTFS는 서비스 팩이 WinXP 시스템으로 업그래이드하면서 가능하게 될 것이다. 후방 호환적 NTFS는 버젼 업그래이드 때문에 변경들을 지원할 것이고, WinXP 시스템에 부트될 때 볼륨을 일관성있게 유지시킬 것이다. 이 릴리스에 대한 온-디스크 버젼으로의 변경들은 다음을 포함한다:
볼륨 DASD 파일 레코드에 저장된 새 버젼 번호.
파일 레코드 헤더에 파일 레코드 번호를 포함하기 위해 모든 파일 레코드들을 업데이트하는 시도를 하기 위해 초기 스캔이 수행된다. 속성 리스트 제한사항들 또는 디스크 공간의 부족은 일부 볼륨들에 대해 이것이 불가능하도록 할 것이다. 볼륨 DSAD 파일 레코드의 플래그는 스캔이 완료되었음을 지시할 것이다.
볼륨과 연관되는 유일한 식별자는, 또한 볼륨 DASD 파일 레코드 및 모든 파일 레코드들의 헤더에 저장된다. 이것은 MFT 레코드들에 대한 전체 볼륨 스캔이 주어진 볼륨에 속하는 레코드들을 정확하게 위치파악하도록 할 것이다. 이것은 그들이 볼륨의 파일 내에 포함된 다른 볼륨의 디스크 이미지 또는 이 볼륨의 스냅샷일 수 있는 경우를 처리할 것이다. 볼륨 DASD 파일 레코드가 유실되면, MFT 자체에 대한 파일 레코드들이 그들 자체의 매핑 정보를 가짐을 주목하여 NTFS는 모순들을 해결하려는 시도를 할 수 있다. 복수의 MFT 파일 이미지들이 볼륨 상에 존재하면, 그들 중 단지 하나만이 그 자체의 매핑에 따라 정확하게 위치될 수 있다.
Chkdsk(온라인과 오프라인)는 버젼 번호가 알려진 버젼 번호를 초과했다면 디스크 상의 속성 정의 표를 존중할 것이다. 통상적으로 이것은 부(minor) 버젼 번호가 주(major) 버젼 번호로서 드물게 진급됨을 의미한다.
ChkDsk
관련
Fsctrls
현재 수리가 종료되기를 기다린다.
현재 수리가 무엇인가
현재 수리가 얼마나 멀었나
현재 수리를 죽인다
현재 및 계류중의 수리를 죽인다
스캔을 시작한다(어떤 레벨의 스캔, RO또는 W)
ChkDsk
관련 상태 코드들
수리가 진행중이므로 동작이 실패됨
손상이 탐지되었으므로 동작이 실패됨
수리하는 파일이 현재 핸들이 무효화되도록 하였으므로 동작이 실패됨
장기 스캔이 실행되는 동안 STATUS-CORRUPT가 리턴되지만 사용자 핸들은 스캔의 끝에 유효할 것인 (가능한) 일시적 오류와, 사용자의 핸들이 발견된 손상과 후속되는 수리 때문에 유효화되지는 않을 것임을 지시하는 STATUS-CORRUPT와는 구별하는 것이 중요하다.
등록 세팅
손상을 보고하지만, 사용자가 시작할 때까지 온-라인 chkdsk를 실행시키지 않는다. 이 방식으로, 여전히 존재하는 임의의 유효 파일들/디렉토리들에 시스템 다운(down) 시간이 전혀 없다.
수리 동작을 실행하는 스레드
NTFS는 전용 작업자 스레드를 시작하여 수리 동작을 수행할 것이다. 이것은 그것이 수리 작업 항목들을 갖는 IrpContext를 삭제하는 지점에서 수행될 것이다. 스레드는 주요 작업자 큐에 의해 사용되는 ExWorker 스레드들과 동일한 우선권으로 실행할 것이다. 스레드가 이미 스케쥴링되었거나 새 스레드를 스케쥴링하기 전에 실행하는지를 NTFS는 검사할 것이다.
작업자 스레드의 스케쥴링이 실패하면, NTFS는 큐된 작업 항목들을 갖지만 실행 중의 스레드를 갖지는 않는다. NTFS는 수리 스레드를 성공적으로 스케쥴링한 후에 NtfsData 플래그를 세트할 것이고, NTFS가 작업 항목들이 있지만 실행중의 수리 스레드는 없음을 탐지하면 각각의 퍼지(fuzzy) 검사점 간격 동안 스레드를 스케쥴하기 위한 시도를 계속할 것이다.
NTFS는 전체 작업 큐에 큐된 수리 항목들의 카운트를 사용하여 작업자 스레드가 스케쥴될 필요가 있는지를 판정할 것이다. 이 값은 작업 항목들이 큐되기 전에 증가되고, 작업 항목이 완료된 후에 감소된다. 0에서 1로의 천이는 스레드가 그 값을 증가시키는 스레드에 의해 시작되어야 함을 지시한다. 1에서 0으로의 천이는 현재 수리 스레드가 존재할 수 있음을 지시하고, 그 값을 조정하고 이전 상태를 테스트하는 인터락(interlock)된 동작은 필요한 스레드가 변하는지를 판정하기 위해 사용될 수 있다.
수리 큐를 계류 중인
NtfsData
NTFS는 큐를 사용하여 새 작업 항목들을 포스트하고 계류중의 작업을 구성할 것이다.
첫번째로, 그것은 작업 항목들이 초기에 포스트되는 위치이다. 이들 작업 항목들은 발견된 손상 및 수행할 수리 작업 유형의 가능한 힌트를 기재한다. 작업 항목들은 언제 손상이 탐지되고 포스트되는지에 기초하여 순서화된다. 또한 언제 손상이 탐지되었는지를 지시하는 작업 항목의 순서 번호가 있다. 작업 항목들은 초기에 이 큐의 첫머리에 큐된다.
큐의 두번째 사용은 어떤 다른 동작이 종료될 때까지 블럭킹되는 수리 동작들을 유지하는 것이다. 작업 항목은 어떤 다른 수리가 큐의 끝에 큐되는 것을 기 다리면서 블럭킹된다. 또한, 이 새 수리가 원래 작업 항목의 모든 손상을 고칠 것이면 블럭킹된 작업 항목에의 먼저 완료할 새 작업 항목으로의 참조가 있다. 예를 들어, 파일이 유효화되고 있음을 고려하고, 속성 리스트가 손상되고 유실됨을 발견한다. 주어진 파일에 속하는 모든 파일 레코드들을 찾는 전체 MFT 스캔이 있을 때까지 파일 수리는 지연될 필요가 있다. 초기 작업 항목은 종속적 수리가 수행될 동안 작업 리스트에 재큐잉될 것이다.
작업 항목이 완료될 때, NTFS 수리 스레드는 지금 완료된 수리의 부작용으로서 완료될 수 있는 항목들의 작업 큐를 조사할 것이다. 이것은 지금 완료된 작업 항목들을 참조하는 엔트리들을 찾는 리스트를 트래버스하여 수행된다. 이 스캔 동안, NTFS는 또한 방금 수리되어 연관된 작업 항목들을 또한 완료시킨 동일 객체에서 탐지된 다른 손상들을 찾을 것이다. 파일의 수리가 진행 중인 동안, 파일의 다른 속성에서 발견된 독립적 손상이 있음을 고려한다. 파일 유효화가 완료될 때, 모든 속성들이 정확함은 사실이어야 한다. 파일의 다른 작업 항목을 시작할 아무런 이유가 없다. NTFS는 수리 항목들과 연계된 순서 번호들을 사용하여 새 손상이 파일 수리가 완료된 후에 발견되었는지를 판정한다.
수리 동기화의 종료
작업 항목이 완료되었을 때, 작업 항목의 이벤트, 존재하면, 가 신호된다. 이벤트를 신호한 후에, 수리 스레드는 작업 항목의 참조 카운트를 감소시킬 것이고, 그것이 0으로 천이되면, 그것은 그 작업 항목을 삭제할 것이다. 이벤트에서 대기 중인 사용자 스레드는 또한 작업 항목의 참조 카운트를 감소시킬 것이다. 카운트가 이 시점에 0이 되면, 그것은 작업 항목을 삭제하는 것에 책임이 있는 사용자 스레드이다.
사용자
IRP
또는 사용자 스레드의 취소
사용자 스레드가 실행될 수 있기 전에 완료할 수리 동작을 기다려야 하는 사용자 스레드가 있을 수 있다. NTFS의 최상위 레벨에서, 우리는 작업 항목의 통지 이벤트를 통해 수리 동작을 기다릴 수 있다. NTFS는 커널 모드 APC들을 블럭킹하지 않고 기다려야 하고, 사용자는 스레드 또는 현재 IRP를 취소할 수 있다. 이벤트를 기다리는 동안 리턴된 상태 코드가 시스템이 현재 스레드를 죽이고 있음을 지시하면, NTFS는 STATUS-FILE-CORRUPT-ERROR로 현재 IRP를 완료할 수 있다. NTFS는 전략을 사용하여 취소 IRP와 동기화할 것이다. 이것은 또한 수리 작업 항목의 참조 카운트를 감소시킬 것이고, 카운트가 0이 되면 그것을 삭제할 수 있다.
NTFS는 또한 수리 동작이 취소되기 위해 진행중인 동안 홀드되는 임의의 IRP가 취소되도록 할 것이다. NTFS는 IrpSp 정보 필드를 사용하여 이 IRP의 취소를 수신함을 지시할 것이고, 작업 항목 통지 이벤트를 기다리는 지점보다는 취소 루틴에서 IRP를 완료할 것이다.
수리 작업의 취소
자체수리 NTFS는 단편들로 임의의 수리를 수행할 것이다. 그것은 확장된 시간 동안 자원들을 홀딩하여 시스템에서 임의의 중요한 타임아웃을 트리거(trigger)하기를 원하지 않을 것이다. 그것은 다음에 무슨 작업을 할지를 알기 위해 현재 작업 항목에 상태 정보를 유지할 것이다. 작업의 각각의 할당량의 시작에서, 그것 은 현재 작업 항목이 취소되어야 하는지 또는 수리되고 있는 볼륨이 설치제거되었는지를 사용자가 지시하였는지를 검사할 것이다. 이들 중의 하나가 사실이면, 수리 스레드는 지시된 임의의 다른 수리와 함께 현재 수리를 취소할 것이다. 그 다음, NTFS는 각각의 작업 항목을 프로세스하고, 그 수리와 연관된 임의의 IRP의 완료와 함께 통지 이벤트를 신호할 것이다.
실행 시스템에서의 손상 탐지
손상이 탐지되는 시간에, NTFS는 수리 작업 항목을 할당하고, 그것을 손상의 세부사항들로 초기화할 것이다. 작업 항목은 최상위 레벨 IrpContext에 첨부된다. 이것은 스레드 스택 컨텍스트들의 체인을 조사할 것을 필요로할 것이다. 이것은 수리가 사용자를 대신하여 발행된 Irp와 연관될 필요가 있을 것이므로 수행된다. IO 스택은 최상위 레벨 요구가 발생하는 지점으로 언와인드할 필요가 있다. 손상이 탐지되면, NTFS는 그것을 위해 이미 포스트된 작업 항목이 있는지를 검사할 필요가 있을 것이다. 이것은 손상과 관련된 FCB 또는 SCB의 상태 모두를 검사하여 이 손상을 커버하는 포스트된 작업 항목이 이미 존재하는지를 보는 것을 의미한다.
수리 작업 항목
NTFS는 전체 리스트에의 작업 항목들의 소수를 유지하여 할당들이 INSUFFICIENT-RESOURCES 때문에 실패하는 경우를 처리할 것이다. 작업 항목들은 구조에 다음 필드들을 가질 것이다:
NotificationEvent - 임의의 대기 스레드에게 이 수리 작업이 완료되었음을 신호하기 위해 사용됨.
ReferenceCount - 이 작업 항목이 여전히 존재하는 이유들의 수를 지시한다. 이 값은 초기에 1이나 2로 세트된다. 한 개의 참조는 작업자 스레드에 의해 수행되어야 하는 수리 작업 때문이다. 다른 참조는 완료될 작업 항목을 기다릴 스레드가 있으면 세트된다. 작업 스레드는 상술된 NotificationEvent를 신호한 후에 참조 카운트를 감소시킨다. 대기 스레드, 존재하면, 는 그것이 더 이상 수리를 기다리지 않는 지점에서(수리가 완료되었거나 대기 스레드가 취소됨) 이 참조를 감소시킬 것이다. 어느 스레드가 참조 카운트를 0으로 천이시켰든지 간에 작업 항목의 삭제에 책임이 있을 것이다.
FileReference - 이것은 어떤 파일이 실제로 손상되었는지를 지시한다. MAXULONGLONG의 값은 이것이 수리되고 있는 파일 손상이 아님을 지시한다. 값이 MAXULONGLONG이 아니면, 이 파일에 대한 FCB는 그것이 메모리를 떠나는 것을 막기 위해 참조를 가질 것이다.
FileRecordReference - 이것은 어떤 파일 레코드가 실제로 손상되었는지를 지시한다. MAXULONGLONG의 값은 알려진 손상 파일 레코드가 전혀 없음을 지시한다.
AttributeOffset - 이것은 FileRecord 이상이 손상된 FileRecord의 오프세트이다. 0의 값은 알려진 손상된 속성이 없음을 지시한다. 그것은 검사될 필요가 있는 속성이 없음을 의미하는 것은 아니다. 예를 들어, NTFS는 속성이 생략됨을 속성이 생략됨을 발견한다.
AttributeTypeCode - 검사될 필요가 있는 속성 유형 코드를 지시한다.
AttributeName - 검사될 필요가 있는 속성의 이름에 대한 UNICODE 스트링.
NTSTATUS - 수리가 성공적으로 완료되었는지를 지시하는 상태.
IRP - 이것은 수리 동작을 시작하기 위해 사용자에 의해 발생되는 IRP이다. 그것은 또한 손상이 탐지된 시간에 프로세스되고 있는 IRP일 수 있다. 아래의 플래그 필드의 정보는 어떤 경우가 이것인지를 지시할 것이다. 제1 경우에, IRP는 수리가 완료된 후에 완료될 것이다. 제2 경우에, IRP는 수리가 완료된 후에 재시도된다. 이 제2 경우가 사용되는 시간은 NTFS가 사용자에게 STATUS PENDING을 이미 리턴했을 때만이고, IRP는 이 경우에 ExWorkerThread에 표시되어야 할 것이다. NTFS는 취소 IRP spinlock과 직렬화하여, 그것이 사용자 액션에 의해 취소되지 않았다는 가정하에, 이것을 완료할 것이다.
Flags - 수행할 수리에 대한 더 많은 세부사항들을 지시함. 또한, IRP가(존재하면) 통지를 위한 것인지 또는 재발생되기 위한 것인지를 지시한다. 통지 Irp는 스캔을 시작하기 위해 사용자에 의해 발생된다.
LIST-ENTRY - 작업 항목들의 전체 큐.
RelatedWorkItem - 존재하면, 일단 RelatedWorkItem이 완료되면 이 작업 항목이 완료될 수 있음을 지시한다. RelatedWorkItem은 이 작업 항목을 프로세싱하는 동안 발견된 손상의 결과로서 생성된다.
SequenceNumber - 이 작업 항목과 연관된 숫자. 손상이 수리가 완료된 후에발견되는지의 날짜 표시를 위해 사용된다.
치명적이지 않은 손상들
일부 경우들에서, NTFS는 손상들을 발견할 것이지만, 수리가 완료될 때까지 현재 요구의 완료를 지연할 필요가 없을 것이다. 이 경우에, NTFS는 작업 항목을 생성하여 최상위 레벨에 포스트할 것이지만, 현재 요구를 프로세싱하기를 계속할 수 있다. 이것은 수리가 수행되는 동안에 손상을 대처하는 전략이 있는 경우들일 것이다. 대처가 인라인(in-line)으로 시작될 수 있으면, 현재 요구는 수리 작업 항목을 최상위 레벨 IRP-CONTEXT에 첨부한 후에 계속할 수 있다. 본 명세서의 예는 손상된 보안 서술자이다. 수리 항목이 생성될 수 있지만, 현재 요구는 수리가 완료될 때까지 현재 파일에 대한 SYSTEM/ADMIN 서술자를 사용할 것이다.
제자리 수리
일부 수리들은 최상위 레벨 스레드에 작업 항목을 포스트하는 것을 요구하지 않는다. 일부 수리들은 현재 실행 중인 동작 내에서 수행될 수 있다. 예를 들어, NTFS가 볼륨 $BITMAP의 일 비트를 해제하려고 하고 그 비트가 이미 해제됨을 발견하면, 그 작업을 포스트할 필요가 전혀 없다. 자체수리 NTFS의 초기 버젼은 최적화보다 간단한 모델에 호의적이어서, 수리가 인라인으로 수행될 수 있을지라도 포스트하기를 선택할 수 있다.
사용자가 시작한 수리
NTFS는 실제 작업을 수행하기 위해 작업자 스레드에 큐되는 작업 항목을 생성할 것이다. 본 명세서에서 사용자 요구 및 사용자 스레드는 수리 동작과 인터랙트하는 일반 사용자 요구에 대해 동일 대기 기술을 사용할 것이다.
FileID
핸들들에
의한 열림
열린 파일에 대한 모든 핸들들(및 CCB들)을 찾기 위해, 우리는 또한 FileID 또는 ObjectID에 의해 열린 것들을 발견할 필요가 있을 것이다. CCB들은 열린 것들을 지원하는 SCB에서 떨어져서 큐된다. NTFS는 무효화시키기 위해 CCB들을 찾는 특정 파일들에 대한 특정 스트림 또는 전체 스트림들을 위해 CCB들을 조사할 것이다.
고려사항들의 테스트
동시 수리 작업들
NTFS는 개별 스레드들에서 동시에 손상들을 발견할 것이다. 자체수리 NTFS의 초기 버젼은 수리들을 한 개의 작업 큐에 포스트하여, 필요하면 스펀된 전용 스 레드에서 그들을 프로세스할 것이다. 자체수리 NTFS의 미래 버젼들은 이들 수리 동작들이 개별 스레드들에서, 특히 손상이 탐지되는 시간에 사용자를 대표하여 실행하는 스레드에서 실행하도록 할 것이다. 이 전략은 제한된 범위를 갖는 수리들에게만 적절하다. 사용자가 그의 요구를 취소시키거나 응용 프로그램과 연관된 스레드를 죽이기를 원하지만, 그래도 수리 동작은 실제로 완료되기 위해 실행할 필요가 있으므로, 장기 실행 수리 동작들을 전용 스레드에 포스트하는 것은 합리적이다.
수리 작업 큐와 작업 항목들을 프로세스하는 루틴들은 일부 미래 버젼에서 동시 수리들을 허용하기 위한 의도로 고안될 것이다.
손상 유형들과 연관된 수리
파일 속성들
속성이 생략되었다.
속성 리스트가 손상되었다
속성 오프세트가 한계 밖이다.
속성 레코드 길이 = 0.
속성 표가 손상된 것같다.
속성 VCN이 음수이다.
속성->RecordLength == 0.
AttributeList가 손상되었다.
손상 속성: 악성 VCN 범위, 찾을 VCN이 범위 밖이다.
파일명 속성이 손상되거나, 파일명 링크들이 악성이거나, 디렉토리가 $INDEX-ROOT를 생략한다.
FILE-ATTRIBUTE-REPARSE-POINT 플래그가 세트되지 않았다.
파일명 속성이 생략되었다.
인덱스된 속성이 이미 존재한다.
IndexEntry가 무효하다(손상 속성).
MFT 데이터 속성이 생략되었다.
열린 속성 표에 엔트리가 생략되었다.
인덱스되지 않은 속성이 이미 존재한다.
비상주 $DATA 속성이 생략되었다.
비상주 속성이 이미 존재한다.
상주 속성 데이터가 레코드 길이를 초과하였다.
$STANDARD-INFORMATION 속성이 생략되었다.
할당들
파일 레코드를 위한 충분치 않은 할당.
할당 손상.
할당을 발견할 수 없음.
VCN이 악성임.
VCN이 너무 큼.
0인 LCN.
할당을 초과하여 데이터 액세스를 시도함.
LCN 0를 해제하려고 시도함.
LCN이 사용중임.
비상주 AllocatedLength가 너무 큼.
인덱스들
손상된 인덱스 트리.
인덱스 엔트리를 찾지 못함. 빈 인덱스.
빈 인덱스 엔트리 리프.
인덱스 버퍼가 손상됨.
인덱스 엔트리가 이미 존재함.
인덱스 엔트리가 존재하지 않음.
인덱스 엔트리가 손상됨.
이름 인덱스가 무효함.
레코드 인덱스가 너무 큼.
리파스 포인트에 인덱스에 레코드가 없음.
0의 길이의 인덱스 엔트리 길이.
UpCase
표
Upcase 표가 너무 큼.
Upcase 표를 액세스할 수 없음.
로그 파일
무효한 로그 레코드. 로그파일이 꽉참.
재시작
무효한 재시작 인덱스.
무효한 재시작 표.
비할당된 재시작 표 엔트리.
보안
손상된 보안 ID.
파일 손상
파일 레코드 손상.
FILE 사인이 손상됨.
Filesize가 할당보다 더 큼.
Filesize가 리파스 포인트에 대해 너무 큼.
악성 파일 레코드일까?
무효한 FileSize, ValidDataLength, 또는 AllocationSize.
비상주 FileSize가 리파스 포인트에 대해 너무 큼.
비할당된 범위를 갖는 성기지 않은(non-sparse) 파일.
FRS 크기를 넘는 RecordOffset.
0 또는 8 이상의 Vcn 변경 바이트들이나, 8개 이상의 Lcn 변경 바이트들이 있으면, 또는 최종 레코드 밖으로 나가거나 Vcn 변경이 음수이면, 그 파일은 손상되었다.
MCB가 존재하지 않는다.
MCB가 손상되었다.
기대되지 않은 파일 참조.
실패한 취소
배타적인 FCB 리스트(및 비트맵 플래그)를 조사하여 무엇이 수리될 필요가 있는지를 결정한다.
결론
본 발명이 구조적 특징들 및/또는 방법적 동작들에 고유한 언어로 기재되었지만, 첨부된 청구범위에서 정의된 본 발명은 기재된 특정 특징들이나 동작들에 제한될 필요는 없음을 이해할 것이다. 그 보다는, 특정 특징들과 동작들은 청구되는 발명을 구현하는 예들의 형태로서 개시된다.
본 발명의 시스템 및 방법은 파일 시스템 손상의 실시간 교정을 하도록 한다. 파일 시스템의 한 가지 개선점은 실행 볼륨에서 탐지된 파일 시스템 손상들에 실시간으로 응답하고, 파일 시스템이 전체 볼륨을 잠그지 않고 그들을 탐지하는 지점에서 손상들을 수리하여 볼륨의 다른 동작들이 계속될 수 있게 한다.
Claims (32)
- 손상의 카테고리들을 정의하는 단계 - 상기 손상의 카테고리들은,i) 파일 시스템 요구와 연관된 손상;ii) 사용자 조작과 연관된 손상; 및iii) 이전의 수리로 인한 무효 핸들과 연관된 손상으로 정의됨 - ;저장 볼륨 상의 데이터에 대한 손상을 탐지하는 단계 - 상기 손상은 상기 카테고리들 중 하나로 분류됨 - ;탐지된 손상에 대응하는 수리 스캔을 정의하는 단계 - 상기 탐지된 손상이 사용자 조작과 연관되어 있으면, 대응하는 수리 스캔이 장기 수리 스캔임 - ;상기 수리 스캔을 구현하는 단계를 포함하는 방법.
- 제1항에 있어서,상기 손상을 지시하는 오류 상태를 발생시키는 단계 -상기 오류 상태는 보류를 시작함-; 및상기 탐지 시에 상기 손상을 기재하는 정보를 기록하는 단계 -상기 수리 스캔은 상기 정보에 기초하여 정의됨-를 더 포함하는 방법.
- 제1항에 있어서, 상기 수리 스캔을 정의하는 단계는 저 레벨 스캔들의 집합을 포함하는 복잡한 수리 스캔을 정의하는 단계를 포함하는 방법.
- 제3항에 있어서, 상기 수리 스캔을 구현하는 단계는 상기 복잡한 수리 스캔을 구현하는 단계를 포함하는 방법.
- 제4항에 있어서, 상기 복잡한 수리 스캔을 구현하는 단계는 상기 저 레벨 스캔들의 집합을 구현하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 수리 스캔을 구현하는 단계는 현재 스레드 내에서 실행의 최상위 레벨 지점에서 수리 루틴을 실행하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 수리 스캔을 구현하는 단계는 상기 수리 스캔을 서비스하는 전용 스레드를 시작하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 파일 시스템 요구는 재귀적인 요구이고, 상기 방법은,상기 재귀적 요구의 최상위 레벨 요구로 언와인드(unwind)하는 단계; 및상기 최상위 레벨 요청에 대해 상기 수리 스캔을 구현하는 단계를 더 포함하는 방법.
- 제1항에 있어서, 상기 수리 스캔은,속성 스캔;파일 스캔;인덱스 스캔;볼륨 비트맵 재구성; 및보안 서술자 파일 스캔을 포함하는 그룹으로부터 선택되는 방법.
- 제1항에 있어서,상기 수리 스캔을 받는 파일과 연관된 제2 파일 시스템 요구를 수신하는 단계;상기 수리 스캔이 장기 실행 수리이면 상기 제2 파일 시스템 요구를 실패하는 단계; 및상기 수리 스캔이 단기-실행 수리이면, 상기 수리 스캔이 완료될 때까지 상기 제2 파일 시스템 요구를 블럭킹하는 단계를 더 포함하는 방법.
- 제1항에 있어서,상기 수리 스캔을 중지(disabling)시키기 위해 파일 시스템 제어 커맨드를 수신하는 단계; 및상기 수리 스캔이 장기-실행 수리이면 상기 수리 스캔을 중지시키는 단계를 더 포함하는 방법.
- 제1항에 있어서,상기 수리 스캔을 구현하는 동안 추가 손상을 탐지하는 단계; 및새 수리 스캔이 완료될 때까지 상기 수리 스캔을 지연하는 단계를 더 포함하는 방법.
- 제1항에 있어서,상기 수리 스캔을 구현하는 동안 산발적 하드웨어 오류를 탐지하는 단계;상기 산발적 하드웨어 오류 때문에 상기 수리 스캔을 실패하는 단계; 및이벤트 로그에 상기 실패된 수리 스캔을 로그하는 단계를 더 포함하는 방법.
- 제1항에 있어서, 상기 수리 스캔 동안에 파일 시스템 메타-데이터에 대해 유효화 스캔을 시작하는 단계를 더 포함하는 방법.
- 제14항에 있어서, 상기 유효화 스캔을 시작하는 단계는,전체 볼륨 스캔;보안 스캔;파일 스캔;스트림 스캔;디렉토리 스캔; 및뷰 인덱스 스캔을 포함하는 그룹으로부터 선택된 유효화 스캔을 시작하는 단계를 포함하는 방법.
- 제1항의 방법을 수행하기 위해 구성된 프로세서-실행가능 명령어들을 포함하는 프로세서 판독가능 기록 매체.
- 제1항에 있어서,사소하지 않은 수리 스캔을 정의하는 단계는,상기 손상에 기초하여 상기 파일 시스템 요구의 실행을 보류하는 단계;상기 파일 시스템 요구를 실패하는 단계; 및손상 상태 오류를 발생시키는 단계를 더 포함하는 방법.
- 프로세서 실행가능 명령어들이 구현되어 있는 프로세서 판독가능 기록 매체에 있어서, 상기 프로세서 실행가능 명령어들은,손상의 카테고리들을 정의하고 - 상기 손상의 카테고리들은,i) 파일 시스템 요구와 연관된 손상;ii) 사용자 조작과 연관된 손상; 및iii) 이전의 수리로 인한 무효 핸들과 연관된 손상으로 정의됨 - ;저장 볼륨 상의 데이터 손상을 탐지하고 - 상기 손상은 상기 카테고리들 중 하나로 분류됨 - ;탐지된 손상에 대응하는 수리 스캔을 정의하는 단계 - 상기 탐지된 손상이 사용자 조작과 연관되어 있으면, 대응하는 수리 스캔이 장기 수리 스캔임 - ;상기 수리 스캔을 구현하도록 구성되는 프로세서 판독가능 기록 매체.
- 제18항에 있어서, 상기 데이터 손상이 수리되는 동안 사용자가 상기 파일 시스템 요구를 취소시키는 것을 허용하도록 구성된 프로세서-실행가능 명령어들을 더 포함하는 프로세서 판독가능 기록 매체.
- 제18항에 기재된 프로세서 판독가능 기록 매체를 포함하는 컴퓨터.
- 컴퓨터로서,한 개 이상의 볼륨들이 구성된 하드 디스크; 및파일 시스템을 포함하며, 상기 파일 시스템은,손상의 카테고리들을 정의하는 단계 - 상기 손상의 카테고리들은,i) 파일 시스템 요구와 연관된 손상;ii) 사용자 조작과 연관된 손상; 및iii) 이전의 수리로 인한 무효 핸들과 연관된 손상으로 정의됨 - ;파일 시스템 요구와 연관된 하나 이상의 볼륨에 포함된 데이터에 대한 손상을 탐지하는 단계 - 상기 손상은 상기 카테고리들 중 하나로 분류됨 - ;탐지된 손상에 대응하는 수리 스캔을 정의하는 단계 - 상기 탐지된 손상이 사용자 조작과 연관되어 있으면, 대응하는 수리 스캔이 장기 수리 스캔임 - ;상기 수리 스캔을 구현하는 단계를 수행하도록 구성되는 컴퓨터.
- 제21항에 있어서,상기 파일 시스템 내에 통합된 실시간 수리 모듈을 더 포함하고, 상기 파일 시스템은 손상된 메타-데이터를 탐지할 때 상기 실시간 수리 모듈을 콜하도록 구성되고, 상기 실시간 수리 모듈은 상기 파일 시스템으로부터의 상기 콜에 응답하여 상기 손상된 메타-데이터를 수리하도록 구성된 컴퓨터.
- 제21항에 있어서,상기 파일 시스템의 요구를 하고, 실시간 수리가 완료되고 상기 파일 시스템이 상기 요구를 구현할 때까지 상기 파일 시스템에 의한 상기 요구의 보류를 관리하도록 구성되는 응용 프로그램을 더 포함하는 컴퓨터.
- 제21항에 있어서,사소하지 않은 수리 스캔을 정의하는 단계는,상기 손상에 기초하여 상기 파일 시스템 요구의 실행을 보류하는 단계;상기 파일 시스템 요구를 실패하는 단계; 및손상 상태 오류를 발생시키는 단계를 더 포함하는 컴퓨터.
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
- 삭제
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US56666204P | 2004-04-30 | 2004-04-30 | |
US60/566,662 | 2004-04-30 | ||
US10/954,664 | 2004-09-30 | ||
US10/954,664 US7523343B2 (en) | 2004-04-30 | 2004-09-30 | Real-time file system repairs |
Publications (2)
Publication Number | Publication Date |
---|---|
KR20060045370A KR20060045370A (ko) | 2006-05-17 |
KR101137081B1 true KR101137081B1 (ko) | 2012-07-02 |
Family
ID=34939258
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020050027129A KR101137081B1 (ko) | 2004-04-30 | 2005-03-31 | 실시간 파일 시스템 수리 |
Country Status (5)
Country | Link |
---|---|
US (1) | US7523343B2 (ko) |
EP (1) | EP1594062B1 (ko) |
JP (1) | JP4685488B2 (ko) |
KR (1) | KR101137081B1 (ko) |
CN (1) | CN1694098B (ko) |
Families Citing this family (102)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060129614A1 (en) * | 2004-12-14 | 2006-06-15 | Kim Hong Y | Crash recovery system and method for distributed file server using object based storage |
US9639554B2 (en) | 2004-12-17 | 2017-05-02 | Microsoft Technology Licensing, Llc | Extensible file system |
US8606830B2 (en) | 2004-12-17 | 2013-12-10 | Microsoft Corporation | Contiguous file allocation in an extensible file system |
US8321439B2 (en) * | 2004-12-17 | 2012-11-27 | Microsoft Corporation | Quick filename lookup using name hash |
US7873596B2 (en) | 2006-05-23 | 2011-01-18 | Microsoft Corporation | Extending cluster allocations in an extensible file system |
US7689599B1 (en) * | 2005-01-31 | 2010-03-30 | Symantec Operating Corporation | Repair of inconsistencies between data and metadata stored on a temporal volume using transaction log replay |
US7590668B2 (en) * | 2005-04-15 | 2009-09-15 | Microsoft Corporation | Pausable backups of file system items |
US7624307B2 (en) * | 2005-05-25 | 2009-11-24 | Microsoft Corporation | Operations engine error handling |
US7774322B2 (en) * | 2005-05-25 | 2010-08-10 | Microsoft Corporation | File transfer error handling |
US7707193B2 (en) * | 2005-09-22 | 2010-04-27 | Netapp, Inc. | System and method for verifying and restoring the consistency of inode to pathname mappings in a filesystem |
CA2652115C (en) * | 2006-05-12 | 2015-11-17 | Goldengate Software, Inc. | Apparatus and method for read consistency in a log mining system |
US8151082B2 (en) * | 2007-12-06 | 2012-04-03 | Fusion-Io, Inc. | Apparatus, system, and method for converting a storage request into an append data storage command |
US8868495B2 (en) * | 2007-02-21 | 2014-10-21 | Netapp, Inc. | System and method for indexing user data on storage systems |
US8127412B2 (en) * | 2007-03-30 | 2012-03-06 | Cisco Technology, Inc. | Network context triggers for activating virtualized computer applications |
US8724521B2 (en) * | 2007-07-30 | 2014-05-13 | Verint Americas Inc. | Systems and methods of recording solution interface |
US20090089628A1 (en) * | 2007-10-01 | 2009-04-02 | Day Mark S | File system error detection and recovery framework |
US8347401B2 (en) * | 2007-10-24 | 2013-01-01 | Mcafee, Inc. | Method and system for ensuring a sharing violation free environment for a trusted software agent |
US8176017B2 (en) * | 2007-12-14 | 2012-05-08 | Microsoft Corporation | Live volume access |
US8219564B1 (en) | 2008-04-29 | 2012-07-10 | Netapp, Inc. | Two-dimensional indexes for quick multiple attribute search in a catalog system |
CN101272150B (zh) * | 2008-05-14 | 2010-09-29 | 中兴通讯股份有限公司 | 一种低密度生成矩阵码的译码方法及装置 |
US7849365B2 (en) * | 2008-07-30 | 2010-12-07 | Apple Inc. | Method for reducing host device to electronic device communication errors |
US8874627B2 (en) * | 2008-10-30 | 2014-10-28 | Hewlett-Packard Development Company, L.P. | Enumerating metadata in file system directories |
US8560524B2 (en) * | 2008-10-30 | 2013-10-15 | Hewlett-Packard Development Company, L.P. | Allocating priorities to prevent deadlocks in a storage system |
US9176963B2 (en) * | 2008-10-30 | 2015-11-03 | Hewlett-Packard Development Company, L.P. | Managing counters in a distributed file system |
WO2010050944A1 (en) * | 2008-10-30 | 2010-05-06 | Hewlett-Packard Development Company, L.P. | Online checking of data structures of a file system |
US8312242B2 (en) * | 2008-10-30 | 2012-11-13 | Hewlett-Packard Development Company, L.P. | Tracking memory space in a storage system |
US8156300B2 (en) * | 2008-11-18 | 2012-04-10 | Microsoft Corporation | Delete notifications for an entire storage volume |
US8255641B2 (en) * | 2008-11-18 | 2012-08-28 | Microsoft Corporation | Modifying delete notifications in a storage stack |
US8261030B2 (en) * | 2008-11-18 | 2012-09-04 | Microsoft Corporation | Using delete notifications to free related storage resources |
TW201022930A (en) | 2008-11-20 | 2010-06-16 | Ibm | Method to improve recovery time of mirrored disks when read stability is in doubt |
US9990254B1 (en) * | 2009-01-29 | 2018-06-05 | Veritas Technologies Llc | Techniques for data restoration |
US8266136B1 (en) | 2009-04-13 | 2012-09-11 | Netapp, Inc. | Mechanism for performing fast directory lookup in a server system |
CA2806368C (en) | 2009-07-29 | 2019-04-30 | Reversinglabs Corporation | Portable executable file analysis |
US9307092B1 (en) | 2010-10-04 | 2016-04-05 | Verint Americas Inc. | Using secondary channel information to provide for gateway recording |
US8650229B2 (en) * | 2010-11-18 | 2014-02-11 | II Hector Fuentes | System and method for removing master file table ($MFT) file record segments (FRS) |
US9158605B2 (en) | 2010-12-01 | 2015-10-13 | Microsoft Technology Licensing, Llc | Method, system and device for validating repair files and repairing corrupt software |
US8607099B2 (en) * | 2010-12-17 | 2013-12-10 | Microsoft Corporation | Online fault verification in a file system |
US8667323B2 (en) * | 2010-12-17 | 2014-03-04 | Microsoft Corporation | Proactive error scan and isolated error correction |
US8621276B2 (en) * | 2010-12-17 | 2013-12-31 | Microsoft Corporation | File system resiliency management |
US8639971B1 (en) | 2011-02-17 | 2014-01-28 | Scale Computing | Condition detection and reporting in complex systems |
KR101831693B1 (ko) * | 2011-03-08 | 2018-02-23 | 삼성전자주식회사 | 멀티 소프트웨어 플랫폼 기반의 휴대용 단말기에서 플랫폼 간 정보를 동기화하는 방법 및 장치 |
US20120284474A1 (en) * | 2011-05-06 | 2012-11-08 | International Business Machines Corporation | Enabling recovery during data defragmentation |
CN102855432B (zh) * | 2011-06-27 | 2015-11-25 | 北京奇虎科技有限公司 | 一种文件、文件夹解锁和删除方法及系统 |
US8849777B1 (en) * | 2011-06-30 | 2014-09-30 | Emc Corporation | File deletion detection in key value databases for virtual backups |
US8843443B1 (en) | 2011-06-30 | 2014-09-23 | Emc Corporation | Efficient backup of virtual data |
US8949305B1 (en) | 2011-07-15 | 2015-02-03 | Scale Computing, Inc. | Distributed dynamic system configuration |
US9104651B1 (en) | 2011-07-15 | 2015-08-11 | Scale Computing, Inc. | Techniques for distributing tests and test suites across a network |
US8918776B2 (en) | 2011-08-24 | 2014-12-23 | Microsoft Corporation | Self-adapting software system |
US8806005B2 (en) * | 2011-09-12 | 2014-08-12 | Microsoft Corporation | Cross-machine event log correlation |
US8341198B1 (en) | 2011-09-23 | 2012-12-25 | Microsoft Corporation | File system repair with continuous data availability |
JP5468710B2 (ja) | 2012-02-27 | 2014-04-09 | パナソニック株式会社 | アクセス装置、通信機器、通信システム、及びデータアクセス方法 |
CN103309768B (zh) * | 2012-03-16 | 2015-03-11 | 腾讯科技(深圳)有限公司 | 系统文件修复方法和装置 |
US9077665B1 (en) | 2012-05-24 | 2015-07-07 | Scale Computing, Inc. | Transferring virtual machines and resource localization in a distributed fault-tolerant system |
CN102799500B (zh) * | 2012-06-25 | 2014-04-30 | 腾讯科技(深圳)有限公司 | 系统修复方法及装置 |
CN103577751B (zh) * | 2012-07-25 | 2015-06-10 | 腾讯科技(深圳)有限公司 | 文件扫描方法和装置 |
US10430216B1 (en) | 2012-08-23 | 2019-10-01 | Scale Computing Inc | Virtual machine automated selection |
US10019287B1 (en) | 2012-08-23 | 2018-07-10 | Scale Computing | Virtual machine resource display |
CN103678032B (zh) * | 2012-09-17 | 2017-10-31 | 腾讯科技(深圳)有限公司 | 系统文件的修复方法及装置 |
US20140123122A1 (en) * | 2012-10-31 | 2014-05-01 | Hcl Technologies Limited | System and method for virtual machine offline patching without mount the virtual disk |
US20140188957A1 (en) * | 2012-11-30 | 2014-07-03 | Hitachi, Ltd. | Hierarchical storage system and file management method |
US9846706B1 (en) * | 2012-12-28 | 2017-12-19 | EMC IP Holding Company LLC | Managing mounting of file systems |
US9547549B2 (en) * | 2013-01-16 | 2017-01-17 | Microsoft Technology Licensing, Llc | Handling file system corruption |
US9244932B1 (en) * | 2013-01-28 | 2016-01-26 | Symantec Corporation | Resolving reparse point conflicts when performing file operations |
TWI518680B (zh) * | 2013-09-12 | 2016-01-21 | 群暉科技股份有限公司 | 維護電腦系統之檔案系統的方法 |
CN103679024B (zh) * | 2013-11-19 | 2015-03-25 | 百度在线网络技术(北京)有限公司 | 病毒的处理方法及设备 |
CN103761156B (zh) * | 2013-12-13 | 2016-09-21 | 北京同有飞骥科技股份有限公司 | 一种针对文件系统的在线修复方法 |
US9400817B2 (en) * | 2013-12-31 | 2016-07-26 | Sybase, Inc. | In-place index repair |
WO2015116125A1 (en) * | 2014-01-31 | 2015-08-06 | Hewlett-Packard Development Company, L.P. | File system analysis in user daemon |
US10423481B2 (en) * | 2014-03-14 | 2019-09-24 | Cisco Technology, Inc. | Reconciling redundant copies of media content |
US9594632B2 (en) | 2014-07-09 | 2017-03-14 | Qualcomm Incorporated | Systems and methods for reliably storing data using liquid distributed storage |
US9582355B2 (en) | 2014-07-09 | 2017-02-28 | Qualcomm Incorporated | Systems and methods for reliably storing data using liquid distributed storage |
US9734007B2 (en) | 2014-07-09 | 2017-08-15 | Qualcomm Incorporated | Systems and methods for reliably storing data using liquid distributed storage |
JP6327028B2 (ja) * | 2014-07-14 | 2018-05-23 | 日本電気株式会社 | オブジェクトストレージシステムおよびその制御方法およびその制御プログラム |
CN104199894A (zh) * | 2014-08-25 | 2014-12-10 | 百度在线网络技术(北京)有限公司 | 一种文件扫描方法及装置 |
JP6021120B2 (ja) | 2014-09-29 | 2016-11-09 | インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation | データをストリーム処理する方法、並びに、そのコンピュータ・システム及びコンピュータ・システム用プログラム |
US9853863B1 (en) | 2014-10-08 | 2017-12-26 | Servicenow, Inc. | Collision detection using state management of configuration items |
CN105573872B (zh) * | 2014-10-09 | 2019-01-08 | 腾讯科技(深圳)有限公司 | 数据存储系统的硬盘维护方法和装置 |
CN104331463B (zh) * | 2014-10-30 | 2018-07-17 | 深圳市锐明技术股份有限公司 | 一种文件系统多线程实现的方法及装置 |
CN104503863B (zh) * | 2014-11-07 | 2017-08-11 | 清华大学 | 用于虚拟容器系统容灾的内核态与用户态数据交换方法 |
US10102214B2 (en) * | 2015-01-30 | 2018-10-16 | International Business Machines Corporation | Analyzing and correcting corruption which caused filesystem checker failure so that the filesystem checker will run without error |
US10810525B1 (en) | 2015-05-07 | 2020-10-20 | CSC Holdings, LLC | System and method for task-specific GPS-enabled network fault annunciator |
US10489240B2 (en) | 2015-09-25 | 2019-11-26 | Microsoft Technology Licensing, Llc | Efficient detection of corrupt data |
KR101688629B1 (ko) * | 2015-11-17 | 2016-12-21 | 한국전자통신연구원 | 메타데이터 및 데이터 클러스터를 이용하는 파일 시스템 복구 방법 및 장치 |
US10412152B2 (en) * | 2015-11-24 | 2019-09-10 | International Business Machines Corporation | Surgical corruption repair in large file systems |
US10437813B2 (en) * | 2016-02-01 | 2019-10-08 | Dell Products L.P. | Self-healing of layer metadata within a layering system |
US9960951B1 (en) | 2016-03-15 | 2018-05-01 | CSC Holdings, LLC | System, method, and medium for determining a failure of a network element |
US10733045B2 (en) * | 2016-07-14 | 2020-08-04 | Microsoft Technology Licensing, Llc | Online repair of metadata for structured data including file systems |
CN107451257A (zh) * | 2017-07-31 | 2017-12-08 | 郑州云海信息技术有限公司 | 一种基于分布式文件系统的可维护性系统和方法 |
CN107506344A (zh) * | 2017-10-12 | 2017-12-22 | 郑州云海信息技术有限公司 | 一种文件在线编辑方法和装置 |
US10848538B2 (en) | 2017-11-28 | 2020-11-24 | Cisco Technology, Inc. | Synchronized source selection for adaptive bitrate (ABR) encoders |
US10820066B2 (en) | 2018-06-20 | 2020-10-27 | Cisco Technology, Inc. | Reconciling ABR segments across redundant sites |
RU2702053C1 (ru) * | 2018-12-28 | 2019-10-03 | Акционерное общество "Лаборатория Касперского" | Способ снижения нагрузки на сканирующую подсистему путем дедупликации сканирования файлов |
CN110399242B (zh) * | 2019-07-23 | 2022-05-31 | 安徽朵朵云网络科技有限公司 | 基于Hadoop平台的信息维护管理系统 |
US11321294B2 (en) * | 2019-09-09 | 2022-05-03 | Salesforce.Com, Inc. | Database index repair |
US11386219B2 (en) | 2020-08-24 | 2022-07-12 | Raytheon Company | Detection of an unauthorized modification to storage and restoration of the storage |
CN112230855A (zh) * | 2020-10-20 | 2021-01-15 | 英韧科技(上海)有限公司 | 固态硬盘及其读写方法 |
US11650975B2 (en) | 2020-12-11 | 2023-05-16 | International Business Machines Corporation | Online file system consistency check for container data on a clustered filesystem |
CN112486734B (zh) * | 2020-12-17 | 2024-09-17 | 深圳软牛科技集团股份有限公司 | 一种ntfs删除文件恢复方法、装置及电子设备 |
US11556410B2 (en) * | 2021-03-18 | 2023-01-17 | Micron Technology, Inc. | Adaptive background scans in a memory sub-system |
US11960606B2 (en) * | 2022-03-24 | 2024-04-16 | Check Point Software Technologies Ltd. | System and method for protecting against data storage attacks |
CN114996046A (zh) * | 2022-08-05 | 2022-09-02 | 北京网藤科技有限公司 | 一种用于windows系统的磁盘扫描加速方法及装置 |
CN117472290B (zh) * | 2023-12-27 | 2024-03-22 | 苏州元脑智能科技有限公司 | 存储数据的修复方法、装置、系统、电子设备及存储介质 |
Family Cites Families (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5305455A (en) * | 1990-12-21 | 1994-04-19 | International Business Machines Corp. | Per thread exception management for multitasking multithreaded operating system |
JPH0561754A (ja) * | 1991-09-05 | 1993-03-12 | Juki Corp | データ処理装置 |
US5432933A (en) * | 1992-10-27 | 1995-07-11 | Bmc Software, Inc. | Method of canceling a DB2 thread |
US5566297A (en) * | 1994-06-16 | 1996-10-15 | International Business Machines Corporation | Non-disruptive recovery from file server failure in a highly available file system for clustered computing environments |
US5765151A (en) * | 1995-08-17 | 1998-06-09 | Sun Microsystems, Inc. | System and method for file system fix-on-panic for a computer operating system |
JPH09330237A (ja) * | 1996-06-07 | 1997-12-22 | Toshiba Corp | プロセス切り替え装置およびプロセス切り替え方法 |
US5875444A (en) * | 1996-12-10 | 1999-02-23 | International Business Machines Corporation | Computer file system check and repair utility |
US6014515A (en) * | 1997-05-29 | 2000-01-11 | Hewlett-Packard Company | Enhanced stack unwind facility |
US6584582B1 (en) * | 2000-01-14 | 2003-06-24 | Sun Microsystems, Inc. | Method of file system recovery logging |
US6640317B1 (en) * | 2000-04-20 | 2003-10-28 | International Business Machines Corporation | Mechanism for automated generic application damage detection and repair in strongly encapsulated application |
US6983362B1 (en) * | 2000-05-20 | 2006-01-03 | Ciena Corporation | Configurable fault recovery policy for a computer system |
US6816984B1 (en) * | 2000-06-23 | 2004-11-09 | Microsoft Corporation | Method and system for verifying and storing documents during a program failure |
US6934939B2 (en) * | 2001-02-28 | 2005-08-23 | International Business Machines Corporation | Method for unwinding a program call stack |
US6976193B2 (en) * | 2001-09-20 | 2005-12-13 | Intel Corporation | Method for running diagnostic utilities in a multi-threaded operating system environment |
US6895413B2 (en) * | 2002-03-22 | 2005-05-17 | Network Appliance, Inc. | System and method for performing an on-line check of a file system |
US20040128658A1 (en) * | 2002-12-27 | 2004-07-01 | Guei-Yuan Lueh | Exception handling with stack trace cache |
US7085943B2 (en) * | 2003-09-26 | 2006-08-01 | Freescale Semiconductor, Inc. | Method and circuitry for controlling supply voltage in a data processing system |
US20050097141A1 (en) * | 2003-10-30 | 2005-05-05 | International Business Machines Corporation | Autonomic filesystem recovery |
-
2004
- 2004-09-30 US US10/954,664 patent/US7523343B2/en not_active Expired - Fee Related
-
2005
- 2005-03-30 JP JP2005097946A patent/JP4685488B2/ja not_active Expired - Fee Related
- 2005-03-30 CN CN2005100562508A patent/CN1694098B/zh not_active Expired - Fee Related
- 2005-03-31 KR KR1020050027129A patent/KR101137081B1/ko active IP Right Grant
- 2005-04-13 EP EP05102907.2A patent/EP1594062B1/en not_active Not-in-force
Also Published As
Publication number | Publication date |
---|---|
US7523343B2 (en) | 2009-04-21 |
JP4685488B2 (ja) | 2011-05-18 |
KR20060045370A (ko) | 2006-05-17 |
CN1694098B (zh) | 2011-02-23 |
EP1594062B1 (en) | 2017-08-23 |
CN1694095A (zh) | 2005-11-09 |
EP1594062A2 (en) | 2005-11-09 |
US20050246612A1 (en) | 2005-11-03 |
EP1594062A3 (en) | 2009-11-25 |
JP2005316981A (ja) | 2005-11-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR101137081B1 (ko) | 실시간 파일 시스템 수리 | |
US9400886B1 (en) | System and method for using snapshots for rootkit detection | |
US7765361B2 (en) | Enforced transaction system recoverability on media without write-through | |
US6067541A (en) | Monitoring document changes in a file system of documents with the document change information stored in a persistent log | |
US6971018B1 (en) | File protection service for a computer system | |
US9311188B2 (en) | Minimizing data recovery window | |
US8732121B1 (en) | Method and system for backup to a hidden backup storage | |
US7360111B2 (en) | Lossless recovery for computer systems with remotely dependent data recovery | |
US6820214B1 (en) | Automated system recovery via backup and restoration of system state | |
US9852198B1 (en) | Method and system for fast generation of file system snapshot bitmap in virtual environment | |
US7953948B1 (en) | System and method for data protection on a storage medium | |
US7631009B1 (en) | Redundancy check of transaction records in a file system log of a file server | |
US6851073B1 (en) | Extensible system recovery architecture | |
US8275939B2 (en) | Preventing data loss in a storage system | |
US8145607B1 (en) | System and method for online backup and restore of MS exchange server | |
US7293044B2 (en) | Method and system for verifying integrity of storage | |
US8886995B1 (en) | Fault tolerant state machine for configuring software in a digital computer | |
US20050289169A1 (en) | Lossless recovery for computer systems with map assisted state transfer | |
US20060037079A1 (en) | System, method and program for scanning for viruses | |
US9286320B2 (en) | System and method for maintaining consistency among metadata elements of filesystem's logical objects | |
KR20150070134A (ko) | 가상 데이터베이스를 생성하기 위한 소스 데이터베이스의 지정 시간 복사의 검색 | |
JP2007531155A (ja) | データベースバックアップの整合性チェックのためのシステムおよび方法 | |
US10261863B2 (en) | Runtime file system consistency checking during backup operations | |
US20230273799A1 (en) | Storage system with boot volume rollback points | |
US9477675B1 (en) | Managing file system checking in file systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A201 | Request for examination | ||
E902 | Notification of reason for refusal | ||
E701 | Decision to grant or registration of patent right | ||
GRNT | Written decision to grant | ||
FPAY | Annual fee payment |
Payment date: 20160318 Year of fee payment: 5 |
|
FPAY | Annual fee payment |
Payment date: 20170317 Year of fee payment: 6 |