🌸🌸🌸내가 좋아하는 window의 파일 시스템은 어떻게 되어있는지 알아보자.
window의 file system
https://learn.microsoft.com/ko-kr/windows-hardware/drivers/ifs/#file-systems
Windows 파일 시스템은 스토리지 시스템 위에서 작동하는 파일 시스템 드라이버로 구현됩니다. Windows 사용할 수 있는 표준 파일 시스템에는 NTFS, ExFAT, UDF 및 FAT32가 포함됩니다. Windows Server 2012 이상 버전에서 사용할 수 있는 ReFS(복원 파일 시스템)는 확장 가능한 대용량 지원과 디스크에서 데이터 손상을 감지하고 수정하는 기능을 제공합니다.
window의 파일 시스템 기능 비교
https://learn.microsoft.com/ko-kr/windows/win32/fileio/filesystem-functionality-comparison
file system별 기능
| Feature | NTFS | exFAT | UDF | FAT32 |
|---|---|---|---|---|
| Creation time stamps | Yes | Yes | Yes | Yes |
| Last access time stamps | No (see note below) | Yes | Yes | Yes (date only) |
| Last change time stamps | Yes | Yes | Yes | Yes |
| Last archive time stamps | No | No | No | No |
| Case-sensitive | Yes (option) | No | Yes | No |
| Case-preserving | Yes | Yes | Yes | Yes |
| Hard links | Yes | No | Yes | No |
| Soft links | Yes | No | No | No |
| Sparse files | Yes | No | Yes | No |
| Named streams | Yes | No | Yes | No |
| Oplocks | Yes | Yes | Yes | Yes |
| Extended attributes | Yes | No | Yes (on-disk only) | No |
| Alternate data streams | Yes | No | Yes | No |
| Mount points | Yes | No | No | No |
Windows Server 2003 및 Windows XP: NTFS 마지막 액세스 타임스탬프 필드가 업데이트됩니다.
window상의 용어 설명
jk피셜: 표를 보는데 생소한 용어들이 많다. 좀더 설명을 찾아보자.
https://learn.microsoft.com/ko-kr/windows/win32/fileio/files-and-clusters
Sparse file
스파스 파일(Sparse file)은 실제로는 데이터가 존재하지 않는 공간을 가진 파일입니다. 즉, 파일의 크기가 크더라도 실제로 데이터로 채워져 있는 부분만을 저장하고, 나머지 빈 공간은 저장하지 않습니다. 이를 통해 디스크 공간을 절약할 수 있습니다.
NTFS 파일 시스템의 파일 압축은 디스크 공간을 비효율적으로 사용하는 문제의 일부 해결책입니다. 명시적으로 작성되지 않은 파일의 모든 데이터는 명시적으로 0으로 설정됩니다. 파일 압축은 이러한 범위를 0으로 압축합니다. 그러나 파일 압축의 단점은 데이터 압축 및 압축 해제로 인해 액세스 시간이 증가할 수 있다는 것입니다.
스파스 파일에 대한 지원은 디스크 공간 사용 효율성을 높이는 또 다른 방법으로 NTFS 파일 시스템에 도입되었습니다. 스파스 파일 기능을 사용하도록 설정하면 시스템에서 0이 아닌 데이터가 포함된 지역을 제외하고 파일에 하드 디스크 드라이브 공간을 할당하지 않습니다. 버퍼에 있는 많은 양의 데이터가 0인 쓰기 작업을 시도하면 0이 파일에 기록되지 않습니다. 대신 파일 시스템은 파일에서 0의 위치를 포함하는 내부 목록을 만들고 모든 읽기 작업 중에 이 목록을 참조합니다. 0이 있는 파일 영역에서 읽기 작업을 수행하면 파일 시스템은 읽기 작업에 할당된 버퍼에서 적절한 수의 0을 반환합니다. 이러한 방식으로 스파스 파일의 유지 관리는 액세스하는 모든 프로세스에 투명하며 이 특정 시나리오의 압축보다 더 효율적입니다.
스파스 파일의 기본 데이터 값은 0입니다. 그러나 다른 값으로 설정할 수 있습니다.
파일 스트림(로컬 파일 시스템)
스트림은 일련의 바이트(sequence of bytes)입니다. NTFS 파일 시스템에서 스트림은 파일에 기록된 데이터를 포함하며, 속성과 속성보다 더 많은 파일에 대한 정보를 제공합니다. 예를 들어, 검색 키워드나 파일을 생성한 사용자 계정과 같은 추가적인 데이터를 포함하는 스트림을 생성할 수 있습니다.
스트림 형식
다음은 특성 형식 코드라고도 하는 NTFS 스트림 형식의 목록입니다. 일부 스트림 형식은 NTFS 내부이며 해당 형식은 문서화되지 않았습니다.
JK추가 설명
NTFS 파일 시스템은 메타데이터를 관리하기 위해 스트림(stream)이라는 개념을 사용합니다. 스트림은 파일에 연결된 추가적인 데이터를 저장하는 데 사용됩니다. 각 파일은 기본 데이터 스트림과 선택적으로 여러 개의 보조 데이터 스트림을 가질 수 있습니다.
기본 데이터 스트림은 파일의 주요 내용을 저장하는 데 사용됩니다. 보조 데이터 스트림은 파일과 관련된 추가 정보를 저장하는 데 사용될 수 있습니다. 이러한 추가 정보는 보안 설명서, 색인 정보, 암호화 키 등을 포함할 수 있습니다.
일반적으로 파일 탐색기와 같은 일부 응용 프로그램은 기본 데이터 스트림만 보여주고, 보조 데이터 스트림은 숨겨진 형태로 파일에 연결됩니다. 이를 통해 파일의 메타데이터를 보호하고 관리할 수 있습니다.
스트림을 사용하여 NTFS 파일 시스템은 파일과 관련된 다양한 속성과 정보를 효과적으로 저장하고 관리할 수 있습니다.
파일 및 클러스터
파일은 사용자가 액세스하고 관리할 수 있는 파일 시스템의 데이터 단위입니다. 파일의 디렉터리에 고유한 이름이 있어야 합니다. 관련 데이터 집합을 포함하는 하나 이상의 바이트 스트림과 파일 또는 파일 내의 데이터를 설명하는 특성 집합(속성이라고도 함)으로 구성됩니다. 파일 생성 시간은 파일 특성의 예입니다.
파일을 만들면 파일이 열려 있는 동안 파일에 기록된 모든 데이터를 저장하기 위해 명명되지 않은 기본 스트림 하나가 만들어집니다. 파일 내에서 추가 스트림을 만들 수도 있습니다. 이러한 추가 스트림을 대체 스트림이라고 합니다. 다음 그림에서는 기본 스트림과 두 개의 대체 스트림이 있는 파일을 보여 줍니다.
파일 특성은 파일 데이터와 함께 데이터 스트림에 저장되지 않지만 다른 곳에 저장되고 운영 체제에서 관리됩니다.
시스템 부트스트랩 코드 및 디렉터리를 포함한 모든 파일 시스템 데이터는 NTFS 파일 시스템에 의해 파일에 저장됩니다. 다른 파일 시스템은 이 정보를 파일 시스템 외부의 디스크 지역에 저장합니다. 이 정보를 파일에 저장하는 장점은 Windows 정보를 쉽게 찾고, 액세스하고, 유지 관리할 수 있다는 것입니다. 다른 장점은 이러한 각 파일이 보안 설명자에 의해 보호될 수 있으며 부분 디스크 손상의 경우 디스크의 안전한 부분으로 신속하게 재배치될 수 있다는 것입니다.
지원되는 모든 파일 시스템의 기본 스토리지 단위는 섹터 그룹인 클러스터입니다. 이렇게 하면 파일 시스템에서 하드웨어 디스크 컨트롤러에서 설정한 디스크 섹터 크기와 독립적으로 디스크 데이터 관리를 최적화할 수 있습니다. 관리할 디스크가 크고 많은 양의 데이터를 단일 작업으로 이동하고 구성하는 경우 관리자는 이를 수용하도록 클러스터 크기를 조정할 수 있습니다.
파일 핸들
CreateFile 함수를 사용하는 프로세스에서 파일을 열면 프로세스가 종료되거나 CloseHandle 함수를 사용하여 핸들을 닫을 때까지 파일 핸들이 연결됩니다. 파일 핸들은 여러 함수 호출에서 파일을 식별하는 데 사용됩니다.
각 파일 핸들 및 파일 개체는 일반적으로 파일을 여는 각 프로세스에 고유합니다. 유일한 예외는 프로세스에서 보유하는 파일 핸들이 중복되거나 자식 프로세스가 부모 프로세스의 파일 핸들을 상속하는 경우입니다. 이러한 경우 이러한 파일 핸들은 고유하지만 공유된 단일 파일 개체를 볼 수 있습니다. 프로세스에서 보유한 중복 파일 핸들에 대한 자세한 내용은 DuplicateHandle 을 참조하세요.
파일 핸들은 일반적으로 프로세스에 비공개이지만 파일 핸들이 가리키는 파일 데이터는 그렇지 않습니다. 따라서 동일한 파일을 공유하는 프로세스 및 스레드는 액세스를 동기화해야 합니다. 파일에 대한 대부분의 작업의 경우 프로세스는 프라이빗 핸들 풀을 통해 파일을 식별합니다.
JK추가 설명
파일 핸들(File handle)은 운영 체제에서 파일에 대한 참조를 나타내는 개념입니다. 파일 핸들은 파일을 식별하고 접근하기 위해 사용됩니다. 일반적으로 파일 핸들은 파일을 열 때 운영 체제로부터 할당받고, 파일 작업을 수행하는 동안 유지됩니다.
파일 핸들은 파일을 열고 닫는 데 사용되며, 파일에 대한 읽기, 쓰기, 이동 등의 작업을 수행할 때 필요합니다. 파일 핸들은 파일 시스템 내부에서 파일을 식별하고 해당 파일에 대한 작업을 수행하는 데 사용되는 고유한 식별자입니다.
파일 핸들은 일반적으로 정수나 포인터 형태로 표현됩니다. 각 운영 체제마다 파일 핸들을 나타내는 특정 데이터 형식이 있을 수 있습니다. 파일 핸들은 파일 시스템 및 운영 체제 API를 사용하여 파일을 조작하는 데 사용됩니다.
파일 핸들은 여러 프로세스 또는 스레드에서 동시에 사용될 수 있으며, 운영 체제는 각각의 파일 핸들을 관리하고 파일 작업을 적절하게 조정합니다. 파일 핸들을 올바르게 사용하면 여러 개의 파일을 동시에 열고 조작할 수 있으며, 파일에 대한 접근과 관련된 작업을 효율적으로 수행할 수 있습니다.
->JK피셜: 오, proxy lab할 때 socket descriptor랑 완전 똑같다! 통신이라는 것도 어차피 데이터를 입력 받아서 file형식으로 메모리에 저장하는 방식이라 똑같은가보다.
파일 포인터
파일이 열리면 Windows 파일 포인터를 기본 스트림과 연결합니다. 이 파일 포인터는 읽을 다음 바이트 또는 쓴 다음 바이트를 받을 위치를 지정하는 64비트 오프셋 값입니다. 파일을 열 때마다 시스템에서 파일 포인터를 파일의 시작 부분에 배치합니다(오프셋 0). 각 읽기 및 쓰기 작업은 읽고 쓰는 바이트 수만큼 파일 포인터를 앞으로 이동합니다. 예를 들어 파일 포인터가 파일의 시작 부분에 있고 5바이트의 읽기 작업을 요청하는 경우 파일 포인터는 읽기 작업 직후 오프셋 5에 배치됩니다. 각 바이트가 읽거나 쓰면 시스템에서 파일 포인터를 앞으로 이동합니다. SetFilePointer 함수를 호출하여 파일 포인터의 위치를 변경할 수도 있습니다.
파일 포인터가 파일의 끝에 도달하고 애플리케이션이 파일에서 읽으려고 하면 오류가 발생하지 않지만 바이트를 읽지 않습니다. 따라서 오류 없이 0바이트를 읽는 것은 애플리케이션이 파일의 끝에 도달했음을 의미합니다. 0바이트 쓰기는 아무런 작업을 수행하지 않습니다.
애플리케이션은 SetEndOfFile 함수를 사용하여 파일을 자르거나 확장할 수 있습니다. 이 함수는 파일의 끝을 파일 포인터의 현재 위치로 설정합니다.
클러스터 및 익스텐트
클러스터는 파일 내부와 볼륨에서 두 가지 관점에서 참조될 수 있습니다. 파일 내의 모든 클러스터는 가상 클러스터 번호 (VCN)를 가지며, 이는 파일의 시작부터의 상대적인 오프셋입니다. 예를 들어, 클러스터 크기의 두 배로 seek한 다음 읽기를 수행하면 세 번째 VCN에서 데이터를 반환합니다. 논리적 클러스터 번호 (LCN)는 볼륨 내에서 클러스터의 오프셋을 나타냅니다. LCN은 순서 또는 상대적인 번호로만 처리되어야 합니다. 논리적 클러스터와 물리적 하드 디스크 드라이브 섹터 간에는 보장된 매핑이 없습니다.
연속적인 클러스터의 연속적인 실행을 의미하는 extent가 있습니다. 예를 들어, 30개의 클러스터로 구성된 파일이 두 개의 extent로 기록될 수 있습니다. 첫 번째 extent는 연속된 5개의 클러스터로 구성될 수 있고, 나머지 25개의 클러스터는 다른 extent로 구성될 수 있습니다.
디스크상에서 한 extent와 다른 extent 간에 어떠한 관계도 보장되지 않습니다. 예를 들어, 첫 번째 extent가 후속 extent보다 더 높은 LCN에 있을 수 있습니다.
JK추가 설명
익스텐트(Extent)는 연속적인 클러스터의 집합을 의미합니다. 파일이 여러 클러스터를 차지하는 경우, 이 클러스터들은 하나의 익스텐트로 묶일 수 있습니다. 익스텐트는 파일 시스템에서 파일의 데이터를 표현하는 방식 중 하나입니다. 예를 들어, 파일이 30개의 클러스터로 구성되어 있고, 첫 번째 익스텐트는 연속된 5개의 클러스터를 사용하고, 두 번째 익스텐트는 나머지 25개의 클러스터를 사용할 수 있습니다. 익스텐트는 파일 시스템의 내부 구조에서 사용되는 개념으로, 사용자에게 직접적으로 노출되지 않습니다.
저널링 및 변경 로그
| 기능 | NTFS | exFAT | UDF | FAT32 |
|---|---|---|---|---|
| 메타데이터 전용 저널링 | 예 | 아니요 | 예 | 예 |
| 파일 변경 로그 | 예 | 예 | 아니요 | 예 |
JK추가 설명
저널링(Journaling)은 파일 시스템은 디스크에 데이터를 쓰거나 수정하는 작업을 수행할 때, 해당 작업에 대한 로그를 특별한 영역에 기록하는 것을 말합니다.
저널링 파일 시스템은 일반적으로 트랜잭션 기반으로 동작합니다. 파일 시스템의 작업은 트랜잭션 단위로 그룹화되며, 해당 작업은 저널이라는 로그 영역에 순차적으로 기록됩니다. 이 저널에는 작업의 내용과 위치 정보가 포함됩니다.
저널링의 주요 목적은 데이터 일관성을 보장하기 위해 사용됩니다. 예를 들어, 파일 시스템 작업 중에 시스템이 강제로 종료되는 경우, 저널에 기록된 작업을 참조하여 작업이 완전히 적용되지 않은 파일 시스템의 비일관성을 복구할 수 있습니다. 따라서 파일 시스템의 복구 시간과 신뢰성을 향상시키는 데 도움이 됩니다.변경 로그(Change Log)는 파일 시스템에서 수행된 변경 작업을 기록하는 메커니즘입니다. 변경 로그를 사용하면 파일 시스템 복구 과정에서 변경된 데이터를 신속하게 찾고 복구할 수 있습니다. 또한 변경 로그는 파일 시스템의 성능을 향상시킬 수 있으며, 일괄 처리 작업 등에서 효과적으로 활용될 수 있습니다.
보안
| 기능 | NTFS | exFAT | UDF | FAT32 |
|---|---|---|---|---|
| 파일 소유자 추적 | 예 | 예 | 예 | 예 |
| POSIX 파일 권한 | 아니요(POSIX 하위 시스템 기능에서 사용 가능) | 예 | 예 | 예 |
| 액세스 제어 목록 | Yes | 예 | 예 | 예 |
| 파일 시스템 수준 암호화 | Yes | 아니요 | 예 | 예 |
| 체크섬/ECC | No | 메타데이터 | 메타데이터 | No |
압축
| 기능 | NTFS | exFAT | UDF | FAT32 |
|---|---|---|---|---|
| 기본 제공 압축 | 예 | 아니요 | 아니요 | 예 |
할당량
| 기능 | NTFS | exFAT | UDF | FAT32 |
|---|---|---|---|---|
| 사용자 수준 디스크 공간 | 예 | 예 | 예 | 예 |
| 디렉터리 수준 디스크 공간 | 아니요(아래 참고 참조) | 예 | 예 | 예 |
참고 NTFS의 디렉터리 수준 디스크 공간 할당량 기능은 파일 서버 리소스 관리자를 통해 사용할 수 있습니다.
