차세대 Windows 파일 시스템 개발: ReFS

Articolo
01/20/2012

Windows 8에 새롭게 도입 중인 차세대 파일 시스템에 대한 논의를 통해 데이터 저장소에 대한 이야기를 계속 함께 나누겠습니다. 현재 NTFS가 가장 풍부하고 앞선 기능을 제공하는 파일 시스템으로 폭넓게 사용되고 있습니다. 하지만 Windows 사용자들이 Windows 8에 거는 기대에 부응하기 위해 과거의 성공에 안주하지 않고 새로운 기술로 파일 시스템을 더욱 개선할 계획입니다. 이러한 배경에서 탄생한 ReFS(Resilient File System)는 차세대 저장 기술로, NTFS를 기반으로 하므로 호환성에 문제가 없으며 동시에 새로운 세대의 저장소 기술과 환경에 맞게 설계 및 개발되고 있습니다. 새로운 파일 시스템이 선보일 때면 언제나 그랬듯이 Windows 8의 경우에도 ReFS를 Windows Server 8에만 포함하여 제공할 예정입니다. 물론, 응용 프로그램 수준에서 ReFS 저장 데이터는 NTFS 데이터처럼 여러 클라이언트에서 액세스할 수 있습니다. 이 글을 읽으면서 잊지 말아야 할 점은 NTFS가 현재까지 PC 파일 시스템의 주요 기술로 자리잡고 있다는 사실입니다.

아키텍처에 대한 심도 있는 논의를 제공하는 이 글은 저장소 및 파일 시스템 팀에서 개발 관리자로 근무 중인 Surendra Verma가 작성했으며 다른 블로그 글과 마찬가지로 많은 분들의 도움이 있었습니다. 또한 이번 글에서도 FAQ를 제공합니다.
- Steven

추신, CES에 대한 새로운 소식을 제공하는 @buildwindows8을 통해 최신 정보를 얻기 바랍니다.

본 글에서는 Windows의 새로운 파일 시스템에 대해 살펴보고자 합니다. ReFS로 알려진 이 파일 시스템은 Windows가 배포되는 다양한 방식을 고려하여 현재는 물론 미래까지 폭넓은 고객 기반의 다양한 요구를 충족시킨다는 목표에 따라 완전히 새롭게 설계되었습니다.

ReFS의 주요 목표는 다음과 같습니다.

폭넓게 채택된 NTFS의 장점과는 호환성을 최대한 유지하고, 시스템 복잡성을 높이고 공간을 많이 차지하면서도 그만한 가치를 제공하지 못하는 부분은 제외합니다.
데이터를 검증하고 자동으로 수정합니다. 데이터는 다양한 원인 때문에 손상될 수 있으므로 검증이 필요하며, 가능한 경우 자동으로 수정되어야 합니다. 아래에서 자세히 언급한 '조각난 쓰기(torn writes)'가 발생할 가능성을 없애기 위해 메타데이터가 원래 위치에 기록되지 않아야 합니다.
최상의 확장성을 유지합니다. 다방면으로 확장성이 우수한 구조를 유지합니다. 특히 디스크 확인 알고리즘이 전체 파일 시스템 크기로 확장될 수 있다고 가정하지 않습니다.
파일 시스템을 오프라인으로 전환하지 않습니다. 데이터가 손상될 경우 오류가 있는 데이터를 분리하고 나머지 볼륨에는 액세스를 허용하는 것이 좋다고 가정합니다. 이때 실시간으로 최대한 많은 데이터를 복구합니다.
ReFS와 연계하여 설계 및 개발된 저장 공간 기술을 함께 사용했을 때 완벽한 복원 아키텍처가 제공됩니다.

ReFS의 주요 특징은 다음과 같습니다. 이러한 특징 중 일부는 저장 공간과 연계하여 제공된다는 점에 유념하시기 바랍니다.

체크섬을 포함한 메타데이터 무결성
선택적 사용자 데이터 무결성을 제공하는 무결성 스트림
강력한 디스크 업데이트를 위한 '쓰기 시 할당' 트랜잭션 모델('쓰기 시 복사'라고도 함)
대용량 볼륨, 파일 및 디렉터리 크기
저장소 풀 구성과 가상화로 파일 시스템 생성과 관리 용이성 개선
성능 개선(대역폭을 관리할 수 있음)을 위한 데이터 스트라이핑 및 장애 복구에 대비한 이중화
숨겨진 디스크 오류로부터 보호해 주는 디스크 스크러빙
'복원'을 통해 손상에 대한 복원력을 제공하여 모든 경우에 최대의 볼륨 가용성 유지
다수의 시스템상에서 공유 저장소 풀을 구성하여 장애 복구 능력과 부하 균형 조절 능력 개선

그 밖에, ReFS에는 BitLocker 암호화, 보안 강화를 위한 액세스 제어 목록, USN 저널, 변경 알림, 바로 가기 링크, 연결 지점, 탑재 지점, 재분석 지점, 볼륨 스냅숏, 파일 ID 및 Oplock 등 NTFS의 여러 가지 기능과 의미 체계가 도입되었습니다.

물론, ReFS에 저장된 데이터는 현재 NTFS 볼륨에 액세스할 수 있는 모든 운영 체제에 사용되는 클라이언트에서 동일한 파일 액세스 API를 사용하여 액세스할 수 있습니다.

주요 설계 속성과 특징

설계 속성은 설계 목표와 밀접한 관련이 있습니다. 이러한 속성에 대한 설명을 읽으면서 수억 개의 장치에 사용되는 파일 시스템이 만들어졌던 지금까지의 과정을 염두에 두기 바랍니다. 이러한 파일 시스템은 초소형 시스템부터 대규모 데이터센터까지, 소형 저장소 형식부터 대형 멀티 스핀들 형식까지, 솔리드 스테이트부터 대용량 드라이브 및 저장소 시스템까지 다양한 환경으로 확장됩니다. 이와 동시에 매우 광범위한 응용 프로그램과 시스템 소프트웨어가 위치에 관계없이 Windows 파일 시스템에 액세스할 수 있습니다. ReFS에는 이러한 장점을 살려 더욱 개선하려는 의도가 담겨 있습니다. 완전히 새롭게 개발하지는 않았지만 합리적 수준에서 새롭게 상상했으며 이러한 합리성에 근거한 NTFS의 장점에 기반을 두었습니다. 무엇보다 이러한 파일 시스템은 주요 파일 시스템을 제공할 때 일관되게 고수했던 실용적 방식으로 제공됩니다. 이러한 수준의 일관성은 Microsoft만이 유지할 수 있습니다.

코드 재사용 및 호환성

파일 시스템 API라는 관점에서 보았을 때 파일 시스템에서 가장 중요한 요소는 호환성이며, 이를 기술적으로 구현하기가 매우 까다롭습니다. 파일 시스템의 의미 체계를 구현하는 코드를 재작성할 경우 적정 수준의 호환성이 유지되지 않고 응용 프로그램 코드, 호출 시기 및 하드웨어에 따라 민감한 문제가 발생할 수 있습니다. 이러한 이유 때문에 ReFS를 개발하는 과정에서 Windows 파일 시스템의 의미 체계를 구현하는 데 사용된 코드를 재사용했습니다. 이 코드는 파일 시스템 인터페이스를 구현하고(읽기, 쓰기, 열기, 닫기 및 변경 알림 등) 메모리 내 파일 및 볼륨 상태를 유지하며 보안 조치를 실행하고 파일 데이터의 메모리 캐싱과 동기화를 관리합니다. 이러한 재사용을 통해 NTFS와 공통되는 부분에서 높은 수준의 호환성이 보장됩니다.

이 재사용 부분에서 NTFS 버전의 코드 기반은 파일 및 디렉터리를 표시하는 마스터 파일 테이블(MFT) 등 온디스크 구조를 구현하는 새로운 엔진을 사용합니다. ReFS에는 이 재사용 코드와 함께 ReFS의 주요 혁신 기술이 적용된 새로운 엔진이 통합되었습니다. 그래프로 나타내보면 다음과 같습니다.

NTFS.SYS = NTFS 상위 계층 API/의미 체계 엔진 / NTFS 디스크내 저장소 엔진; ReFS.SYS = NTFS에서 상속된 상위 계층 엔진 / 새로운 디스크내 저장소 엔진

확장 가능하고 신뢰할 수 있는 온디스크 구조

온디스크 구조와 이 구조의 관리는 온디스크 저장소 엔진이 처리합니다. 이 엔진은 일반 키 값 인터페이스를 노출시키며 그 위의 계층에서 이를 이용하여 파일, 디렉터리 등을 구현합니다. 자체적인 구현을 위해 저장소 엔진은 B+ 트리를 독립적으로 사용합니다. 실제로 B+ 트리는 디스크의 모든 정보를 나타내기 위해 하나의 공통 온디스크 구조로 사용됩니다. 트리는 다른 트리 내에 포함될 수 있습니다(하위 트리의 루트가 상위 트리 행 내에 저장됨). 디스크에서 트리는 여러 수준을 가진 매우 큰 규모이거나 단 몇 개의 키를 가지고 다른 구조 내에 포함되는 작은 규모일 수도 있습니다. 이를 통해 파일 시스템의 모든 측면에서 규모를 확대하고 축소하는 확장성이 극대화됩니다. 단일 구조에서는 시스템이 크게 간소화되고 코드가 줄어듭니다. 새로운 엔진 인터페이스에는 키 값 쌍의 열거 가능한 집합인 '테이블'의 개념이 포함됩니다. 대부분의 테이블에는 참조를 위한 수단으로 고유 ID(개체 ID라고 함)가 사용됩니다. 특수 개체 테이블이 시스템에서 이러한 모든 테이블을 인덱스 처리합니다.

이제, 공통 파일 시스템의 추상화가 테이블을 통해 구조화되는 방식을 살펴보겠습니다.

파일 구조

위 그림과 같이 디렉터리는 테이블로 표시됩니다. B+ 트리를 사용하여 테이블을 구현하기 때문에 디렉터리를 매우 큰 규모로 효과적으로 확장할 수 있습니다. 파일은 자체가 테이블인 상위 디렉터리 행 내에 포함된 테이블로 구현되며, 위 그림에는 테이블이 파일 메타데이터로 표시되어 있습니다. 파일 메타데이터 테이블 내의 행은 다양한 파일 속성을 나타냅니다. 파일 데이터 범위 위치는 오프셋 매핑 테이블(및 선택적으로 체크섬까지 포함)이 포함된 스트림 테이블로 표시됩니다. 즉, 성능에 영향을 미치지 않으면서 파일과 디렉터리가 커질 수 있기 때문에 NTFS의 한계가 극복됩니다.

예상되는 바와 같이 ACL(액세스 제어 목록)과 같은 파일 시스템 내의 다른 전역 구조는 개체 테이블에 기반하는 테이블로 표시됩니다.

모든 디스크 공간 할당은 여유 공간 범위의 테이블을 통해 여유 공간을 표시하는 계층적 할당자에 의해 관리됩니다. 확장성을 높이기 위해 이러한 테이블에는 대형, 중간 및 소형 할당자 등 세 가지가 있습니다. 이러한 테이블은 공간을 관리하는 단위에서 차이가 있습니다. 예를 들어, 중간 할당자는 대형 할당자에서 할당한 중간 크기의 청크를 관리합니다. 그 결과 디스크 할당 알고리즘이 매우 효과적으로 확장되며, 관련 메타데이터를 자연스럽게 배치하는 이점이 있으므로 성능이 향상됩니다. 디스크의 알려진 특정 위치에서 이러한 할당자의 루트와 개체 테이블의 루트에 접근할 수 있습니다. 일부 테이블에는 경합을 줄이고 국부적 할당 효율을 높이기 위해 외부에 노출되지 않는 할당자가 사용됩니다.

파일이 디렉터리 내에 포함되기 때문에 전역 시스템 메타데이터 테이블과 별도로 개체 테이블의 항목은 디렉터리를 참조합니다.

강력한 디스크 업데이트 전략

안정적이고 효과적인 디스크 업데이트는 파일 시스템을 설계할 때 가장 중요하면서도 까다로운 측면 중 하나입니다. 이러한 이유 때문에 다양한 접근 방식을 평가하는 데 많은 시간을 할애해야 했습니다. 도입을 검토했다가 포기한 접근 방식 중 하나는 로그로 구조화된 파일 시스템을 구현하는 것이었습니다. 이 접근 방식은 Windows에 필요한 범용 파일 시스템 형태에는 적합하지 않습니다. NTFS는 디스크에서 일관성을 유지하기 위해 트랜잭션 저널에 의존합니다. 이 접근 방식은 디스크의 원래 위치에서 메타데이터를 업데이트하는 동시에 저널을 사용하여 오류가 발생하거나 정전 복구 중 롤백할 수 있도록 변경 내용을 추적합니다. 이 방식의 이점 중 하나는 메타데이터 레이아웃을 원래 위치에 유지시켜 주므로 읽기 성능에 도움이 된다는 점입니다. 저널링 시스템의 가장 큰 단점은 쓰기가 임의화될 수 있다는 점 외에도 디스크를 업데이트할 때 쓰기 작업 중에 전원 공급이 중단될 경우 이미 기록된 메타데이터가 손상될 수 있다는 점입니다. 이러한 문제를 일반적으로 조각난 쓰기라고 합니다.

안정성을 극대화하고 조각난 쓰기를 없애기 위해 메타데이터를 원래 위치에서 업데이트하는 대신 원자화된 방식으로 다른 위치에 메타데이터를 기록하는 쓰기 시 할당(allocate-on-write, 이하 AOW) 방식을 선택했습니다. 어떤 의미에서는 디스크 구조를 안정적으로 업데이트할 때 사용되는 섀도 페이징의 오래된 개념을 차용했다고 할 수 있습니다. 트랜잭션은 AOW 방식에 기반을 둡니다. ReFS의 상위 계층은 NTFS에서 파생되기 때문에 새로운 트랜잭션 모델은 많은 릴리스를 거치면서 입증되고 안정화된 기존의 오류 복구 논리를 완벽하게 활용합니다.

ReFS는 관련 부분(스트림 할당, 파일 속성, 파일 이름 및 디렉터리 페이지 등)의 쓰기를 회전 미디어 및 플래시에 유리하게 더 큰 단위와 더 적은 횟수의 I/O로 통합하는 방식으로 메타데이터를 할당합니다. 이때 읽기의 접근 단위는 그대로 유지됩니다. 여기서 계층적 할당 방식이 많이 활용됩니다.

우리는 시스템이 극심한 스트레스 하에 있을 때 시스템에서 전원을 차단하고 시스템이 백업되면 모든 구조가 올바른지 검사하는 테스트를 중점적으로 진행하고 있습니다. 이 테스트에 따라 궁극적으로 성패가 결정됩니다. Microsoft 파일 시스템에 대해 실시한 테스트에서는 최상의 결과를 얻었습니다. 즉 이 결과는 업계에서도 선두적인 것이며 우리의 주요 설계 목표를 충족합니다.

디스크 손상에 대한 복원력

앞서 언급했듯이 설계 목표 중 하나는 손상을 발견하고 수정하는 것이었습니다. 그 결과 데이터 무결성이 보장될 뿐만 아니라 시스템 가용성과 온라인 작동도 개선됩니다. 따라서, 모든 ReFS 메타데이터는 B+ 트리 페이지 수준에서 체크섬이 적용되고 이 체크섬은 페이지 자체와 독립적으로 저장됩니다. 따라서 손실된 쓰기와 잘못 지정된 쓰기 및 미디어에서 데이터가 손상되는 비트 랏(bit rot) 등 모든 형태의 디스크 손상을 발견할 수 있습니다. 또한, 파일 내용에 체크섬을 적용하는 옵션도 추가했습니다. '무결성 스트림'이라고 하는 이 옵션을 사용하면 ReFS가 파일 변경 사항을 항상 원래 위치와 다른 위치에 씁니다. 이 'AOW' 기술은 새로운 쓰기 방식을 통해 기존 데이터가 손실되는 것을 방지합니다. 데이트 쓰기와 함께 체크섬 업데이트가 자동으로 수행되므로 쓰는 중에 전원이 차단되면 일관되게 검증할 수 있는 파일 버전이 항상 준비되고 이를 통해 손상 여부를 명시적으로 확인할 수 있습니다.

몇 주 전 저장 공간에 대한 글을 올렸습니다. ReFS와 저장 공간은 전체 저장 시스템을 구성하는 두 요소로서 서로를 보완하도록 설계되었습니다. NTFS 및 클라이언트 PC는 활용폭이 넓기 때문에 저장 공간이 사용될 수 있습니다. 이러한 아키텍처의 계층 구조는 이 클라이언트쪽 접근 방식을 지원하며 궁극적으로 ReFS를 클라이언트와 서버 모두에서 사용할 수 있도록 클라이언트에서 사용하기 적합하게 ReFS가 최적화되고 있습니다.

저장 공간은 성능이 향상되었을 뿐 아니라 다수의 디스크에서 복사본을 관리함으로써 부분 또는 전체 디스크 오류로부터 데이터를 보호합니다. 읽기 오류가 발생하면 저장 공간이 대체 복사본을 읽을 수 있고, 쓰기 오류(및 읽기/쓰기 시 전체 미디어 손실)가 발생하면 데이터를 확실하게 다시 할당할 수 있습니다. 많은 경우에 오류는 미디어 오류 때문이 아니라 데이터 손상 혹은 손실되거나 잘못 지정된 쓰기 때문에 발생합니다.

이것이 바로 ReFS가 체크섬을 사용하여 발견할 수 있는 오류입니다. ReFS가 이러한 오류를 발견하면 저장 공간과 인터페이스를 구성하여 사용 가능한 모든 데이터 복사본을 읽고 체크섬 확인 결과에 따라 올바른 복사본을 선택합니다. 그런 다음 올바른 복사본을 기준으로 잘못된 복사본을 수정하라고 저장 공간에 지시합니다. 이러한 모든 과정은 응용 프로그램의 관점에서 보면 분명히 발생합니다. ReFS가 미러링된 저장 공간을 기반으로 실행되지 않으면 손상을 자동으로 복구할 방법이 없습니다. 이러한 경우에는 ReFS에서 손상이 감지되었다는 이벤트만 기록합니다. 이러한 손상이 파일 데이터와 관련된다면 읽기에 실패하게 됩니다. 이것이 메타데이터에 미치는 영향은 다음 기회에 자세히 설명하겠습니다.

체크섬(64비트)은 ReFS 메타데이터를 위해 항상 실행되며, 볼륨이 미러링된 저장 공간에서 호스팅된다고 가정하면 자동 수정도 항상 실행됩니다. 모든 무결성 스트림(아래 참고)은 동일한 방식으로 보호됩니다. 이를 통해 고객은 완전한 무결성 솔루션을 얻게 되어 상대적으로 불안정한 저장소의 안정성을 대폭 높일 수 있습니다.

무결성 스트림

무결성 스트림은 모든 형태의 데이터 손상으로부터 파일 내용을 보호합니다. 대개의 경우 이러한 측면은 매우 유용하지만 그렇지 않을 때도 있습니다. 예를 들어, 어떤 응용 프로그램은 파일 저장소를 세심하게 관리하고 디스크의 특정 파일 레이아웃을 사용하려고 합니다. 무결성 스트림은 파일 내용이 변경될 때마다 블록을 다시 할당하기 때문에 이러한 응용 프로그램 입장에서는 파일 레이아웃을 예측하기가 힘듭니다. 데이터베이스 시스템이 대표적인 예입니다. 이러한 응용 프로그램은 일반적으로 파일 내용에 대한 자체 체크섬을 관리하며 저장 공간 API와의 직접적인 상호 작용을 통해 데이터를 검증하고 수정할 수 있습니다.

특정 파일 레이아웃이 필요한 경우, 다양한 관리 단위로 이 설정을 제어하기 위한 메커니즘 및 API가 제공됩니다.

가장 기본적 수준에서 무결성은 파일의 한 속성입니다(FILE_ATTRIBUTE_INTEGRITY_STREAM). 이는 디렉터리의 속성이기도 합니다. 이 속성이 디렉터리에 존재하는 경우 디렉터리 내에서 생성된 모든 파일 및 디렉터리에 의해 이 속성이 상속됩니다. 편의를 위해 'format' 명령을 사용하여 포맷할 때 볼륨의 루트 디렉터리에 이 속성을 지정할 수 있습니다. 루트에서 이 속성을 설정하면 기본적으로 볼륨에 있는 모든 파일과 디렉터리에 이 속성이 전파됩니다. 예를 들면 다음과 같습니다.

 D:\>format /fs:refs /q /i:enable <volume>

D:\>format /fs:refs /q /i:disable <volume>

기본적으로, /i 스위치를 지정하는 경우 시스템의 동작은 볼륨이 미러링된 공간에 있는지 여부에 따라 결정됩니다. 미러링된 공간에서는 이점이 손실보다 클 것으로 예상하기 때문에 무결성이 보장됩니다. 응용 프로그램은 개별 파일에 대해 항상 이를 프로그래밍 방식으로 재정의할 수 있습니다.

'비트 랏'과의 전쟁

앞서 설명했듯이 ReFS와 저장 공간의 결합으로 디스크 손상 및 저장소 오류가 발생할 때 데이터의 복원력이 향상됩니다. '비트 랏'이라는 것 때문에 찾아내어 처리하기 어려운 데이터 형태가 존재합니다. 디스크의 일부가 시간에 따라 점차적으로 손상되고 이러한 부분은 자주 읽지 않기 때문에 대부분 발견되지 않은 채 지나치게 된다는 것이 '비트 랏'의 개념입니다. 이러한 부분을 읽고 손상된 것을 발견할 때면 이미 대체 복사본이 다른 오류로 인해 손상되거나 손실된 후인 경우가 많습니다.

비트 랏에 대응하기 위해 미러링된 저장 공간에 존재하는 ReFS 볼륨의 모든 메타데이터와 무결성 스트림 데이터를 주기적으로 스크러빙하는 시스템 작업이 추가되었습니다. 이로써 스크러빙을 위해 중복된 모든 복사본을 읽고 ReFS 체크섬을 사용하여 정상적인 상태인지를 확인할 수 있게 되었습니다. 체크섬이 일치하지 않으면 정상 복사본을 이용해 오류가 있는 복사본을 수정하게 됩니다.

FILE_ATTRIBUTE_NO_SCRUB_DATA의 파일 속성은 스크러버가 파일을 건너뛰어야 한다는 것을 나타냅니다. 이 속성은 응용 프로그램 개발자가 이러한 파일이 스크러빙되는 시기와 방식을 철저하게 관리하려는 의도로 개발하여 자체 무결성 정보를 관리하는 응용 프로그램에 유용합니다.

Integrity.exe 명령줄 도구는 무결성과 스크러빙 정책을 관리할 때 사용되는 강력한 방법입니다.

전면적 장애 시에도 볼륨 가용성 유지

우리는 많은 고객이 손상을 자동으로 확실하게 수정하기 위해 미러링된 저장 공간과 함께 ReFS를 사용할 것으로 기대합니다. 하지만 드물게 미러링된 공간의 볼륨까지 손상되는 경우가 있습니다. 예를 들어, 오류가 있는 시스템 메모리로 인해 데이터가 손상되고, 이어 디스크까지 침범하여 중복된 모든 복사본이 손상될 수 있습니다. 또한, ReFS 하에서 미러링된 저장 공간을 사용하지 않는 고객도 있을 수 있습니다.

볼륨이 손상되는 경우, ReFS는 라이브 볼륨의 네임스페이스에서 손상된 데이터를 제거하는 기능인 '복원'을 실행합니다. 이 기능의 목적은 복구 불가능한 손상이 정상 데이터의 가용성에 부정적 영향을 미치지 못하도록 하는 것입니다. 예를 들어, 디렉터리의 한 파일이 손상되고 자동으로 복구할 수 없는 경우, ReFS는 파일 시스템 네임스페이스에서 이 파일을 제거하여 볼륨의 나머지 부분을 복원합니다. 이 작업은 일반적으로 1초 미만의 시간에 완료될 수 있습니다.

기본적으로, 파일 시스템은 손상된 파일을 열거나 삭제할 수 없어 관리자의 대응을 불가능하게 만듭니다. 그러나 이 경우에도 ReFS는 손상된 데이터를 복원할 수 있기 때문에 관리자는 백업에서 이 파일을 복구하거나 파일 시스템을 오프라인으로 전환하지 않고 응용 프로그램에서 파일이 다시 생성되도록 할 수 있습니다. 이와 같은 중대한 혁신의 결과로 고가의 오프라인 디스크 확인 및 수정 도구를 실행할 필요가 없으며, 손상으로 인해 장시간 오프라인 상태를 유지하는 위험을 감수하지 않고도 대용량 데이터를 배포할 수 있습니다.

Windows 저장소 스택에 안성맞춤

우리는 유연성과 호환성을 극대화하도록 설계해야 함을 잘 알고 있었습니다. 이에 따라, 주변에 있는 다른 계층과의 호환성을 극대화하기 위해 다른 파일 시스템과 마찬가지로 저장소 스택에 연결되도록 ReFS를 설계했습니다. 예를 들어, ReFS는 BitLocker 암호화, 보안 강화를 위한 액세스 제어 목록, USN 저널, 변경 알림, 바로 가기 링크, 연결 지점, 탑재 지점, 재분석 지점, 볼륨 스냅숏, 파일 ID 및 Oplock을 완벽하게 활용할 수 있습니다. 대부분의 파일 시스템 필터가 거의 또는 전혀 수정되지 않고도 ReFS와 완벽하게 연동할 것으로 생각합니다. 내부 테스트 결과가 이를 잘 입증하는데, 예를 들면 기존 Forefront 바이러스 백신 솔루션 기능이 정상적으로 실행되는 것을 검증할 수 있었습니다.

NTFS의 물리적 형식에 의존하는 일부 파일에는 더 많은 수정이 필요합니다. 타사 바이러스 백신, 백업 등의 소프트웨어와 파일 시스템 호환성을 테스트하는 광범위한 호환성 프로그램이 운영되고 있습니다. ReFS에 대해서도 같은 프로그램이 진행 중이며 주요 파트너와 협력하여 발견된 호환성 문제를 해결할 예정입니다. 이러한 노력은 우리가 예전부터 해온 것으로 ReFS에만 국한된 것은 아닙니다.

유연성 측면에서 한 가지 알아둘 점은 ReFS와 저장 공간이 상호 보완적으로 실행되기는 하지만 서로 독립적으로 실행되도록 설계되었다는 것입니다. 이렇게 해야 불필요하게 서로를 제한하지 않으면서 두 구성 요소의 배포 유연성을 극대화할 수 있습니다. 다시 말해, 파트너의 기본 저장소에 사용할 ReFS 배포 등의 완전한 저장소 솔루션을 선택할 때 안정성과 성능 사이에서 득실을 저울질해야 합니다.

저장 공간을 사용하면 여러 시스템에서 저장소 풀을 공유할 수 있으며 이러한 시스템 사이에서 가상 디스크를 완벽하게 전환하여 오류에 대한 복원력을 높일 수 있습니다. 우리가 지향하는 시스템 설계 방식 때문에 ReFS에서는 이러한 이점을 완벽하게 활용할 수 있습니다.

사용

우리는 20년이 넘는 기간 동안 NTFS용으로 개발된 수만 가지의 정교하고 방대한 테스트를 사용하여 ReFS를 테스트하고 있습니다. 이러한 테스트는 시스템에 가해지는 스트레스, 전원 공급 중단 등의 장애, 확장성 및 성능 측면에서 예상되는 배포 요구를 재현하거나 그 이상의 조건을 가정합니다. 따라서, ReFS는 관리 환경에서 즉시 배포 테스트를 실시할 수 있습니다. 주요 파일 시스템의 첫 번째 버전이라는 점 때문에 몇 가지 당부할 사항이 있습니다. Windows 8에서 ReFS는 '베타'로 제공되지 않습니다. 데이터의 안정성이 그 무엇보다 중요하다는 원칙적인 입장을 견지하기 위해 Windows 8의 베타 과정을 마친 다음 베타가 아닌 일반 버전으로 ReFS를 제공할 예정입니다. 따라서 시스템의 다른 측면과 달리 ReFS는 초기 배포와 테스트에서 조심스럽게 접근해야 할 필요가 있습니다.

이러한 점을 염두에 두고 단계적 확대를 통해 ReFS를 구현할 예정입니다. 우선은 Windows Server용 저장소 시스템으로 도입한 다음 클라이언트용 저장소, 그리고 최종적으로 부팅 볼륨으로 확대해 나갈 계획입니다. 과거 새로운 파일 시스템들도 이와 같은 과정을 거쳐 도입되었습니다.

초기에는 ReFS를 파일 서버로 실행하는 부분에 중점을 두고 테스트했습니다. 고객은 특히 미러링된 저장 공간에서 ReFS를 파일 서버로 사용하여 좋은 효과를 거둘 것으로 생각합니다. 저장소 파트너와 협력하여 ReFS를 이들의 저장소 솔루션과 통합하기 위한 계획도 갖고 있습니다.

결론

저장 공간과 함께 ReFS는 향후 10년 이상 Windows에서 저장소의 근간을 이루게 될 것입니다. 앞으로 ReFS로 인해 저장소 기술이 많이 발전할 것으로 예상합니다. 이와 함께, 저장 공간과 ReFS는 미래의 혁신을 위해 그 가능성을 열어두고 설계되었으며 ReFS가 앞으로 가장 폭넓게 배포되는 파일 시스템으로 자리잡을 것으로 기대합니다.

- Surendra

FAQ:

Q) ReFS로 부르는 이유는 무엇인가요?

ReFS는 Resilient File System(복원력 있는 파일 시스템)의 약어입니다. 많은 차원에서 개선된 성능을 발휘하도록 설계되었지만 복원력은 그 중에서 가장 중요한 측면입니다.

Q) ReFS의 용량 한계는 얼마인가요?

아래 표에 온디스크 형식의 용량 한계가 나와 있습니다. 시스템 구성 등의 다른 실용적 제한(메모리 용량 등), 다양한 시스템 구성 요소에서 설정하는 제한, 및 데이터 집합을 입력하는 시간과 백업 시간 등 몇 가지 실용적 제한도 관련될 수 있습니다.

속성	온디스크 형식을 기준으로 한 용량 제한
단일 파일의 최대 크기	2^64-1 바이트
단일 볼륨의 최대 크기	포맷은 16KB 클러스터 크기(2^64 * 16 * 2^10)로 2^78 바이트를 지원합니다. Windows 스택의 주소 지정은 2^64 바이트까지 가능합니다.
디렉터리의 최대 파일 수	2^64
볼륨의 최대 디렉터리 수	2^64
최대 파일 이름 길이	32K 유니코드 문자
최대 경로 길이	32K
저장소 풀의 최대 크기	4 PB
시스템에서 저장소 풀의 최대 수	제한 없음
저장소 풀에서 최대 공간 수	제한 없음

Q) NTFS와 ReFS 사이에서 데이터를 변환할 수 있나요?

Windows 8에서는 데이터 변환 방법을 제공하지 않습니다. 데이터를 복사할 수는 있습니다. 이는 현재 이용되고 있는 데이터 집합의 크기, 이러한 변환의 실용성 및 변환 전과 후 아키텍처상의 가능한 변화 등을 고려하여 의도적으로 내린 설계 결정이었습니다.

Q) Windows Server 8에서 ReFS로 부팅할 수 있나요?

아니요. 그러한 작업은 구현되거나 지원되지 않습니다.

Q) 이동식 미디어 또는 드라이브에서 ReFS를 사용할 수 있나요?

아니요. 그러한 작업은 구현되거나 지원되지 않습니다.

Q) ReFS에서 더 이상 지원되지 않는 NTFS의 의미 체계나 기능으로는 무엇이 있나요?

ReFS에서 지원하지 않기로 결정한 NTFS 기능으로는 이름 있는 스트림, 개체 ID, 짧은 이름, 압축, 파일 수준 암호화(EFS), 사용자 데이터 트랜잭션, 구문 분석, 하드 링크, 확장 특성 및 할당량 등이 있습니다.

Q) 패리티 공간과 ReFS의 경우는 어떤가요?

ReFS는 저장 공간이 제공하는 오류 복원력 옵션에서 지원됩니다. Windows Server 8에서는 미러링된 공간에 대해서만 자동 데이터 수정이 실행됩니다.

Q) 클러스터링이 지원되나요?

장애 조치 클러스터링이 지원되며, 이때 개별 볼륨이 여러 시스템에 걸쳐 장애 조치할 수 있습니다. 또한, 클러스터에서 공유 저장소 풀도 지원됩니다.

Q) RAID의 경우는 어떤가요? ReFS의 스트라이핑, 미러링 또는 다른 형태의 RAID 기능을 어떻게 사용하나요? ReFS는 예를 들어 비디오에 필요한 읽기 성능을 제공하나요?

ReFS는 스트라이프 미러와 패리티를 포함하는 저장 공간의 데이터 중복 기능을 사용합니다. ReFS의 읽기 성능은 관련 코드를 상당 부분 공유하고 있는 NTFS의 성능과 유사할 것으로 예상합니다. 스트리밍 데이터를 확실하게 처리할 것입니다.

Q) ReFS에 데이터 중복 제거, DRAM과 저장소 사이의 2차 캐싱 및 쓰기 가능한 스냅숏이 없는 이유는 무엇인가요?

ReFS는 자체적으로 데이터 중복 제거를 제공하지 않습니다. 잘 알고 있는 플러그형 파일 시스템 아키텍처의 부작용 중 하나는 다른 데이터 중복 제거 제품이 NTFS의 경우와 마찬가지로 ReFS에 연결될 수 있다는 점입니다.

ReFS는 2차 캐시를 명시적으로 구현하지 않지만 고객이 이를 지원하는 타사 솔루션을 사용할 수 있습니다.

ReFS는 VSS와 함께 사용되어 Windows 환경에서 NTFS에 일관된 방식으로 스냅숏을 제공합니다. 현재로서는 쓰기 가능한 스냅숏 또는 64TB 이상의 스냅숏을 지원하지 않습니다.

Condividi tramite