NTFS

NT 파일 시스템

개발사	마이크로소프트
정식 명칭	NT 파일 시스템
도입	1993년 7월 27일(1993-07-27) - 윈도우 NT 3.1
파티션 식별자	0x07 (MBR) EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (GPT)
구조
디렉터리 내용	B 트리 변형
파일 할당	비트맵
불량 블록	$BadClus (MFT 레코드)
제약사항
최대 볼륨 크기	264 클러스터 − 1 클러스터 (포맷); 256 TB − 64 KB (윈도우 10 버전 1703, 윈도우 서버 2016 또는 이전 구현) 8 PB − 2 MB (윈도우 10 버전 1709, 윈도우 서버 2019 또는 이후 구현)
최대 파일 크기	16 EB − 1 KB (포맷); 16 TB − 64 KB (윈도우 7, 윈도우 서버 2008 R2 또는 이전 구현) 256 TB − 64 KB (윈도우 8, 윈도우 서버 2012 또는 이후 구현) 8 PB − 2 MB (윈도우 10 버전 1709, 윈도우 서버 2019 또는 이후 구현)
최대 파일 수	4,294,967,295 (232−1)
최대 파일 이름 길이	255 UTF-16 코드 단위
파일 이름 내 허용 문자	Win32 네임스페이스: /\:*"?<>| 및 NUL을 제외한 모든 UTF-16 코드 단위 (대소문자 구분 안 함) POSIX 네임스페이스: / 및 NUL을 제외한 모든 UTF-16 코드 단위 (대소문자 구분함)
기능
날짜 사용 권한	생성, 수정, POSIX 변경, 액세스
날짜 범위	1601년 1월 1일 – 30828년 9월 14일 또는 60056년 5월 28일 (파일 시간은 1601년부터 100나노초 간격(초당 천만 개)을 세는 64비트 숫자임)
날짜 정밀도	100 ns
포크	예 (아래의 § 대체 데이터 스트림 (ADS) 참고)
특성	읽기 전용, 숨김, 시스템, 보관, 콘텐츠 인덱싱 안 함, 오프라인, 임시, 압축됨, 암호화됨
파일 시스템 권한	ACL
투명한 압축	파일별, LZ77 (윈도우 NT 3.51부터)
투명한 암호화	파일별, DESX (윈도우 2000부터), 트리플 DES (윈도우 XP부터), AES (윈도우 XP 서비스 팩 1, 윈도우 서버 2003부터)
데이터 중복 제거	예 (윈도우 서버 2012)
기타
지원 운영 체제	윈도우 NT 3.1 및 이후 버전 Mac OS X 10.3 및 이후 버전 (읽기 전용) 리눅스 커널 버전 2.6 및 이후 버전 리눅스 커널 버전 2.2–2.4 (읽기 전용) FreeBSD NetBSD OpenBSD (읽기 전용) 크롬OS 솔라리스 ReactOS (읽기 전용)

NT 파일 시스템(NT File System, NTFS, 뉴 테크놀로지 파일 시스템/New Technology File System)은 1990년대에 마이크로소프트가 개발한 독점 저널링 파일 시스템이다.

이 시스템은 FAT의 확장성, 보안 및 기타 제한 사항을 극복하기 위해 개발되었다. NTFS는 접근 제어 목록(ACL), 파일 시스템 암호화, 투명한 압축, 스파스 파일, 파일 시스템 저널링 및 사용 중인 시스템의 백업을 가능하게 하는 볼륨 섀도 복사본을 포함하여 FAT 및 HPFS에 없는 여러 기능을 추가한다.

윈도우 NT 3.1부터 시작하여, 파일 할당 테이블(FAT) 파일 시스템을 대체하는 윈도우 NT 제품군의 기본 파일 시스템이 되었다. NTFS 읽기/쓰기 지원은 리눅스와 BSD에서 리눅스의 NTFS3 및 리눅스와 BSD 모두의 NTFS-3G를 통해 사용할 수 있다.

NTFS는 드라이브에 저장된 다른 파일에 대한 메타데이터를 저장하기 위해 사용자에게 숨겨진 여러 파일을 사용하며, 이는 데이터를 읽을 때 속도와 성능을 향상시키는 데 도움이 된다.

역사

1980년대 중반, 마이크로소프트와 IBM은 차세대 그래픽 운영체제를 만들기 위한 공동 프로젝트를 결성했으며, 그 결과가 OS/2와 HPFS였다. 마이크로소프트는 여러 중요한 문제에 대해 IBM과 의견 차이를 보였고 결국 결별했다. OS/2는 IBM의 프로젝트로 남았고 마이크로소프트는 윈도우 NT와 NTFS 개발에 착수했다.

OS/2용 HPFS 파일 시스템에는 몇 가지 중요한 새 기능이 포함되어 있었다. 마이크로소프트가 새로운 운영체제를 만들 때 이러한 개념 중 상당수를 NTFS를 위해 차용했다. 초기 NTFS 개발자는 톰 밀러, 게리 키무라, 브라이언 앤드류, 데이비드 괴벨이었다.

아마도 이러한 공통된 혈통의 결과로 HPFS와 NTFS는 동일한 디스크 파티션 식별 유형 코드(07)를 사용한다. 수십 개의 사용되지 않는 코드 번호를 사용할 수 있었고 다른 주요 파일 시스템은 자체 코드를 가지고 있었기 때문에 동일한 파티션 ID 레코드 번호를 사용하는 것은 매우 이례적이다. 예를 들어 FAT는 9개 이상의 코드를 가지고 있다(FAT12, FAT16, FAT32 등 각각 하나씩). 파티션 유형 07에서 파일 시스템을 식별하는 알고리즘은 HPFS와 NTFS를 구별하기 위해 추가 확인을 수행해야 한다.

버전

마이크로소프트는 다섯 가지 버전의 NTFS를 출시했다.

NTFS 버전 번호	최초 운영체제	출시일	새로운 기능	비고
1.0	윈도우 NT 3.1	1993년	초기 버전	NTFS 1.0은 1.1 및 이후 버전과 호환되지 않는다. 윈도우 NT 3.5x에서 기록된 볼륨은 업데이트(NT 3.5x 설치 미디어에서 제공)가 설치될 때까지 윈도우 NT 3.1에서 읽을 수 없다.
1.1	윈도우 NT 3.5	1994년	명명된 스트림 및 접근 제어 목록	NTFS 압축 지원은 윈도우 NT 3.51에서 추가되었다.
1.2	윈도우 NT 4.0	1996년	보안 서술자	OS 출시 이후 흔히 NTFS 4.0으로 불린다.
3.0	윈도우 2000	2000년	디스크 할당량, 암호화 파일 시스템 형태의 파일 수준 암호화, 스파스 파일, 재분석 지점, 업데이트 시퀀스 번호(USN) 저널링, 분산 링크 추적, $Extend 폴더 및 해당 파일	윈도우 NT 4.0에서도 서비스 팩 4 업데이트를 통해 호환성을 확보했다. OS 출시 이후 흔히 NTFS 5.0으로 불린다.
3.1	윈도우 XP	2001년 10월	중복 MFT 레코드 번호를 사용하여 마스터 파일 테이블(MFT) 항목 확장 (손상된 MFT 파일 복구에 유용)	OS 출시 이후 흔히 NTFS 5.1로 불린다. 성능 향상을 위해 윈도우 8부터 LFS 버전 1.1이 버전 2.0으로 대체되었다.

NTFS.sys 버전 번호(예: 윈도우 2000의 v5.0)는 운영체제 버전을 기반으로 하며, NTFS 버전 번호(윈도우 XP 이후 v3.1)와 혼동해서는 안 된다.

이후 버전의 윈도우에서 새로운 파일 시스템 관련 기능이 추가되었지만, NTFS 자체는 변경되지 않았다. 예를 들어, 윈도우 비스타는 NTFS 심볼릭 링크, 트랜잭셔널 NTFS, 파티션 축소 및 자가 치유 기능을 구현했다. NTFS 심볼릭 링크는 파일 시스템의 새로운 기능이지만, 나머지는 이미 마련된 NTFS 기능을 활용하는 새로운 운영체제 기능이다.

확장성

NTFS는 4 KB 클러스터에 최적화되어 있지만 최대 2 MB의 클러스터 크기를 지원한다. (이전 구현은 최대 64 KB까지 지원한다) 사양상 지원할 수 있는 최대 NTFS 볼륨 크기는 2⁶⁴ − 1 클러스터이지만, 아래에서 설명하는 바와 같이 모든 구현이 이 이론적 최대치에 도달하는 것은 아니다.

윈도우 XP 프로페셔널에서 구현된 최대 NTFS 볼륨 크기는 파티션 테이블 제한으로 인해 부분적으로 2³² − 1 클러스터이다. 예를 들어 64 KB 클러스터를 사용하면 최대 윈도우 XP NTFS 볼륨 크기는 256 TB에서 64 KB를 뺀 값이다. 기본 클러스터 크기인 4 KB를 사용하면 최대 NTFS 볼륨 크기는 16 TB에서 4 KB를 뺀 값이다. 이 두 수치 모두 윈도우 XP SP1의 128 GB 제한보다 훨씬 높다. 512바이트 물리 섹터가 있는 하드 드라이브의 마스터 부트 레코드(MBR) 파티션 크기는 2 TiB로 제한되지만, 4 KiB 물리 섹터의 경우 MBR 파티션 크기 제한은 16 TiB이다. 대안으로 여러 GUID 파티션 테이블(GPT 또는 "동적") 볼륨을 사용하여 2 TiB보다 큰 단일 NTFS 볼륨을 생성할 수 있다. 마이크로소프트가 지원하는 방식으로 GPT 볼륨에서 윈도우 환경으로 부팅하려면 통합 확장 펌웨어 인터페이스(UEFI) 및 64비트 지원을 갖춘 시스템이 필요하다. GPT 데이터 디스크는 바이오스가 있는 시스템에서 지원된다.

개별 파일 크기에 대한 NTFS의 이론적 최대 제한은 16 EB(16 × 1024⁶ 또는 2⁶⁴ 바이트)에서 1 KB를 뺀 값으로, 총 18,446,744,073,709,550,592바이트(18.4 EB)이다. 윈도우 10 버전 1709 및 윈도우 서버 2019를 사용하면 구현된 최대 파일 크기는 8 PB에서 2 MB를 뺀 값 또는 9,007,199,252,643,840바이트(9 PB)이다.

상호 운용성

윈도우

서로 다른 NTFS 버전은 대부분 완전한 상위 및 하위 호환성을 갖추고 있지만, 구버전 마이크로소프트 윈도우에서 최신 NTFS 볼륨을 마운트하는 데는 기술적인 고려 사항이 있다. 이는 듀얼 부팅 및 외부 휴대용 하드 드라이브에 영향을 미친다. 예를 들어, 지원하지 않는 운영체제에서 윈도우의 "이전 버전"(섀도 복사본) 기능이 있는 NTFS 파티션을 사용하려고 하면 해당 이전 버전의 콘텐츠가 손실된다.

convert.exe라는 윈도우 명령줄 유틸리티는 HPFS(윈도우 NT 3.1, 3.5, 3.51에서만), FAT16 및 FAT32(윈도우 2000 이상)를 포함하여 지원되는 파일 시스템을 NTFS로 변환할 수 있다. 변환은 제자리에서 이루어지므로 기존 파일은 그대로 유지되며 프로세스 중에 다시 기록되지 않는다. 이 프로세스는 포맷하고 파일을 다시 쓰지 않고는 되돌릴 수 없다.

FreeBSD

1999년 5월에 출시된 FreeBSD 3.2에는 Semen Ustimenko가 작성한 읽기 전용 NTFS 지원이 포함되었다. 이 구현은 Christos Zoulas와 Jaromir Dolecek에 의해 NetBSD로 포팅되어 2000년 12월 NetBSD 1.5와 함께 출시되었다. FreeBSD의 NTFS 구현은 Julien Bordet에 의해 OpenBSD로도 포팅되었으며, 2011년 5월 1일 출시된 버전 4.9부터 i386 및 amd64 플랫폼에서 기본적으로 네이티브 읽기 전용 NTFS 지원을 제공한다.

리눅스

리눅스 커널 버전 2.1.74 이상에는 NTFS 파티션을 읽을 수 있는 Martin von Löwis가 작성한 드라이버가 포함되어 있다. 커널 버전 2.5.11 이상에는 파일 읽기를 지원하는 케임브리지 대학교의 Anton Altaparmakov와 Richard Russon이 작성한 새 드라이버가 포함되어 있다. 파일 쓰기 기능은 2006년 커널 버전 2.6.15에서 도입되어 사용자가 기존 파일에 쓸 수는 있지만 새 파일을 생성할 수는 없게 되었다. 파라곤의 NTFS 드라이버(아래 참조)는 커널 버전 5.15에 통합되었으며 일반, 압축 및 스파스 파일에 대한 읽기/쓰기와 저널 재생을 지원한다.

NTFS-3G는 처음에 Szabolcs Szakacsits에 의해 리눅스 커널 드라이버로 개발된 무료 GPL 라이선스 FUSE 구현 NTFS이다. 이는 macOS, FreeBSD, NetBSD, OpenBSD, 솔라리스, QNX 및 하이쿠와 같이 FUSE가 지원하는 다른 시스템에서 작동하도록 FUSE 프로그램으로 다시 작성되었으며 NTFS 파티션에 대한 읽기 및 쓰기를 허용한다. "Tuxera NTFS for Mac"이라는 NTFS-3G의 성능 향상 상용 버전도 NTFS-3G 개발자로부터 구입할 수 있다.

윈도우 자체 드라이버인 ntfs.sys를 사용하는 '래핑' 드라이버인 캡티브 NTFS가 리눅스용으로 존재한다. 이는 Filesystem in Userspace(FUSE) 프로그램으로 제작되어 GPL 하에 출시되었으나 캡티브 NTFS에 대한 작업은 2006년에 중단되었다.

리눅스 커널 버전 5.15부터는 3.1 버전까지의 NTFS 버전에서 작동하며 주로 파라곤 소프트웨어 그룹에 의해 유지 관리되는 완전한 기능의 NTFS 읽기-쓰기 드라이버인 NTFS3를 포함한다.

macOS

Mac OS X 10.3에는 FreeBSD의 Ustimenko가 작성한 읽기 전용 NTFS 구현이 포함되었다. 이후 2006년에 애플은 Anton Altaparmakov를 고용하여 Mac OS X 10.6을 위한 새로운 NTFS 구현을 작성하도록 했다. 네이티브 NTFS 쓰기 지원은 10.6 이상에 포함되어 있지만 기본적으로 활성화되어 있지는 않으며, 해당 기능을 활성화하기 위한 해결 방법은 존재한다. 그러나 사용자 보고에 따르면 해당 기능은 불안정하고 커널 패닉을 일으키는 경향이 있다.

파라곤 소프트웨어 그룹은 NTFS for Mac이라는 읽기-쓰기 드라이버를 판매하며, 이는 일부 씨게이트 하드 드라이브 모델에도 포함되어 있다.

OS/2

OS/2(및 eComStation 및 ArcaOS와 같은 파생형)용 NetDrive 패키지는 NTFS 볼륨에 대한 읽기 및 쓰기 액세스를 허용하는 플러그인을 지원한다.

DOS

MS-DOS용으로 아비라에서 만든 "NTFS4DOS"라는 개인용 무료 읽기/쓰기 드라이버가 있다.

네로 버닝 롬 소프트웨어의 일부로서 Ahead Software는 2002년에서 2004년 사이에 DR-DOS 7.0x용 "NTFSREAD" 드라이버(버전 1.200)를 개발했다.

보안

NTFS는 사용자 데이터를 보호하기 위해 접근 제어 목록과 사용자 수준 암호화를 사용한다.

접근 제어 목록 (ACL)

NTFS에서 각 파일 또는 폴더에는 소유자를 정의하고 두 개의 접근 제어 목록(ACL)을 포함하는 보안 서술자가 할당된다. 임의 접근 제어 목록(DACL)이라고 불리는 첫 번째 ACL은 어떤 사용자 또는 사용자 그룹에 의해 어떤 유형의 상호 작용(예: 읽기, 쓰기, 실행 또는 삭제)이 허용되거나 금지되는지를 정확하게 정의한다. 예를 들어, C:\Program Files 폴더의 파일은 모든 사용자가 읽고 실행할 수 있지만 관리자 권한을 가진 사용자만 수정할 수 있다. 윈도우 비스타는 DACL에 강제적 접근 제어 정보를 추가한다. DACL은 윈도우 비스타 및 이후 버전의 사용자 계정 컨트롤의 주요 초점이다.

시스템 접근 제어 목록(SACL)이라고 불리는 두 번째 ACL은 파일 또는 폴더와의 어떤 상호 작용을 감사할지, 그리고 활동이 성공했는지, 실패했는지 또는 둘 다인지에 따라 로그를 기록할지 여부를 정의한다. 예를 들어 회사의 민감한 파일에 감사를 활성화하여 누군가가 해당 파일을 삭제하거나 복사하려고 시도할 때, 그리고 성공 여부를 관리자가 알 수 있도록 할 수 있다.

암호화

 이 부분의 본문은 암호화 파일 시스템입니다.

암호화 파일 시스템(EFS)은 NTFS 볼륨의 모든 파일 또는 폴더에 대해 사용자에게 투명한 암호화를 제공한다. EFS는 EFS 서비스, 마이크로소프트의 암호화 API(CryptoAPI) 및 EFS 파일 시스템 런타임 라이브러리(FSRTL)와 연동하여 작동한다. EFS는 대량의 대칭 키 알고리즘 대칭 키(파일 암호화 키 또는 FEK라고도 함)를 사용하여 파일을 암호화함으로써 작동한다. 이는 비대칭 키 알고리즘 암호를 사용하는 것보다 대량의 데이터를 암호화하고 복호화하는 데 상대적으로 시간이 적게 걸리기 때문이다. 파일을 암호화하는 데 사용되는 대칭 키는 파일을 암호화한 사용자와 연관된 공개 키로 암호화되며, 이 암호화된 데이터는 암호화된 파일의 대체 데이터 스트림에 저장된다. 파일을 복호화하기 위해 파일 시스템은 사용자의 개인 키를 사용하여 데이터 스트림에 저장된 대칭 키를 복호화한다. 그런 다음 대칭 키를 사용하여 파일을 복호화한다. 이 작업은 파일 시스템 수준에서 수행되므로 사용자에게는 투명하게 이루어진다. 또한 사용자가 키에 대한 액세스 권한을 잃을 경우를 대비하여 추가 복호화 키에 대한 지원이 EFS 시스템에 내장되어 있어 필요한 경우 복구 에이전트가 파일에 액세스할 수 있다. NTFS에서 제공하는 암호화와 NTFS에서 제공하는 압축은 상호 배타적이다. 즉, 동일한 파일에 대해 동시에 사용할 수 없다. 그러나 하나는 NTFS를 사용하고 다른 하나는 서드파티 도구를 사용할 수는 있다.

EFS 지원은 윈도우의 Basic, Home 및 MediaCenter 버전에서는 사용할 수 없으며, Professional, Ultimate 및 Server 버전을 설치한 후 또는 윈도우 도메인 내에서 엔터프라이즈 배포 도구를 사용하여 활성화해야 한다.

기능

저널링

NTFS는 저널링 파일 시스템이며 NTFS 로그($LogFile)를 사용하여 볼륨에 대한 메타데이터 변경 사항을 기록한다. 이는 FAT가 제공하지 않는 기능이며, 시스템 충돌이나 단편화 제거 API에 의해 수행된 데이터 이동 시 NTFS의 복잡한 내부 데이터 구조가 일관성을 유지하도록 보장하고 볼륨이 다시 마운트될 때 이러한 중요한 데이터 구조에 대한 커밋되지 않은 변경 사항을 쉽게 롤백할 수 있게 하는 데 중요하다. 특히 영향을 받는 구조는 볼륨 할당 비트맵, MFT 레코드에 저장된 일부 가변 길이 속성의 이동과 같은 MFT 레코드의 수정 및 속성 목록, 디렉토리 및 보안 서술자에 대한 인덱스이다.

($LogFile) 형식은 여러 버전을 거쳐 발전해 왔다.

윈도우 버전	$LogFile 형식 버전
윈도우 NT 4.0	1.1
윈도우 2000
윈도우 XP
윈도우 비스타
윈도우 7
윈도우 8	2.0
윈도우 8.1
윈도우 10
윈도우 11

윈도우 8, 윈도우 10, 윈도우 11에서 구현된 $LogFile 버전의 비호환성으로 인해 윈도우 7( 및 이전 버전의 윈도우)은 2.0 버전의 $LogFile을 인식하지 못한다. NTFS 볼륨이 정상적으로 분리될 때 $LogFile을 1.1 버전으로 다운그레이드하여 하위 호환성을 제공한다. 호환되는 버전의 윈도우에서 마운트할 때 다시 2.0 버전으로 업그레이드된다. 그러나 로그오프 상태에서 디스크로 하이브리드 부팅 또는 빠른 부팅(기본적으로 활성화됨)을 수행하면 마운트된 파일 시스템이 분리되지 않으므로 활성 파일 시스템의 $LogFile이 1.1 버전으로 다운그레이드되지 않는다. 8.0 이전 버전의 윈도우에서 2.0 버전의 $LogFile을 처리하지 못하면 CHKDSK 디스크 복구 유틸리티가 불필요하게 호출되는 결과가 발생한다. 이는 특히 8.0 이전 및 이후 버전의 윈도우가 포함된 멀티 부팅 시나리오나 구버전과 신버전 간에 저장 장치를 자주 옮길 때 문제가 된다. $LogFile이 최신 버전으로 자동 업그레이드되는 것을 방지하는 윈도우 레지스트리 설정이 존재한다. 또한 하이브리드 부팅을 비활성화하여 이 문제를 해결할 수도 있다.

USN 저널(업데이트 시퀀스 번호 저널)은 볼륨의 파일, 스트림 및 디렉토리뿐만 아니라 다양한 속성 및 보안 설정에 대한 변경 사항을($Extend\$UsnJrnl에) 기록하는 시스템 관리 기능이다. 저널은 애플리케이션이 볼륨의 변경 사항을 추적할 수 있도록 제공된다. 이 저널은 시스템 볼륨이 아닌 볼륨에서 활성화하거나 비활성화할 수 있다.

하드 링크

하드 링크 기능을 사용하면 서로 다른 파일 이름이 동일한 파일 콘텐츠를 직접 참조할 수 있다. 각 볼륨은 자체 MFT를 가지고 있기 때문에 하드 링크는 동일한 볼륨 내의 파일에만 연결할 수 있다. 하드 링크는 원래 윈도우 NT에서 POSIX 하위 시스템을 지원하기 위해 포함되었다.

하드 링크는 파일 크기, 수정 날짜 및 속성과 같은 파일 메타데이터를 기록하는 동일한 MFT 레코드(아이노드)를 사용하지만 NTFS는 성능 향상을 위해 이 데이터를 디렉토리 항목에도 캐시한다. 즉, FindFirstFile/FindNextFile 계열 API(POSIX opendir/readdir API에 해당)를 사용하여 디렉토리 내용을 나열할 때 디렉토리를 나열하는 소프트웨어는 이름과 아이노드 외에도 이 캐시된 정보를 수신한다. 그러나 파일이 닫힐 때만 정보 업데이트가 보장되고 파일을 연 디렉토리에 대해서만 업데이트가 보장되므로 소프트웨어가 최신 정보를 보지 못할 수 있다. 즉, 파일이 하드 링크를 통해 여러 이름을 가진 경우 한 이름을 통해 파일을 업데이트해도 다른 이름과 관련된 캐시된 데이터는 업데이트되지 않는다. 소프트웨어는 GetFileInformationByHandle(POSIX fstat 함수에 해당)을 사용하여 최신 데이터를 얻을 수 있다. 이는 파일 자체에 대한 액세스 권한이 없는 핸들을 사용하여 수행할 수 있으며(CreateFile에 dwDesiredAccess로 0 전달), 이 핸들을 닫으면 캐시된 정보가 업데이트되는 부수적인 효과가 있다.

윈도우는 NTFS에서 짧은(8.3) 파일 이름을 지원하기 위해 하드 링크를 사용한다. 8.3 파일 이름으로만 작동하는 레거시 애플리케이션이 있기 때문에 운영체제 지원이 필요하지만 이 지원은 비활성화할 수 있다. 이 경우 추가 파일 이름 레코드 및 디렉토리 항목이 추가되지만 일반 하드 링크와 달리 8.3 이름과 긴 파일 이름이 함께 연결되고 업데이트된다.

NTFS 파일 시스템은 파일 하나당 1023개의 하드 링크 제한이 있다.

대체 데이터 스트림 (ADS)

 이 부분의 본문은 포크 (파일 시스템)입니다.

 마크 오브 더 웹 문서를 참고하십시오.

대체 데이터 스트림을 사용하면 "파일명:스트림명"(예: "text.txt:extrastream") 형식을 사용하여 둘 이상의 데이터 스트림을 파일 이름과 연결할 수 있다(포크). 이러한 스트림은 기본적으로 윈도우에 내장된 일반적인 GUI 애플리케이션을 통해 사용자에게 표시되거나 편집 가능하게 만들어지지 않으므로 대부분의 사용자로부터 그 존재가 가려진다. 도움이 되는 메타데이터를 목적으로 하지만, 그 난해한 특성으로 인해 악성 코드, 스파이웨어, 보이지 않는 브라우저 기록 및 기타 잠재적으로 원치 않는 정보의 은닉처가 될 가능성이 있다.

대체 스트림은 파일 탐색기에 나열되지 않으며 그 크기는 파일 크기에 포함되지 않는다. ADS 지원이 없는 다른 파일 시스템으로 파일을 복사하거나 이동할 때 대체 데이터 스트림을 보존할 수 없다는 경고가 사용자에게 표시된다. 일반적으로 파일이 이메일에 첨부되거나 웹사이트에 업로드되는 경우에는 그러한 경고가 제공되지 않는다. 따라서 중요한 데이터에 대체 스트림을 사용하면 문제가 발생할 수 있다. 마이크로소프트는 선택한 볼륨의 스트림을 볼 수 있도록 Streams라는 다운로드 가능한 도구를 제공한다. 윈도우 파워셸 3.0부터는 Add-Content, Clear-Content, Get-Content, Get-Item, Remove-Item, Set-Content의 6개 명령렛을 사용하여 기본적으로 ADS를 관리할 수 있다.

Zone.Identifier라는 작은 ADS는 외부 사이트에서 다운로드한 파일을 실행하기에 안전하지 않을 수 있는 파일로 표시하기 위해 인터넷 익스플로러 및 대부분의 브라우저에 의해 추가된다. 그러면 로컬 셸은 파일을 열기 전에 사용자 확인을 요구한다. 사용자가 더 이상 이 확인 대화 상자를 원하지 않는다고 표시하면 이 ADS는 삭제된다. 이 기능은 "마크 오브 더 웹"(Mark of the Web)으로도 알려져 있다. 모든 크로미엄(예: 구글 크롬) 및 파이어폭스 기반 웹 브라우저도 다운로드한 파일에 Zone.Identifier 스트림을 기록한다.

악성 소프트웨어는 코드를 숨기기 위해 대체 데이터 스트림을 사용해 왔다. 2000년대 후반부터 일부 악성 소프트웨어 스캐너 및 기타 특수 도구는 대체 데이터 스트림을 확인한다. ADS와 관련된 위험, 특히 개인 정보 보호 및 Zone.Identifier 스트림과 관련된 위험 때문에 사용자 친화적인 방식으로 파일에서 스트림(위험하다고 인지되는 특정 스트림 또는 모든 스트림)을 제거하도록 특별히 설계된 소프트웨어가 존재한다.

NTFS 스트림은 윈도우 NT 3.1에서 매킨토시용 서비스(SFM)가 리소스 포크를 저장할 수 있도록 도입되었다. 현재 버전의 윈도우 서버에는 더 이상 SFM이 포함되어 있지 않지만, 서드파티 애플 파일링 프로토콜(AFP) 제품(예: GroupLogic의 ExtremeZ-IP)은 여전히 파일 시스템의 이 기능을 사용한다.

파일 압축

'압축됨' 속성을 설정하여 폴더 또는 파일별로 압축을 활성화한다. 폴더에서 압축을 활성화하면 해당 폴더로 이동하거나 저장된 모든 파일이 LZNT1 알고리즘(LZ77의 변형)을 사용하여 자동으로 압축된다. 압축 알고리즘은 최대 4 KB의 클러스터 크기를 지원하도록 설계되었다. NTFS 볼륨의 클러스터 크기가 4 KB보다 크면 NTFS 압축을 사용할 수 없다. 데이터는 16개 클러스터 덩어리(최대 64 KB 크기)로 압축된다. 압축을 통해 64 KB의 데이터가 60 KB 이하로 줄어들면 NTFS는 불필요한 4 KB 페이지를 빈 스파스 파일 클러스터처럼 취급하며 기록하지 않는다. 이를 통해 OS가 단지 단편들의 체인을 따르기만 하면 되므로 합리적인 임의 접근 시간을 가질 수 있다.

압축은 반복적인 내용이 있고, 거의 기록되지 않으며, 일반적으로 순차적으로 액세스되고, 그 자체가 압축되지 않은 파일에서 가장 잘 작동한다. 하드 디스크 공간이 제한된 단일 사용자 시스템은 압축 가능성에 따라 4 KB에서 64 KB 이상의 작은 파일에 대해 NTFS 압축의 이점을 얻을 수 있다. 약 900바이트보다 작은 파일은 MFT의 디렉토리 항목 내에 저장된다.

윈도우 이외의 운영체제의 경우, 모든 버전의 NTFS-3G 드라이버는 개발자에 따르면 압축된 파일 읽기를 지원하지만, 압축된 파일에 데이터를 추가(파일 크기가 늘어나는 결과를 초래하는 새 데이터 추가)하는 지원은 2009년 11월에 추가되었다. 기존 압축 데이터를 덮어쓰는 기능은 2010년 8월부터 지원된다. CompactGUI와 같은 다양한 프로그램이 NTFS 파일 압축을 활용한다.

장점

빠른 멀티 코어 프로세서 사용자는 애플리케이션과 데이터를 압축함으로써 사용 공간 감소뿐만 아니라 애플리케이션 속도 향상을 경험할 수 있다. SSD 컨트롤러가 이미 데이터를 압축하는 경우에도 전송되는 데이터가 적기 때문에 여전히 I/O 감소 효과가 있다.

마이크로소프트의 NTFS 개발 팀의 연구에 따르면, 4 KB(기본) 클러스터(블록) 크기를 갖는 NTFS 볼륨에서 압축 파일의 합리적인 최대 크기는 50–60 GB이다. 이 합리적인 최대 크기는 클러스터 크기가 작은 볼륨의 경우 급격히 감소한다.

단점

64 KB보다 작은 모든 덩어리가 단편이 되기 때문에 압축 가능한 큰 파일은 심하게 단편화된다. SSD 드라이브와 같은 플래시 메모리는 기계식 하드 디스크 드라이브와 같은 헤드 이동 지연 및 높은 액세스 시간이 없으므로 단편화로 인한 패널티가 적다.

윈도우 2000은 압축 해제 필터가 아직 로드되지 않았기 때문에 NTLDR이 압축되어 있으면 시작할 수 없다. 이후 버전의 윈도우는 중요한 시스템 파일을 압축하는 것을 허용하지 않는다.

시스템 압축

윈도우 10부터 마이크로소프트는 4K/8K/16K 블록 크기를 갖는 XPRESS 알고리즘과 LZX 알고리즘에 기반한 새로운 파일 압축 기법을 도입했다. 둘 다 LZNT1에 없던 허프만 엔트로피 부호화 및 범위 부호화가 추가된 LZ77의 변형이다. 이러한 압축 알고리즘은 윈도우 이미징 포맷(WIM 파일)에서 가져왔다.

새로운 압축 기법은 윈도우 시스템 파일을 압축하여 디스크 사용량을 줄이는 CompactOS 기능에서 사용된다. CompactOS는 NTFS 파일 압축의 확장이 아니며 '압축됨' 속성을 사용하지 않는다. 대신 각 압축 파일에 WOF(Windows Overlay Filter) 태그가 있는 재분석 지점을 설정하지만, 실제 데이터는 "WofCompressedData"라는 이름의 대체 데이터 스트림에 저장된다. 이 스트림은 WOF 파일 시스템 필터 드라이버에 의해 실시간으로 압축 해제되며 기본 파일은 빈 스파스 파일이다. 이 설계는 순수하게 읽기 전용 액세스를 위한 것이므로 압축 파일에 쓰기를 수행하면 자동으로 압축이 해제된다.

CompactOS 압축은 윈도우 ADK의 DISM 도구에서 /compact 플래그를 사용하여 OS 이미지를 준비하는 OEM을 위한 것이지만, compact 명령의 /exe 플래그를 사용하여 파일별로 수동으로 켤 수도 있다. CompactOS 알고리즘은 핵심 NTFS 압축과 달리 압축 데이터를 연속적으로 할당된 덩어리에 기록함으로써 파일 단편화를 방지한다.

CompactOS 파일 압축은 윈도우 8.1에서 도입된 WIMBoot 기능의 개선된 버전이다. WIMBoot는 별도의 숨겨진 디스크 파티션에 있는 압축된 WIM 이미지에 시스템 파일을 보관함으로써 윈도우 디스크 사용량을 줄인다. CompactOS와 유사하게 윈도우 시스템 디렉토리에는 WOF 태그가 있는 재분석 지점으로 표시된 스파스 파일만 포함되며, Windows Overlay Filter 드라이버는 WIM 이미지에서 파일 콘텐츠를 실시간으로 압축 해제한다. 그러나 WIMBoot는 시스템 파일의 새로운 업데이트 버전을 시스템 파티션에 기록해야 하므로 디스크 공간을 소모하게 되어 CompactOS보다 덜 효과적이다.

스파스 파일

스파스 파일: 빈 바이트는 저장할 필요가 없으므로 메타데이터로 표현할 수 있다.

스파스 파일은 실제 저장 공간이 사용되지 않는 빈 세그먼트가 산재해 있는 파일이다. 애플리케이션에게 파일은 0으로 채워진 영역이 있는 일반 파일처럼 보이며, 파일 시스템은 각 스파스 파일에 대해 이러한 영역의 내부 목록을 유지 관리한다. 스파스 파일에 반드시 희소한 0 영역이 포함되어야 하는 것은 아니다. "스파스 파일" 속성은 단지 파일이 그러한 영역을 가질 수 있음을 의미한다.

예를 들어 데이터베이스 애플리케이션은 스파스 파일을 사용할 수 있다. 압축된 파일과 마찬가지로 할당량 제한을 결정할 때 스파스 파일의 실제 크기는 고려되지 않는다.

섀도 복사본

볼륨 섀도 복사본 서비스(VSS)는 카피 온 라이트 기술을 통해 오래된, 새로 덮어써진 데이터를 섀도 복사본으로 복사하여 NTFS 볼륨에 있는 파일 및 폴더의 과거 버전을 유지한다. 사용자는 나중에 이전 버전의 복구를 요청할 수 있다. 이는 또한 데이터 백업 프로그램이 파일 시스템에서 현재 사용 중인 파일을 보관할 수 있게 해준다.

윈도우 비스타는 시스템 복원 및 이전 버전 기능과 함께 사용할 수 있는 영구 섀도 복사본도 도입했다. 그러나 영구 섀도 복사본은 이전 운영체제가 해당 NTFS 볼륨을 마운트할 때 삭제된다. 이는 이전 운영체제가 더 새로운 형식의 영구 섀도 복사본을 이해하지 못하기 때문이다.

트랜잭션

윈도우 비스타부터 애플리케이션은 트랜잭셔널 NTFS(TxF)를 사용하여 파일에 대한 여러 변경 사항을 단일 트랜잭션으로 그룹화할 수 있다. 트랜잭션은 모든 변경 사항이 발생하거나 전혀 발생하지 않음을 보장하며, 트랜잭션 외부의 어떤 애플리케이션도 커밋될 때까지 변경 사항을 볼 수 없음을 보장한다.

이는 섀도 복사본(즉, 카피 온 라이트)에 사용되는 것과 유사한 기술을 사용하여 덮어써진 데이터를 안전하게 롤백할 수 있도록 보장하고, 아직 커밋되지 않은 트랜잭션 또는 커밋되었으나 아직 완전히 적용되지 않은 트랜잭션(참가자 중 한 명이 커밋하는 동안 시스템 충돌이 발생한 경우)을 표시하기 위해 CLFS 로그를 사용한다.

트랜잭셔널 NTFS는 트랜잭션을 로컬 NTFS 볼륨으로만 제한하지 않고 별도의 볼륨에 저장된 데이터, 로컬 레지스트리 또는 SQL 데이터베이스 또는 시스템 서비스 또는 원격 서비스의 현재 상태와 같은 다른 위치의 다른 트랜잭션 데이터 또는 작업도 포함한다. 이러한 트랜잭션은 특정 서비스인 DTC를 사용하는 모든 참여자와 네트워크 전체에서 조정되어 모든 참여자가 동일한 커밋 상태를 수신하고 참여자 중 한 명에 의해 검증된 변경 사항을 전송하도록 보장한다(다른 참여자가 이전 데이터에 대한 로컬 캐시를 무효화하거나 진행 중인 커밋되지 않은 변경 사항을 롤백할 수 있도록 함). 예를 들어 트랜잭셔널 NTFS를 사용하면 로컬 라이브 또는 오프라인 캐시를 포함하여 네트워크 전체에서 일관된 분산 파일 시스템을 생성할 수 있다.

마이크로소프트는 현재 TxF 사용을 권장하지 않는다. "마이크로소프트는 개발자가 대체 수단을 활용할 것을 강력히 권장한다"라며 "TxF는 마이크로소프트 윈도우의 향후 버전에서 사용 가능하지 않을 수 있기 때문"이라고 밝혔다.

할당량

디스크 할당량은 NTFS v3에서 도입되었다. 이를 통해 NTFS를 지원하는 버전의 윈도우를 실행하는 컴퓨터의 관리자는 사용자가 사용할 수 있는 디스크 공간의 임계값을 설정할 수 있다. 또한 관리자가 각 사용자가 사용 중인 디스크 공간의 양을 추적할 수 있게 해준다. 관리자는 사용자가 공간의 상한선에 도달하기 전에 경고를 받을 수 있는 특정 수준의 디스크 공간을 지정할 수 있으며, 상한선에 도달하면 사용자의 액세스를 거부할 수 있다. 디스크 할당량은 NTFS의 투명한 파일 압축이 활성화된 경우 이를 고려하지 않는다. 사용 가능한 공간의 양을 조회하는 애플리케이션은 할당량이 적용된 사용자에게 남은 사용 가능한 공간의 양을 보게 된다.

재분석 지점

 이 부분의 본문은 NTFS 링크입니다.

NTFS v3에서 도입된 NTFS 재분석 지점은 파일 또는 디렉토리의 사용자 공간 속성에 재분석 태그를 연결하여 사용된다. 마이크로소프트는 심볼릭 링크, 디렉토리 접합부 및 볼륨 마운트 포인트를 포함하여 여러 기본 태그를 포함한다. 객체 관리자가 파일 시스템 이름 조회를 구문 분석하고 재분석 속성을 만나면 이름 조회를 다시 분석하여 사용자 제어 재분석 데이터를 윈도우에 로드된 모든 파일 시스템 필터 드라이버에 전달한다. 각 필터 드라이버는 재분석 데이터를 검사하여 해당 재분석 지점과 연관되어 있는지 확인하고, 해당 필터 드라이버가 일치하는 것으로 판단하면 파일 시스템 요청을 가로채서 특수 기능을 수행한다.

날짜 및 시간

NTFS는 윈도우 NT 에포크를 따라 1601년 초부터 100나노초 간격을 세는 64비트 정수형으로 날짜 및 시간 속성을 저장한다. 1601년은 400년 주기로 작동하는 그레고리력과 날짜 범위의 시작을 맞추어 계산을 단순화하기 위해 선택되었으며, 윈도우 NT가 구상될 당시 1601-2000 주기가 활성 주기였다.

NTFS는 네 가지 유형의 타임스탬프를 기록한다. 파일 생성 시간(리눅스에서는 "출생 시간"으로 해석됨), 마지막 수정 시간, MFT 레코드의 마지막 수정(리눅스에서는 "변경 시간"으로 해석됨) 및 마지막 액세스 시간이다. 이러한 각 시간은 100나노초의 동일한 세밀도를 갖는다.

제한 사항

크기 조정

윈도우 비스타부터 마이크로소프트는 파티션을 축소하거나 확장하는 기능을 내장했다. 그러나 이 기능은 페이징 파일 조각이나 이동 불가능으로 표시된 파일을 재배치하지 않으므로 볼륨을 축소하려면 종종 페이지 파일, 윈도우 검색 인덱스 및 시스템 복원에서 사용하는 모든 섀도 복사본을 재배치하거나 비활성화해야 한다. 다양한 서드파티 도구가 NTFS 파티션 크기를 조정할 수 있다.

원드라이브

2017년부터 마이크로소프트는 원드라이브 파일 구조를 NTFS 디스크에 두도록 요구한다. 이는 원드라이브 파일 요청 기능이 원드라이브에 저장된 파일 및 폴더를 로컬 파일 시스템에 연결하기 위해 NTFS 재분석 지점을 사용하기 때문이며, 이로 인해 해당 파일 또는 폴더를 이전 버전의 윈도우, 다른 NTFS 파일 시스템 드라이버 또는 이를 지원하도록 업데이트되지 않은 파일 시스템 및 백업 유틸리티와 함께 사용할 수 없게 된다.

구조

NTFS는 부팅 정보를 보관하는 파티션 부트 섹터(PBS), 파일 시스템의 모든 파일과 폴더의 레코드를 저장하는 마스터 파일 테이블, 메타데이터를 더 효율적으로 구조화하는 데 도움이 되는 일련의 메타 파일, 데이터 스트림 및 잠금 메커니즘을 포함한 여러 구성 요소로 구성된다.

내부적으로 NTFS는 B 트리를 사용하여 파일 시스템 데이터를 인덱싱한다. 파일 시스템 저널은 파일 시스템 메타데이터의 무결성을 보장하는 데 사용되지만 개별 파일의 내용은 보장하지 않는다. NTFS를 사용하는 시스템은 FAT 파일 시스템에 비해 신뢰성이 향상된 것으로 알려져 있다.

NTFS는 0x0000을 제외하고 이름 인코딩(예: 파일 이름, 스트림 이름 또는 인덱스 이름)을 위해 모든 16비트 값 시퀀스를 허용한다. 이는 UTF-16 코드 단위가 지원됨을 의미하지만 파일 시스템은 시퀀스가 유효한 UTF-16인지 확인하지 않는다(유니코드 표준에 제한되지 않고 모든 단정수형 시퀀스를 허용함). Win32 네임스페이스에서 모든 UTF-16 코드 단위는 대소문자를 구분하지 않지만 POSIX 네임스페이스에서는 대소문자를 구분한다. 파일 이름은 255개의 UTF-16 코드 단위로 제한된다. 특정 이름은 볼륨 루트 디렉토리에 예약되어 있으며 파일에 사용할 수 없다. 이들은 $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, . (마침표), $Bitmap, $Boot, $BadClus, $Secure, $UpCase, $Extend이다. . (마침표)와 $Extend는 모두 디렉토리이고 나머지는 파일이다. NT 커널은 전체 경로를 32,767개의 UTF-16 코드 단위로 제한한다. 코드 포인트 및 파일 이름에 대한 몇 가지 추가 제한 사항이 있다.

파티션 부트 섹터 (PBS)

NTFS 부트 섹터 내용 (문자열을 제외한 모든 값은 리틀 엔디언 순서로 저장된다.)

바이트 오프셋	필드 길이	일반적인 값	필드 이름		목적
0x00	3 바이트	0xEB5290	x86 JMP 및 NOP 명령어		이 부트 섹터의 데이터 구조 뒤에서 실행을 계속하게 한다.
0x03	8 바이트	"NTFS    " "NTFS" 단어 뒤에 4개의 공백(0x20)이 옴	OEM ID		이것이 NTFS 파일 시스템임을 나타내는 매직 넘버이다.
0x0B	2 바이트	0x0200	BPB	섹터당 바이트 수	디스크 섹터의 바이트 수.
0x0D	1 바이트	0x08		클러스터당 섹터 수	클러스터의 섹터 수. 값이 0x80보다 크면 섹터 양은 이 필드를 음수로 간주한 절대값의 2의 거듭제곱이다.
0x0E	2 바이트	0x0000		예약된 섹터, 사용되지 않음
0x10	3 바이트	0x000000		사용되지 않음	이 필드는 항상 0이다.
0x13	2 바이트	0x0000		NTFS에서 사용되지 않음	이 필드는 항상 0이다.
0x15	1 바이트	0xF8		미디어 서술자	드라이브 유형. 0xF8은 하드 드라이브를 나타내는 데 사용된다(여러 크기의 플로피와 대조됨).
0x16	2 바이트	0x0000		사용되지 않음	이 필드는 항상 0이다.
0x18	2 바이트	0x003F		트랙당 섹터 수	드라이브 트랙의 디스크 섹터 수.
0x1A	2 바이트	0x00FF		헤드 수	드라이브의 헤드 수.
0x1C	4 바이트	0x0000003F		숨겨진 섹터	파티션 앞에 오는 섹터 수.
0x20	4 바이트	0x00000000		사용되지 않음	NTFS에서 사용되지 않음
0x24	4 바이트	0x00800080	EBPB	사용되지 않음	NTFS에서 사용되지 않음
0x28	8 바이트	0x00000000007FF54A		총 섹터 수	섹터 단위의 파티션 크기.
0x30	8 바이트	0x0000000000000004		$MFT 클러스터 번호	마스터 파일 테이블을 포함하는 클러스터
0x38	8 바이트	0x000000000007FF54		$MFTMirr 클러스터 번호	마스터 파일 테이블의 백업을 포함하는 클러스터
0x40	1 바이트	0xF6		파일 레코드 세그먼트당 바이트 또는 클러스터 수	양수 값은 파일 레코드 세그먼트의 클러스터 수를 나타낸다. 음수 값은 파일 레코드 세그먼트의 바이트 양을 나타내며, 이 경우 크기는 절대값의 2의 거듭제곱이다. (0xF6 = -10 → 210 = 1024).
0x41	3 바이트	0x000000		사용되지 않음	이 필드는 NTFS에서 사용되지 않는다.
0x44	1 바이트	0x01		인덱스 버퍼당 바이트 또는 클러스터 수	양수 값은 인덱스 버퍼의 클러스터 수를 나타낸다. 음수 값은 바이트 양을 나타내며 "파일 레코드 세그먼트당 바이트 또는 클러스터 수"와 동일한 음수 알고리즘을 사용한다.
0x45	3 바이트	0x000000		사용되지 않음	이 필드는 NTFS에서 사용되지 않는다.
0x48	8 바이트	0x1C741BC9741BA514		볼륨 일련 번호	정리를 위해 이 파티션에 할당된 고유한 난수.
0x50	4 바이트	0x00000000		체크섬, 사용되지 않음	체크섬으로 추정됨.
0x54	426 바이트		부트스트랩 코드		운영체제의 나머지를 로드하는 코드. 이 섹터의 처음 3바이트가 이를 가리킨다.
0x01FE	2 바이트	0xAA55	섹터 종료 마커		이 플래그는 유효한 부트 섹터임을 나타낸다.

이 부트 파티션 형식은 대략 이전의 FAT 파일 시스템을 기반으로 하지만 필드가 다른 위치에 있다. 이러한 필드 중 일부, 특히 "트랙당 섹터 수", "헤드 수" 및 "숨겨진 섹터" 필드는 의미가 없거나 결정할 수 없는 드라이브에서 더미 값을 포함할 수 있다.

OS는 먼저 0x30의 8바이트를 살펴서 $MFT의 클러스터 번호를 찾은 다음, 그 번호에 클러스터당 섹터 수(0x0D에서 찾은 1바이트)를 곱한다. 이 값은 아래에 설명된 $MFT까지의 섹터 오프셋(LBA)이다.

마스터 파일 테이블

NTFS에서 모든 파일, 디렉토리 및 메타파일 데이터(파일 이름, 생성 날짜, 액세스 권한(접근 제어 목록 사용을 통해) 및 크기)는 마스터 파일 테이블(MFT)에 메타데이터로 저장된다. 이러한 추상적인 접근 방식은 윈도우 NT 개발 중에 파일 시스템 기능을 쉽게 추가할 수 있게 해주었으며, 그 예로 액티브 디렉터리 및 윈도우 검색에서 사용하는 인덱싱 필드 추가가 있다. 이를 통해 빠른 파일 검색 소프트웨어가 다른 인덱스 없이도 MFT에 포함된 명명된 로컬 파일 및 폴더를 매우 빠르게 찾을 수 있다.

MFT 구조는 디스크 단편화를 최소화하는 알고리즘을 지원한다. 디렉토리 항목은 파일 이름과 마스터 파일 테이블에서 파일을 나타내는 레코드 번호인 "파일 ID"(아이노드 번호와 유사)로 구성된다. 파일 ID에는 오래된 참조를 탐지하기 위한 재사용 횟수도 포함되어 있다. 이것은 Files-11의 W_FID와 매우 유사하지만 다른 NTFS 구조는 근본적으로 다르다.

손상될 경우를 대비해 사용하기 위해 MFT 미러라고 불리는 MFT의 부분 복사본이 저장된다. MFT의 첫 번째 레코드가 손상되면 NTFS는 두 번째 레코드를 읽어 MFT 미러 파일을 찾는다. 두 파일의 위치는 부트 섹터에 저장된다.

메타파일

NTFS에는 파일 시스템을 정의하고 구성하는 여러 파일이 포함되어 있다. 모든 면에서 이러한 파일의 대부분은 다른 사용자 파일과 같이 구조화되어 있지만($Volume이 가장 독특함), 파일 시스템 클라이언트에게 직접적인 관심 대상은 아니다. 이러한 메타파일은 파일을 정의하고, 중요한 파일 시스템 데이터를 백업하며, 파일 시스템 변경 사항을 버퍼링하고, 여유 공간 할당을 관리하며, 바이오스 기대치를 충족하고, 불량 할당 단위를 추적하며, 보안 및 디스크 공간 사용 정보를 저장한다. 별도로 명시되지 않는 한 모든 콘텐츠는 이름 없는 데이터 스트림에 있다.

MFT (항목 0–26은 NTFS 메타파일임)

세그먼트 번호	파일 이름	목적
0	$MFT	파일 이름, 타임스탬프, 스트림 이름 및 데이터 스트림이 있는 클러스터 번호 목록, 인덱스, 보안 식별자 및 "읽기 전용", "압축됨", "암호화됨" 등과 같은 파일 속성을 포함하여 볼륨의 모든 파일을 설명한다.
1	$MFTMirr	$MFT의 첫 번째 핵심 항목의 복제본으로, 일반적으로 4개 항목(4 킬로바이트)이다.
2	$LogFile	파일 시스템 메타데이터 변경 사항의 트랜잭션 로그를 포함한다.
3	$Volume	볼륨 개체 식별자, 볼륨 레이블, 파일 시스템 버전 및 볼륨 플래그(마운트됨, chkdsk 요청됨, $LogFile 크기 조정 요청됨, NT 4에 마운트됨, 볼륨 일련 번호 업데이트 중, 구조 업그레이드 요청)와 같은 볼륨에 대한 정보를 포함한다. 이 데이터는 데이터 스트림에 저장되지 않고 특수 MFT 속성에 저장된다. 볼륨 개체 ID가 있는 경우 $OBJECT_ID 레코드에 저장되고, 볼륨 레이블은 $VOLUME_NAME 레코드에 저장되며 나머지 볼륨 데이터는 $VOLUME_INFORMATION 레코드에 저장된다. 참고: 볼륨 일련 번호는 $Boot 파일(아래)에 저장된다.
4	$AttrDef	숫자 식별자를 이름과 연결하는 MFT 속성 테이블이다.
5	.	루트 디렉토리. 디렉토리 데이터는 $I30이라는 이름의 $INDEX_ROOT 및 $INDEX_ALLOCATION 속성에 저장된다.
6	$Bitmap	비트 항목 배열. 각 비트는 해당 클러스터가 사용(할당) 중인지 또는 비어 있는지(할당 가능)를 나타낸다.
7	$Boot	볼륨 부트 레코드(VBR). 이 파일은 항상 볼륨의 첫 번째 클러스터에 위치한다. 부트스트랩 코드(참조: NTLDR/BOOTMGR)와 볼륨 일련 번호 및 $MFT와 $MFTMirr의 클러스터 번호를 포함하는 BIOS 매개변수 블록을 포함한다.
8	$BadClus	불량 섹터가 있는 것으로 표시된 모든 클러스터를 포함하는 파일이다. 이 파일은 새로 발견된 불량 섹터를 보관하는 장소와 참조되지 않은 클러스터를 식별하는 장소로 사용하여 chkdsk 유틸리티의 클러스터 관리를 단순화한다. 이 파일은 불량 섹터가 없는 볼륨에서도 두 개의 데이터 스트림을 포함한다. 이름 없는 스트림은 불량 섹터를 포함하며 결함이 없는 볼륨의 경우 길이가 0이다. $Bad라는 이름의 두 번째 스트림은 첫 번째 스트림에 없는 볼륨의 모든 클러스터를 포함한다.
9	$Secure	각 파일과 함께 저장된 동일한 ACL이 많을 때의 오버헤드를 줄여주는 접근 제어 목록 데이터베이스로, 이러한 ACL을 이 데이터베이스에 고유하게 한 번만 저장한다(실제 ACL 테이블을 포함하는 $SDS라는 이름의 스트림을 인덱싱하는 두 개의 인덱스인 $SII(Standard_Information ID) 및 $SDH(보안 서술자 해시)를 포함함).
10	$UpCase	Win32 및 DOS 네임스페이스에서 대소문자 구분을 방지하기 위한 유니코드 대문자 테이블이다.
11	$Extend	$Quota, $ObjId, $Reparse 또는 $UsnJrnl과 같은 다양한 선택적 확장 기능을 포함하는 파일 시스템 디렉토리이다.
12–23	$MFT 확장 항목을 위해 예약됨. 확장 항목은 기본 레코드에 들어가지 않는 추가 속성을 포함하는 추가 MFT 레코드이다. 이는 파일이 충분히 단편화되었거나, 스트림이 많거나, 파일 이름이 길거나, 보안이 복잡하거나, 기타 드문 상황에서 발생할 수 있다.
24	$Extend\$Quota	디스크 할당량 정보를 보유한다. $O 및 $Q라는 이름의 두 가지 인덱스 루트를 포함한다.
25	$Extend\$ObjId	링크 추적 정보를 보유한다. $O라는 이름의 인덱스 루트 및 할당을 포함한다.
26	$Extend\$Reparse	재분석 지점 데이터(심볼릭 링크 등)를 보유한다. $R라는 이름의 인덱스 루트 및 할당을 포함한다.
27–	일반 파일 항목의 시작.

이 메타파일들은 윈도우에서 특별히 취급되며 NTFS.SYS 드라이버에 의해 직접 처리되고 직접 보기가 어렵다. 특수하게 제작된 도구가 필요하다. 윈도우 7부터 NTFS 드라이버는 사용자 액세스를 완전히 차단하여 메타데이터 파일을 실행하려고 시도할 때마다 BSoD가 발생한다. 이러한 도구 중 하나는 마이크로소프트 "OEM Support Tools"의 일부로 무료로 배포되는 nfi.exe("NTFS File Sector Information Utility")이다. 예를 들어 "$MFT"-Master File Table 세그먼트에 대한 정보를 얻으려면 다음 명령을 사용한다: nfi.exe c:\$MFT 제한을 우회하는 또 다른 방법은 7-Zip의 파일 관리자를 사용하여 저수준 NTFS 경로 \\.\X:\(여기서 X:\는 드라이브/파티션)로 이동하는 것이다. 여기에는 $EXTEND, [DELETED](7-Zip이 보기를 위해 파일 시스템에서 삭제된 파일을 첨부하는 데 사용하는 가상 폴더), [SYSTEM](모든 NTFS 메타데이터 파일을 포함하는 또 다른 가상 폴더)의 3개 새 폴더가 나타난다. 이 트릭은 윈도우 내부의 이동식 장치(USB 플래시 드라이브, 외부 하드 드라이브, SD 카드 등)에서 사용할 수 있지만 활성 파티션에서 이 작업을 수행하려면 오프라인 액세스(즉, WinRE)가 필요하다.

속성 목록, 속성 및 스트림

MFT 레코드에 설명된 각 파일(또는 디렉토리)에 대해, 하나 이상의 MFT 레코드(소위 속성 목록 포함)에 함께 묶인 스트림 서술자(속성이라고도 함)의 선형 저장소가 있으며, 모든 MFT 레코드의 고정된 1 KB 크기를 채우기 위한 추가 패딩이 있고, 해당 파일과 연관된 유효한 스트림을 완전히 설명한다.

각 속성에는 속성 유형(파일 $AttrDef의 속성 정의에 매핑되는 고정 크기 정수), 선택적 속성 이름(예: 대체 데이터 스트림의 이름으로 사용됨) 및 바이트 시퀀스로 표현되는 값이 있다. NTFS의 경우 파일의 표준 데이터, 대체 데이터 스트림 또는 디렉토리의 인덱스 데이터가 속성으로 저장된다.

$AttrDef에 따르면 일부 속성은 상주 또는 비상주가 될 수 있다. 파일 데이터를 포함하는 $DATA 속성이 그러한 예이다. 속성이 상주(플래그로 표시됨)인 경우 그 값은 MFT 레코드에 직접 저장된다. 그렇지 않으면 데이터에 대해 클러스터가 할당되고, 데이터 실행 형식의 클러스터 위치 정보가 속성에 저장된다.

• MFT의 각 파일에 대해 속성 유형, 속성 이름으로 식별되는 속성은 고유해야 한다. 또한 NTFS에는 이러한 속성에 대한 몇 가지 순서 제약 조건이 있다.
• 하나의 MFT 레코드에서 속성 목록의 끝을 나타내는 데 사용되는 미리 정의된 널 속성 유형이 있다. 이는 레코드의 마지막 속성으로 존재해야 한다(그 뒤에 사용 가능한 모든 다른 저장 공간은 무시되며 단지 MFT의 레코드 크기와 일치시키기 위한 패딩 바이트로 구성됨).
• 일부 속성 유형은 필수이며 사용되지 않는 레코드(널 속성 유형으로만 표시됨)를 제외한 각 MFT 레코드에 존재해야 한다.
  • 이는 고정 크기 레코드로 저장되고 타임스탬프 및 기타 기본 단일 비트 속성(DOS 또는 윈도우 9x에서 FAT에 의해 관리되는 것과 호환됨)을 포함하는 $STANDARD_INFORMATION 속성의 경우이다.
• 일부 속성 유형은 이름을 가질 수 없으며 익명으로 유지되어야 한다.
  • 이는 표준 속성이나 NTFS에서 선호하는 "파일 이름" 속성 유형 또는 "짧은 파일 이름" 속성 유형(DOS와 같은 애플리케이션과의 호환성을 위해, 아래 참조)이 있는 경우이다. 파일이 짧은 파일 이름만 포함하는 것도 가능하며, 이 경우 파일 탐색기에 나열된 대로 선호되는 이름이 된다.
  • 속성 목록에 저장된 파일 이름 속성은 파일을 계층적 파일 시스템을 통해 즉시 액세스할 수 있게 만들지는 않는다. 실제로 모든 파일 이름은 동일한 볼륨의 하나 이상의 다른 디렉토리에 별도로 인덱싱되어야 한다. 거기에는 자체 MFT 레코드와 이 파일의 MFT 레코드 번호를 참조하는 자체 보안 서술자 및 속성이 있어야 한다. 이를 통해 동일한 파일 또는 디렉토리를 동일한 볼륨의 여러 컨테이너에서 서로 다른 파일 이름으로 여러 번 "하드 링크"할 수 있다.
• 일반 파일의 기본 데이터 스트림은 유형이 $DATA이지만 이름이 익명인 스트림이며, ADS도 유사하지만 이름이 지정되어야 한다.
• 반면에 디렉토리의 기본 데이터 스트림은 별개의 유형을 갖지만 익명은 아니다. 인덱싱 형식을 반영하는 속성 이름(NTFS 3+에서는 "$I30")을 갖는다.

주어진 파일의 모든 속성은 마이크로소프트 "OEM Support Tools"의 일부로 무료 배포되는 nfi.exe("NTFS File Sector Information Utility")를 사용하여 표시될 수 있다.

윈도우 시스템 호출은 대체 데이터 스트림을 처리할 수 있다. 운영체제, 유틸리티 및 원격 파일 시스템에 따라 파일 전송 중에 데이터 스트림이 자동으로 제거될 수 있다. 파일을 복사하거나 이동하는 안전한 방법은 BackupRead 및 BackupWrite 시스템 호출을 사용하는 것이다. 이 호출을 통해 프로그램은 스트림을 열거하고 각 스트림을 대상 볼륨에 기록해야 하는지 확인하고 원치 않는 스트림을 의도적으로 건너뛸 수 있다.

상주 속성 vs. 비상주 속성

매우 작은 관련 값을 가진 속성의 매우 일반적인 경우에 대해 저장 공간을 최적화하고 I/O 오버헤드를 줄이기 위해, NTFS는 속성 값의 크기가 MFT 레코드의 최대 크기를 초과하지 않는 한 속성 자체 내에 값을 배치하는 것을 선호한다. 대신 MFT 레코드 공간을 사용하여 데이터가 포함된 클러스터를 나열한다. 이 경우 속성은 데이터를 직접 저장하지 않고 볼륨의 다른 곳에 저장된 실제 데이터를 가리키는 할당 맵(데이터 실행 형식)만 저장한다. 속성 내에서 직접 값에 액세스할 수 있는 경우 이를 "상주 데이터"(컴퓨터 포렌식 작업자들에 의해)라고 한다. 들어맞는 데이터의 양은 파일의 특성에 크게 좌우되지만, 긴 파일 이름과 ACL이 없는 단일 스트림 파일의 경우 700~800바이트가 일반적이다.

• 일부 속성(예: 선호하는 파일 이름, 기본 파일 속성)은 비상주로 만들 수 없다. 비상주 속성의 경우 할당 맵이 MFT 레코드 내에 들어맞아야 한다.
• NTFS에 의해 암호화된 스트림, 스파스 데이터 스트림 또는 압축된 데이터 스트림은 상주할 수 없다.
• 비상주 속성의 할당 맵 형식은 스파스 데이터 저장 지원 능력에 따라 달라진다. 현재 NTFS 구현에서 비상주 데이터 스트림이 스파스로 표시되고 변환되면 다시 비스파스 데이터로 변경될 수 없으므로, 해당 데이터가 완전히 잘려 할당 맵을 완전히 버리지 않는 한 다시 상주할 수 없다.
• 비상주 속성이 너무 단편화되어 유효한 할당 맵이 하나의 MFT 레코드 내에 완전히 들어맞지 않는 경우 NTFS는 해당 속성을 여러 레코드에 저장한다. 그중 첫 번째 레코드를 기본 레코드라고 하고 다른 레코드를 확장 레코드라고 한다. NTFS는 긴 속성의 다른 부분을 MFT 레코드에 매핑하는 정보를 저장하기 위해 특수 속성 $ATTRIBUTE_LIST를 생성한다. 이는 할당 맵이 여러 레코드로 분할될 수 있음을 의미한다. $ATTRIBUTE_LIST 자체도 비상주일 수 있지만 자체 할당 맵은 하나의 MFT 레코드 내에 들어맞아야 한다.
• 파일에 속성이 너무 많아(ADS, 확장 속성 또는 보안 서술자 포함) MFT 레코드 내에 모두 들어맞지 않는 경우, 기본 MFT 레코드에서 사용되는 것과 동일한 형식을 사용하지만 단일 MFT 레코드의 공간 제약 없이 다른 속성을 저장하기 위해 확장 레코드를 사용할 수도 있다.

할당 맵은 압축된 인코딩이 있는 데이터 실행 형식으로 저장된다. 각 데이터 실행은 속성 값을 저장하는 인접한 클러스터 그룹을 나타낸다. 수 GB 볼륨의 파일의 경우 각 항목을 5~7바이트로 인코딩할 수 있으며, 이는 1 KB MFT 레코드가 약 100개의 이러한 데이터 실행을 저장할 수 있음을 의미한다. 그러나 $ATTRIBUTE_LIST에도 크기 제한이 있기 때문에 NTFS 볼륨에서 단일 파일의 조각이 100만 개를 넘는 것은 위험하며, 이는 일반적으로 10 GB보다 큰 파일에는 NTFS 압축을 사용하지 않는 것이 좋음을 의미한다.

NTFS 파일 시스템 드라이버는 때때로 우선순위 및 선호하는 순서 규칙과 크기 제약에 따라 비상주로 만들 수 있는 일부 속성의 데이터를 클러스터로 재배치하려고 시도하며, 클러스터에 저장된 데이터를 MFT 레코드 내부의 속성으로 다시 재배치하려고 시도한다.

상주 파일은 클러스터("할당 단위")를 직접 점유하지 않기 때문에 NTFS 볼륨에 클러스터 수보다 더 많은 파일을 포함하는 것이 가능하다. 예를 들어 74.5 GB 파티션을 NTFS로 포맷하면 4 KB의 클러스터 19,543,064개가 생긴다. 시스템 파일(64 MB 로그 파일, 2,442,888바이트 비트맵 파일 및 약 25클러스터의 고정 오버헤드)을 빼면 파일 및 인덱스를 위해 19,526,158개 클러스터가 남는다. 클러스터당 4개의 MFT 레코드가 있으므로 이 볼륨은 이론적으로 거의 4 × 19,526,158 = 78,104,632개의 상주 파일을 보관할 수 있다.

기회적 잠금

기회적 파일 잠금(oplock)은 클라이언트가 성능을 높이고 네트워크 사용을 줄이기 위해 특정 파일이나 스트림에 대한 버퍼링 전략을 변경할 수 있게 한다. Oplock은 파일의 열려 있는 지정된 스트림에 적용되며 다른 스트림의 oplock에는 영향을 미치지 않는다.

Oplock은 백그라운드에서 파일에 투명하게 액세스하는 데 사용될 수 있다. 네트워크 클라이언트는 다른 프로세스가 데이터에 액세스하지 않는 경우 원격 서버의 파일에 정보를 기록하는 것을 피할 수 있으며, 다른 프로세스가 데이터를 기록하지 않는 경우 미리 읽기 데이터를 버퍼링할 수 있다.

윈도우는 네 가지 유형의 oplock을 지원한다.

• 레벨 2(또는 공유) oplock: 다중 읽기 가능, 쓰기 불가(즉, 읽기 캐싱).
• 레벨 1(또는 독점) oplock: 임의의 버퍼링을 사용한 독점 액세스(즉, 읽기 및 쓰기 캐싱).
• 배치 oplock(역시 독점): 스트림이 서버에서 열려 있지만 클라이언트 머신에서 닫힌 상태(즉, 읽기, 쓰기 및 핸들 캐싱).
• 필터 oplock(역시 독점): 다른 사용자가 동일한 스트림에 액세스하려고 할 때 애플리케이션 및 파일 시스템 필터가 "물러날" 수 있음(즉, 읽기 및 쓰기 캐싱)(윈도우 2000부터).

윈도우 7 및 윈도우 서버 2008 R2에서 클라이언트당 oplock 키를 사용하여 기회적 잠금이 강화되었다.

시간

윈도우 NT 및 그 후손들은 내부 타임스탬프를 UTC로 유지하고 표시 목적을 위해 적절한 변환을 수행한다. 모든 NTFS 타임스탬프는 UTC 기준이다.

역사적인 이유로 NTFS를 지원하지 않는 윈도우 버전은 모두 내부적으로 시간을 로컬 시간대로 유지하므로 FAT 파일 시스템도 마찬가지이다. 즉, NTFS와 FAT 파티션 간에 파일을 복사하거나 이동할 때 OS가 즉석에서 타임스탬프를 변환해야 한다. 그러나 일부 파일이 일광 절약 시간제(DST)가 적용될 때 이동되고 다른 파일이 표준시가 적용될 때 이동되면 변환에 모호함이 발생할 수 있다. 그 결과, 특히 로컬 시간대가 변경되는 날 직후에 사용자는 일부 파일의 타임스탬프가 1시간 정도 틀린 것을 관찰할 수 있다. 서로 다른 관할권에서의 DST 구현 차이로 인해 임의의 12개월 동안 최대 4시간의 잠재적인 타임스탬프 오류가 발생할 수 있다.

이 문제는 로컬 시간대가 가끔 변경되는 모든 컴퓨터(예: 노트북 및 기타 휴대용 장치에서 흔히 발생하는 것처럼 컴퓨터를 한 시간대에서 다른 시간대로 이동하는 경우)에서 더욱 악화된다.

같이 보기

• 파일 시스템 비교
• NTFSDOS
• ntfsresize
• WinFS
• ReFS, 최신 마이크로소프트 파일 시스템

참고 자료

• Bolosky, William J.; Corbin, Scott; Goebel, David; Douceur, John R. (January 2000). “Single Instance Storage in Windows 2000”. 《Proceedings of 4th USENIX Windows Systems Symposium》. 
• Custer, Helen (1994). 《Inside the Windows NT File System》. 마이크로소프트 프레스. ISBN 978-1-55615-660-1. 
• Nagar, Rajeev (1997). 《Windows NT File System Internals: A Developer's Guide》. O'Reilly. ISBN 978-1-56592-249-5. 
• “NTFS Technical Reference”. 《마이크로소프트 런》. 마이크로소프트. 2009년 10월 8일. 

외부 링크

• NTFS3
• NTFS3 소스 코드