윈도우 8 파일 시스템 변화 프리뷰

OSR Online의 Windows 8 Preview: File System Changes의 일부 주요 내용만 번역한 글 입니다.
헤더 파일의 내용을 기반으로 파일 시스템의 변화를 추측한 글인데 이런 추측을 한다는 것이 재미있는 것 같습니다.
급하게 번역 하다보니 어색한 문장들이 많네요. 혹시 잘못된 내용이 있으면 알려주세요.

여기서 다룬 내용들은 ntifs.h와 fltKernel.h와 같은 주요 헤더 파일의 변경된 내용들에 초점을 맞춰 쓰여졌습니다.
윈도우 8 프리 릴리즈(pre-release) 버전을 기준으로 쓰여졌기 때문에 최종 릴리즈 버전과 다를 수 있습니다.

새로운 파일 시스템 Protogon

아래 헤더 파일의 내용으로 보아 'Protogon' 이라는 윈도우 8의 새로운 파일 시스템을 추측할 수 있습니다.

#define FILESYSTEM_STATISTICS_TYPE_PROTOGON 4

typedef struct _PROTOGON_STATISTICS {
    ULONG Unused;
} PROTOGON_STATISTICS, *PPROTOGON_STATISTICS;

Protogon은 비스타의 WinFS와 같이 데이터베이스 개념을 이용한 파일 시스템일 것이라고 추측합니다.

데이터 검증

변화의 많은 부분은 데이터 검증 지원과 관련이 있습니다.
이러한 변화와 관련해서 두 개의 새로운 FSCTL (FSCTL_{GET,SET}_INTEGRITY_ INFORMATION)과
이 정보를 제어하는 아래의 구조체를 볼 수 있습니다.

#define FSCTL_INTEGRITY_FLAG_CHECKSUM_ENFORCEMENT_OFF (1)

typedef struct _FSCTL_INTEGRITY_INFORMATION_BUFFER {
    USHORT ChecksumAlgorithm; // Checksum algorithm. e.g. CHECKSUM_TYPE_UNCHANGED, CHECKSUM_TYPE_NONE, CHECKSUM_TYPE_CRC32
    USHORT Reserved; // Must be 0
    ULONG Flags; // FSCTL_INTEGRITY_FLAG_xxx
} FSCTL_INTEGRITY_INFORMATION_BUFFER, *PFSCTL_INTEGRITY_INFORMATION_BUFFER;

흥미로운 것은 "integrity streams"가 존재한다는 겁니다.

#define FILE_SUPPORTS_INTEGRITY_STREAMS 0x04000000 // winnt

현대 디스크 드라이브 기술은 과거 방식보다 매우 복잡해 졌고 데이터 무결성에 관한 문제가 있을 수 있습니다.
그래서 드라이브에서 데이터를 다시 읽어들이고 원래 기록하지 않은 무언가를 수신할 수 있습니다.
이러한 무결성 문제는 빈번하진 않지만 발생하고
대부분의 애플리케이션은 데이터 손상 같은 것에 견디도록 만들어지지 않았습니다.
일부 애플리케이션 (특히 데이터베이스 애플리케이션)은 데이터 손상 같은 것에 매우 민감합니다.
즉, 중요한 데이터베이스 정보가 손실되었을 때 컴포넌트 간의 관계 정보는 손실될 수 있습니다.
트랜젝션 데이터베이스 모델은 일부 실패로 부터 보호되지만
스토리지 미디어로 부터 리턴된 잘못된 데이터로 부터는 보호되지 않습니다.

데이터 중복 제거

헤더 파일로 부터 데이터 중복 제거 관련해서 아래의 새로 추가된 FSCTL 정의를 볼 수 있습니다.

// Dedup FSCTLs
// Values 162 - 170 are reserved for Dedup.
//
#if (_WIN32_WINNT >= 0x0602)
#define FSCTL_DEDUP_FILE CTL_CODE(FILE_DEVICE_FILE_SYSTEM, 165, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define FSCTL_DEDUP_QUERY_FILE_HASHES CTL_CODE(FILE_DEVICE_FILE_SYSTEM, 166, METHOD_NEITHER, FILE_READ_DATA)
#endif /*_WIN32_WINNT >= 0x0602 */

이것은 파일 해쉬가 퀴리되는 방식을 사용하도록 제안합니다.
그리고 데이터 중복 제거는 동일한 해쉬 값을 가지는 이러한 블럭들에 대해서 완료됩니다.

Offload 지원

헤더 파일에 Offload와 관련된 FSCTL 정의를 볼 수 있습니다.
Offload의 다른 형태와 유사한 경우 해쉬 연산과 I/O 작업과 같은 몇 가지 작업을
수행하기 위해서 하드웨어를 사용하도록 합니다.
이것은 지능적인 디스크 드라이브가 오브젝트 스토리지 디바이스 (Object Storage Device)와 같이
추가적으로 높은 수준의 처리를 가능하게 합니다.
파일 시스템에 결합되면 이런 장치들은 실제로 전문적인 지원을 제공할 수 있고
심지어 여러 장치에 걸쳐 데이터와 메타 데이터를 분리할 수 있습니다.
이것은 헤더 파일의 정보를 기반으로 한 추측이고 여전히 확실하진 않습니다.

#define FSCTL_OFFLOAD_READ CTL_CODE(FILE_DEVICE_FILE_SYSTEM, 153, METHOD_BUFFERED, FILE_READ_ACCESS)
#define FSCTL_OFFLOAD_WRITE CTL_CODE(FILE_DEVICE_FILE_SYSTEM, 154, METHOD_BUFFERED, FILE_WRITE_ACCESS)

파일 시스템 필터 드라이버가 Offload를 지원하지 않는다면 비활성화됩니다.

//
// To better guarentee backwards compatibility for
// selective new file system functionality, this new
// functionality will be disabled until all mini
// file system filters as well as legacy file system
// filters explicitly opt-in to this new functional-
// ity. This is controlled by a new registry key in
// the filters service defintion called
// "SupportedFeatures".
//
// File System filters need to update their .INF
// files to set state that the given functionality is
// now supported. Even if a filter can't actually
// support the given operations they should mark in
// the .INF that it is supported and modify their
// filter to fail the operations they don't support.
//

그래서 이와 관련된 파일 시스템 필터 드라이버 개발 시 이 새로운 기능을 인지해야 합니다.
그렇치 않으면 다른 드라이버의 기능 저해할 수 있는 잠재적 위험이 있습니다.

향상된 FCB 헤더 변화

향상된 FCB 헤더에는 Oplock 필드가 추가 되었고
헤더 초기화를 적절히 하기 위해서 헤더 파일의 FsRtlSetupAdvancedHeader 정의가 변경되었습니다.

//
// The following fields are valid only if the Version
// field in the FSRTL_COMMON_FCB_HEADER is greater
// than or equal to FSRTL_FCB_HEADER_V2. These
// fields are present in Windows 8 and beyond.
//
// For local file system this is the oplock field
// used by the oplock package to maintain current
// information about opportunistic locks on this
// file/directory.
//
// For remote file systems this field is reserved.

    union {

          OPLOCK Oplock;
          PVOID ReservedForRemote;

     };
#endif
#define FSRTL_FCB_HEADER_V2 (0x02)

위에서 새로운 FCB 헤더 버전 (2) 이 있다는 것을 선언하고 있습니다.

Oplocks

윈도우 8 oplock 지원 관련해서 새로운 oplock 필드가 추가 되었습니다.
아래 함수들은 새로 추가된 함수들을 볼 수 있습니다.

FsRtlCheckLockForOplock
FsRtlAreThereWaitingFileLocks

이러한 함수들은 파일에서의 byte range lock과 oplock 간 충돌을 방지하도록 최적화 되었습니다.
(예전에는 byte range lock과 oplock은 양립하지 못 했습니다.)

양쪽 모두를 허용하지 않는 이유는 byte range lock을 사용하는 애플리케이션은
일관된 데이터의 복사본을 원하고 그것은 캐싱의 기본 전제에 어긋나기 때문입니다.
그러나 데이터가 없는 파일에서의 byte range lock은 IPC를 위해서 애플리케이션에 의해 사용되고
이것은 데이터 일관성과 관련이 없습니다.
그래서 이러한 루틴은 실제적으로 여러 상황에서 oplock의 사용을 허용해야 합니다.

새로운 ECP 타입

Oplock과 관련된 또 다른 흥미로운 변화는 오픈에 대한 타겟 뿐만 아니라 부모까지
oplock 소유권 상태를 추적할 수 있는  ECP (Extra Create Parameter)에 대한 새로운 지원입니다.

DEFINE_GUID( GUID_ECP_DUAL_OPLOCK_KEY, 0x41621a14, 0xb08b, 0x4df1, 0xb6, 0x76, 0xa0, 0x5f, 0xfd, 0xf0, 0x1b, 0xea );

이것은 유용한 rename 동작이 될 것이라고 생각합니다.
그리고 이것은 oplock을 중지시키지 않고 동작을 계속 진행하도록 합니다.

이 외에도 IoCreateFileSpecifyDeviceObjectHint 호출 내부에서 재분석이 일어날 때마다
발생하는 에러 (STATUS_MOUNT_POINT_NOT _RESOLVED)에 대한 해결책이 있지만
파일 시스템 필터 드라이버에서는 완벽하게 해결되기 어렵습니다.
이것은 향후 윈도우 릴리즈 버전에서 해결되길 기대해 봅니다.

기본적으로 이 ECP 정보는 필터가 재분석 점에 대한 상세한 정보를 얻도록 합니다.

typedef struct _IO_DEVICE_HINT_ECP_CONTEXT {
    PDEVICE_OBJECT TargetDevice;
    UNICODE_STRING RemainingName;
} IO_DEVICE_HINT_ECP_CONTEXT, *PIO_DEVICE_HINT_ECP_CONTEXT;

아래 헤더 커멘트는 이 새로운 ECP 모델에 대해서 설명합니다.

// This GUID and structure are for passing back
// information from the I/O manager to the filter
// manager about a reparse when the reparse target
// goes to a new device.

캐시 매니저 (Cache Manager)

헤더 파일에는 캐시 매니저 관련된 변화들도 있습니다.

typedef struct _READ_AHEAD_PARAMETERS {

    CSHORT NodeByteSize;

    //
    //  Granularity of read aheads, which must be an
    //  even power of 2 and >= PAGE_SIZE
    //  See Also: CcSetReadAheadGranularity.

    ULONG Granularity;

    //
    //  The request size in number of bytes, to be
    //  used when performing pipelined read-aheads.
    //  Each read ahead request that is pipelined is
    //  broken into smaller PipelinedRequestSize
    //  sized requests. This is typically used to
    //  increase the throughput by parallelizing
    //  multiple requets instead of one single big
    //  one.
    //
    //  Special behavior:
    //  If this value is zero, then Cc will break
    //  every read-ahead request into two. This is
    //  used for backward compatibility where we
    //  used to break every read-ahead request for
    //  remote FS into two.
    //

    ULONG PipelinedRequestSize;

    //
    //  Growth of read ahead in percentage of the
    //  data that has already been read by the
    //  application so far
    //

    ULONG ReadAheadGrowthPercentage;

} READ_AHEAD_PARAMETERS, *PREAD_AHEAD_PARAMETERS;

몇가지 흥미있는 정보가 있지만 기존의 인터페이스는 이러한 값들을
얻거나 직접적으로 수정할 수 있는 어떠한 메커니즘도 제공하지 않습니다.
향후 릴리즈 버전에서는 개선되길 기대합니다.

아래는 새로 추가된 캐시 매니저 관련 추가된 함수들을 입니다.

CcCopyReadEx
CcScheduleReadAheadEx
CcSetAdditionalCacheAttributesEx

이 새 함수들은 "I/O issuer"  개념을 소개하고 PEPROCESS 포인터를 추가적인 파라미터로 사용합니다.

필터 매니저 (Filter Manager) 변화

헤더 파일의 필터 매니저 관련 변화 중에 가장 흥미로운 부분은 세션 컨텍스트입니다.
파일 시스템 필터 드라이버는 특정 상태를 세션과 연관지을 수 있습니다.
이러한 목적은 mini-filter의 변화를 세션 객체와 동기화시키기 위해서 입니다.
아래 함수들은 세션 컨텍스트를 지원하는 새 API들 중 일부입니다.

FltGetSectionContext
FltSetSectionContext
FltRegisterForDataScan
FltCreateSectionForDataScan
FltCloseSectionForDataScan

등록하는 구조체는 새 세션 컨텍스트에 맞게 변경되었습니다.
세션 컨텍스트는 윈도우 8 이상에서만 존재합니다.

윈도우 8에서 필터 매니저는 메일 슬롯 파일 시스템 (MSFS) 뿐만 아니라 
네임드 파이프 파일 시스템 (NPFS)도 지원합니다.
이러한 파일 시스템들을 필터하기 위해서 mini-filter는 등록 정보의 일부분으로
필터링 대상에 대한 관심을 나타내야 합니다.
그러기 위해서 필터 매니저는 네임드 파이프와 메일 슬롯을 오픈하기 위한 새로운 함수를 제공합니다.

FltCreateNamedPipeFile
FltCreate MailslotFile

이 함수들은 아마도 기존 OS 호출의 와퍼 함수일 것 입니다.

필터 매니저 API들은 재분석 점 지원과 같은 새 기능들을 지원하기 위해서 확장되었습니다
(GUID_ECP_FLT_CREATEFILE_TARGET 참고).

MDL 인터페이스는 FltReadFileExand와 FltWriteFileEx의 일부로 가능합니다.
이것은 모델의 근본적인 변화는 아니지만 필터 매니저 인터페이스를 직접 통해서는 할 수 없었던
기존 OS 인터페이스의 기능을 사용하고 싶은 mini-filter 개발을 단순화시켰습니다.

Fast I/O MDL 동작을 직접 호출을 위한 새로운 필터 매니저 API들도 추가되었습니다.

마지막으로 FltGetContextsEx을 이용해서 멀티 컨텍스트를 동시에 얻을 수 있는 새로운 지원도 추가 되었습니다.
그리고 FltReleaseContextsEx는 "bulk release" 작업을 지원합니다.

결론

여기서 다루지 못한 윈도우 8 파일 시스템의 다른 변경 사항들 (특히 보안 분야)도 있습니다.
그러나 확실한 점은 이러한 변화가 혁신적이기 보다는 진보에 가깝다라는 겁니다.

그리고 앞에서 언급 했듯이 여기서 다룬 내용들은 윈도우 8 릴리즈 버전과 다를 수 있습니다.