맨위로가기

파일 시스템

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

파일 시스템은 컴퓨터에서 데이터를 저장하고 관리하는 방식이다. 1900년대 초 종이 문서 정리 방식에서 유래되었으며, 컴퓨터 기술 발전과 함께 디지털 파일 관리에 적용되었다. 파일 시스템은 블록 단위로 데이터를 저장하고, 파일 이름과 디렉터리를 사용하여 파일을 구성한다. 다양한 계층 구조로 구성되어 하드 디스크, CD-ROM, 플래시 메모리 등 다양한 저장 장치를 지원하며, 디스크 파일 시스템, 데이터베이스 파일 시스템, 트랜잭션 기반 파일 시스템, 특수 용도 파일 시스템 등 여러 종류가 있다. 운영 체제는 파일 시스템을 통해 사용자에게 파일 접근을 제공하며, 유닉스 계열과 윈도우를 비롯한 다양한 운영 체제가 각기 다른 파일 시스템을 사용한다.

더 읽어볼만한 페이지

  • 파일 시스템 - 부트 섹터
    부트 섹터는 시스템 부팅 코드를 담은 저장 매체의 특정 영역으로, 볼륨 부트 레코드(VBR)와 마스터 부트 레코드(MBR)로 나뉘며, BIOS는 이를 실행하고 UEFI는 부트로더를 직접 로드하지만 바이러스 공격에 취약하다.
  • 파일 시스템 - ZFS
    ZFS는 Jeff Bonwick 등이 설계하고 구현한 파일 시스템으로, 데이터 무결성, 스냅샷, RAID-Z 등의 기능을 제공하며, 썬 마이크로시스템즈에서 개발되어 OpenZFS 프로젝트를 통해 다양한 운영체제에서 사용된다.
파일 시스템
파일 시스템 개요
종류디스크 파일 시스템
플래시 파일 시스템
데이터베이스 파일 시스템
네트워크 파일 시스템
테이프 파일 시스템
공유 디스크 파일 시스템
특수 목적 파일 시스템
용도파일 시스템은 데이터를 저장하고 검색하는 방법을 제공하며, 컴퓨터 시스템의 중요한 부분임.
기능파일 구성
디렉터리 구조 제공
파일 이름 관리
접근 권한 제어
데이터 무결성 유지
저장 공간 관리
기본 속성
디렉터리 (폴더)파일들을 그룹화하는 컨테이너 역할을 함.
파일데이터의 기본 단위.
파일 이름파일 시스템 내에서 파일을 식별하는 데 사용되는 이름.
메타데이터파일 시스템에 저장된 파일에 대한 정보 (예: 크기, 생성 날짜, 수정 날짜, 권한).
파일 시스템 종류별 특징
디스크 파일 시스템하드 디스크 드라이브 (HDD) 또는 솔리드 스테이트 드라이브 (SSD)와 같은 저장 장치에 데이터를 구성하는 데 사용됨.
예: FAT32, NTFS, ext4, APFS
플래시 파일 시스템플래시 메모리 장치 (예: USB 드라이브, SD 카드)에 최적화됨.
예: exFAT, JFFS2, YAFFS
데이터베이스 파일 시스템데이터베이스 내에 파일을 저장하고 관리함.
데이터베이스 기능을 활용하여 파일 관리의 효율성을 높임.
네트워크 파일 시스템네트워크를 통해 파일에 접근할 수 있도록 함.
예: NFS, SMB/CIFS
테이프 파일 시스템자기 테이프 드라이브에 데이터를 저장하고 검색하는 데 사용됨.
주로 백업 및 아카이브에 사용됨.
공유 디스크 파일 시스템여러 컴퓨터가 동시에 동일한 디스크에 접근할 수 있도록 함.
클러스터 환경에서 사용됨.
특수 목적 파일 시스템특정 목적을 위해 설계된 파일 시스템.
예: procfs, sysfs (리눅스 커널 정보 제공)
역사
1세대 파일 시스템단순한 구조.
파일 이름 길이 제한, 계층적 디렉터리 구조 미지원.
예: CP/M의 파일 시스템
2세대 파일 시스템계층적 디렉터리 구조 도입, 긴 파일 이름 지원.
예: MS-DOS의 FAT 파일 시스템
3세대 파일 시스템성능 향상, 데이터 무결성 강화.
저널링, 접근 제어 목록 (ACL) 지원.
예: NTFS, ext3
4세대 파일 시스템대용량 저장 장치 지원, 고급 기능 제공.
copy-on-write, 스냅샷 지원.
예: ZFS, btrfs

2. 용어의 기원

컴퓨터가 등장하기 이전인 1900년경부터 '파일 시스템(file system)', '파일링 시스템(filing system)', '파일링을 위한 시스템(system for filing)' 등의 용어는 종이 문서를 정리, 저장, 검색하는 방법을 설명하는 데 사용되었다.[4] 1961년에 '파일 시스템'이라는 용어는 원래 의미와 함께 전산화된 파일링에도 적용되기 시작했으며,[5] 1964년에는 일반적인 용어로 사용되었다.[6]

3. 구조

파일 시스템은 일반적으로 512바이트, 1키비바이트, 2키비바이트 등 2의 제곱 형태의 크기를 가진 블록들의 배열(섹터)에 접근할 수 있는 자료 보관 장치 위에 생성된다. 이러한 배열들을 조직하여 파일이나 디렉터리를 만들고, 파일과 공백을 구분하기 위해 각 배열에 표시를 한다. 자료는 '클러스터' 또는 '블록'이라는 단위로 새겨지며, 이는 파일 하나에 필요한 최소 디스크 공간을 의미한다.

로컬 파일 시스템의 구조는 추상화 계층으로 설명할 수 있다.


  • '''논리적 파일 시스템''' 계층은 열기, 닫기, 읽기, 쓰기 등 파일 작업에 대한 API를 제공하여 상위 수준의 접근을 지원하고, 하위 계층에 작업을 위임한다. 이 계층은 열린 파일 테이블 항목과 프로세스별 파일 디스크립터를 관리하며, 파일 접근, 디렉터리 작업, 보안 및 보호 기능을 제공한다.[7]
  • '''가상 파일 시스템'''은 선택적인 계층으로, 여러 개의 물리적 파일 시스템의 동시 인스턴스를 지원한다.[8]
  • '''물리적 파일 시스템''' 계층은 디스크와 같은 스토리지 장치에 대한 낮은 수준의 접근을 제공한다. 이 계층은 데이터 블록을 읽고 쓰며, 버퍼링 및 메모리 관리를 수행하고, 스토리지 매체의 특정 위치에 블록 배치를 제어한다. 이 계층은 장치 드라이버 또는 채널 I/O를 사용하여 스토리지 장치를 구동한다.[7]


파일 시스템은 보조 기억 장치 상의 "섹터" 등으로 불리는 고정 크기의 "블록" 배열에 접근하며, 이 섹터군을 사용하여 파일과 디렉터리를 구성하고, 각 섹터의 사용 여부를 파악한다. 파일 시스템은 데이터 조작 및 접근을 제공하는 것이 목적이며, 기억 장치에 저장되어 있는지, 네트워크를 통해 동적으로 생성되는지는 중요하지 않다.[41]

계층형 파일 시스템은 UNIX에서 데니스 리치의 초기 연구 대상이었다. UNIX의 성공 이후, 리치는 Plan 9과 Inferno와 같은 후속 OS 개발에서도 파일 시스템 개념을 다양한 대상에 확장했다.

초기 파일 시스템은 파일 및 디렉터리의 생성, 이동, 삭제 기능을 제공했지만, 하드 링크 생성, 부모 링크 명칭 변경, 양방향 링크 생성과 같은 기능은 초기에 존재하지 않았다. 파일 내용의 일부 삭제, 파일 연결, 갱신 등은 제공했지만, 파일 선두 데이터 삽입/삭제, 임의 위치 내용 삭제/삽입 등은 제공하지 않았다.

파일 시스템의 기본 조작에 대한 안전한 접근은 접근 제어 목록 또는 케퍼빌리티를 기반으로 한다. 접근 제어 목록은 완전한 보안 확보가 어렵다는 연구 결과에 따라, 최신 OS에서는 케퍼빌리티가 사용되는 경향이 있다. 그러나 상용 파일 시스템은 여전히 접근 제어 목록을 사용한다. (컴퓨터 보안 참조)

FMR 시리즈・FM TOWNS용 워드 프로세서 소프트웨어인 「FM-OASYS」 등과 같이 독자적인 파일 시스템을 채용하는 애플리케이션 소프트웨어도 있다.

3. 1. 파일 이름

파일 이름은 애플리케이션에서 파일을 식별하고, 경우에 따라 사용자를 식별하는 데 사용된다. 파일 시스템이 디렉터리를 지원하는 경우, 일반적으로 파일 이름의 고유성은 각 디렉터리의 컨텍스트 내에서 적용된다. 즉, 저장소는 동일한 이름을 가진 여러 파일을 포함할 수 있지만, 동일한 디렉터리 내에서는 불가능하다.[41]

대부분의 파일 시스템은 파일 이름의 길이를 제한한다. 일부 파일 시스템은 파일 이름을 대소문자를 구분하여 일치시키고, 다른 파일 시스템은 대소문자를 구분하지 않고 일치시킨다. 예를 들어, 대소문자를 구분하지 않는 경우 `MYFILE`과 `myfile`이라는 이름은 동일한 파일과 일치하지만, 대소문자를 구분하는 경우에는 다른 파일과 일치한다.

대부분의 최신 파일 시스템에서는 파일 이름에 유니코드 문자 집합의 광범위한 문자를 포함할 수 있다. 그러나 장치, 장치 유형, 디렉터리 접두사, 파일 경로 구분 기호 또는 파일 유형과 같은 특수 속성을 나타내는 데 사용되는 일부 문자는 제한된다.

일반적으로 파일 이름은 FAT이나 Unix 계열 파일 시스템에서의 아이노드와 같은 파일 할당 테이블의 인덱스와 대응한다. 디렉터리 구조는 평탄할 수도 있고, 디렉터리 아래에 서브 디렉터리가 있는 계층 구조일 수도 있다. 몇몇 파일 시스템에서는 파일 이름도 구조화되어 확장자나 버전 번호의 문법이 존재한다. 그렇지 않은 경우, 파일 이름은 단순한 문자열이며, 파일마다의 메타데이터는 적절한 장소에 저장된다.[41]

3. 2. 디렉터리

파일 시스템은 일반적으로 파일을 그룹으로 분리하는 '''디렉터리'''(directory) 또는 '''폴더'''를 사용하여 파일을 구성한다.

이는 파일 이름을 목차 또는 유닉스 계열 파일 시스템의 아이노드의 인덱스와 연결하여 구현할 수 있다.

디렉터리 구조는 평면적(선형)일 수도 있고, 하위 디렉터리라고 하는 디렉터리가 디렉터리를 포함하도록 허용하여 계층 구조를 허용할 수도 있다.

임의의 디렉터리 계층 구조를 지원하는 최초의 파일 시스템은 Multics 운영 체제에서 사용되었다.[9] 유닉스 계열 시스템의 기본 파일 시스템도 임의의 디렉터리 계층 구조를 지원하며, 애플(Apple Inc.)의 계층적 파일 시스템과 클래식 Mac OS의 후속 버전인 HFS+, MS-DOS 2.0 및 이후 버전의 MS-DOS와 마이크로소프트 윈도우FAT 파일 시스템, 윈도우 NT 운영 체제 제품군의 NTFS 파일 시스템, OpenVMS의 Files-11 파일 시스템의 ODS-2(On-Disk Structure-2) 및 상위 레벨에서도 지원된다.

파일 시스템이 스토리지에 있는지 여부에 관계없이, 일반적인 파일 시스템은 파일의 파일 이름을 묶는 디렉토리를 가진다. 일반적으로 파일 이름은 MS-DOSFAT, Unix 계열 파일 시스템에서의 inode와 같이 어떤 파일 할당 테이블의 인덱스와 대응한다. 디렉터리 구조는 평탄한 경우도 있고, 디렉터리 아래에 서브 디렉터리가 있는 계층 구조일 수도 있다.

4. 파일 시스템의 종류

파일 시스템은 크게 디스크 파일 시스템, 분산 파일 시스템, 특수 용도 파일 시스템으로 나눌 수 있다.

분산 파일 시스템윈도우의 SMB/CIFS, 매킨토시의 AFP, 유닉스NFS 등이 해당하며, 네트워크를 통해 파일을 공유할 수 있도록 한다. 이러한 네트워크 파일 시스템은 공유 원본의 파일 시스템을 추상화한 또 다른 종류의 파일 시스템으로 취급된다.[41]

개별 OS가 표준으로 하는 NTFS, UFS, HFS+, ext3, HPFS, BFS 등의 차이는 Samba 등을 사용한 파일 공유에서 실용적인 문제는 거의 없지만, 파일 이름 제한이나 확장 파일 속성을 사용할 수 없는 등의 문제는 있을 수 있다. 또한, Windows나 macOS를 대상으로 한 NAS 장치에서도 내부 하드 디스크 드라이브 (HDD)에서는 ReiserFS나 XFS 등이 사용되는 경우가 많다.

유닉스와 같은 파일 중심의 운영 체제는 '/proc'와 같은 여러 가지 특수 용도의 파일 시스템을 사용하여 프로세스나 운영 체제의 여러 기능에 접근할 수 있다.[41]

4. 1. 디스크 파일 시스템

디스크 파일 시스템은 자료 기억 장치, 특히 컴퓨터에 연결된 디스크 드라이브에 파일을 저장하도록 설계된 시스템이다. 지역 파일 시스템은 어떤 저장 공간이 어떤 파일에 속하고, 어떤 공간이 사용되지 않는지 추적한다.

파일 시스템이 파일을 생성할 때, 데이터에 대한 공간을 할당한다. 일부 파일 시스템은 파일이 커짐에 따라 초기 공간 할당과 후속 증가 할당을 지정하도록 허용하거나 요구한다. 파일을 삭제하려면 파일 시스템은 해당 파일의 공간이 다른 파일에 사용할 수 있도록 비어 있음을 기록한다.

4,096-바이트 NTFS 클러스터로 시연된 슬랙 공간의 예: 100,000개의 파일, 각 파일당 5바이트, 실제 데이터는 500,000바이트이지만 저장하려면 409,600,000바이트의 디스크 공간이 필요함


지역 파일 시스템은 신뢰성과 효율성을 제공하기 위해 저장 공간을 관리한다. 일반적으로, 여러 물리적 단위(예: 바이트)로 세분화된 방식으로 저장 장치 공간을 할당한다. 세분화된 특성으로 인해 각 파일에 대해 사용되지 않는 공간, 때로는 슬랙 공간이라고 불리는 공간이 발생하며, 이는 할당 단위의 배수인 드문 크기를 가진 파일을 제외하고 발생한다.[41] 512바이트 할당의 경우, 평균 사용되지 않는 공간은 256바이트이다. 64KB 클러스터의 경우, 평균 사용되지 않는 공간은 32KB이다.

일반적으로 할당 단위 크기는 저장 공간이 구성될 때 설정된다. 저장된 파일에 비해 비교적 작은 크기를 선택하면 과도한 접근 오버헤드가 발생한다. 비교적 큰 크기를 선택하면 과도한 사용되지 않는 공간이 발생한다. 저장 공간에 있을 것으로 예상되는 파일의 평균 크기에 따라 할당 크기를 선택하면 사용할 수 없는 공간을 최소화하는 경향이 있다.

''디스크 파일 시스템''은 디스크 저장 매체가 짧은 시간 안에 데이터를 임의로 주소 지정할 수 있는 기능을 활용한다. 추가적인 고려 사항으로는 처음에 요청된 데이터에 이어 데이터를 액세스하는 속도와 후속 데이터도 요청될 수 있다는 예측이 있다. 이를 통해 여러 사용자(또는 프로세스)가 데이터의 순차적인 위치에 관계없이 디스크의 다양한 데이터에 액세스할 수 있다.

'''디스크 파일 시스템의 예시'''

일부 디스크 파일 시스템은 저널링 파일 시스템 또는 버전 관리 파일 시스템이다.

ISO 9660과 UDF는 CD, DVD, 블루레이 광 디스크를 대상으로 하는 두 가지 일반적인 형식이다. 마운트 레이니어는 리눅스 커널 2.6 시리즈부터, 그리고 Windows Vista부터 지원되는 UDF의 확장으로, DVD 재작성을 용이하게 한다.

파일 시스템명개발자등장 연도최초 지원 OS
RT-11DEC1973년RT-11
FAT12마이크로소프트1977년Microsoft Disk BASIC
ODS-2DEC1979년VMS
UFS (FFS)커크 매큐식1983년4.2BSD
HFS애플1985년Macintosh System 2.1
FAT16마이크로소프트1987년MS-DOS 3.31
HPFSIBM & 마이크로소프트1988년OS/2
JFSIBM1990년AIX
VxFSVERITAS1991년SVR4.0
NTFS마이크로소프트1993년Windows NT
ext2레미 카를1993년리눅스
UFS (FFFS)커크 매큐식1994년4.4BSD
XFSSGI1994년IRIX
UDFISO/Ecma International/OSTA1995년-
FAT32마이크로소프트1996년Windows 95 OSR2
HFS Plus애플1998년Mac OS 8.1
ext3스티븐 트위디1999년리눅스
VMFSVMware2000년VMware ESX
ReiserFSNamesys2001년리눅스
UFS2커크 매큐식2002년FreeBSD 5.0
HFSX애플2003년Mac OS X v10.3
ZFS썬 마이크로시스템즈2004년Solaris
Reiser4Namesys2004년리눅스
NILFSNTT2005년리눅스
ext4Mingming Cao, Dave Kleikamp, Alex Tomas, Andrew Morton 외2006년리눅스
exFAT마이크로소프트2006년Windows Embedded CE 6.0
btrfs오라클2007년리눅스
HAMMER-FSMatthew Dillon2008년DragonFly BSD 2.0
ReFS마이크로소프트2012년Microsoft Windows Server 2012
APFS애플2017년macOS High Sierra



최대 파일명 길이디렉터리명에 사용할 수 있는 문자 종류최대 패스명 길이최대 파일 크기최대 볼륨 크기
Btrfs255바이트NUL 이외의 임의의 바이트제한 정의 없음16 EiB16 EiB
ext2255바이트NUL 이외의 임의의 바이트제한 정의 없음16 GiB – 2 TiB2 TiB – 32 TiB
ext3255바이트NUL 이외의 임의의 바이트제한 정의 없음16 GiB – 2 TiB2 TiB – 32 TiB
ext4255바이트NUL 이외의 임의의 바이트제한 정의 없음16 GiB – 16 TiB1 EiB
FAT128.3 형식 (또는 255자)NUL 이외의 모든 유니코드제한 정의 없음32 MiB1 MiB – 128 MiB
FAT168.3 형식 (또는 255자)NUL 이외의 모든 유니코드제한 정의 없음2 GiB16 MiB – 4 GiB
FAT328.3 형식 (또는 255자)NUL 이외의 모든 유니코드제한 정의 없음4 GiB512 MiB – 2 TiB
HFS+255자 (UTF-16)임의의 올바른 유니코드무제한8 EiB8 EiB
HFS31바이트: 이외의 임의의 바이트무제한2 GiB2 TiB
JFS255바이트NUL 이외의 임의의 바이트제한 정의 없음8 EiB512 TiB – 4 PiB
NILFS255자NUL 이외의 임의의 바이트제한 정의 없음8 EiB8 EiB
NTFS255자NUL 이외의 모든 유니코드유니코드로 32,767자 (파일명 및 디렉터리명은 각각 255자까지)16 EiB16 EiB
ReFS255자 (UTF-16)NUL 이외의 모든 유니코드유니코드로 32,767자 (파일명 및 디렉터리명은 각각 255자까지)16 EiB3.76 ZiB
Reiser4불명불명제한 정의 없음x86에서는 8 TiB불명
ReiserFS4032바이트/255바이트 (VFS에 의한 제한)NUL 이외의 임의의 바이트제한 정의 없음8 TiB16 TiB
RT-1112바이트A-Z, 0-9, $16바이트33,554,432바이트 (65536 * 512)33,554,432바이트
UDF255바이트NUL 이외의 모든 유니코드1023바이트16 EiB불명
UFS (FFS)255바이트NUL 이외의 임의의 바이트제한 정의 없음4 GiB256 TiB
UFS (FFFS)255바이트NUL 이외의 임의의 바이트제한 정의 없음4 GiB – 256 TiB256 TiB
UFS2255바이트NUL 이외의 임의의 바이트제한 정의 없음512 GiB – 32 PiB1 YiB
VxFS255바이트NUL 이외의 임의의 바이트제한 정의 없음16 EiB불명
XFS255바이트NUL 이외의 임의의 바이트제한 정의 없음8 EiB8 EiB



파일 소유자명 유지POSIX 형식 파일 권한생성 시 타임스탬프 (TS)최종 접근 시 TS최종 메타데이터 업데이트 TS최종 아카이브 TSACL보안/MAC 라벨확장 파일 속성/포크체크섬/ECC
RT-11
FAT12
FAT16
FAT32
HPFS불명
NTFS불명
ReFS불명
HFS
HFS+불명
UFS (FFS)
UFS (FFFS)
UFS2
ext2
ext3
ext4
NILFS
ReiserFS
Reiser4
XFS
JFS
VxFS불명
UDF



하드 링크소프트 링크블록 저널링 또는메타데이터만 저널링대소문자 구분대소문자 보존파일 갱신 로그점증적 스냅샷XIP
RT-11
FAT12
FAT16
FAT32
HPFS불명
NTFS불명
ReFS불명불명불명불명불명
HFS+
UFS (FFS)
UFS (FFFS)
UFS2불명
ext2
ext3불명
ext4불명
NILFS불명
ReiserFS불명
Reiser4불명불명
XFS불명
JFS불명불명
ODS-2
UDF
VxFS불명
ZFS



{| class="wikitable" style="width: 100%; text-align: center; font-size: smaller; table-layout: fixed;"

|-style="position:sticky; top:0px"

!

! Tail Packing

! 투명 압축

! 블록 분할 할당

! 지연 할당

! 익스텐트(Extent (file systems))

! 가변 파일 블록 크기

|-

! FAT12

|

|

|

|

|

|

|-

! FAT16

|

|

|

|

|

|

|-

! FAT32

|

|

|

|

|

|

|-

! HPFS

|

|

|

|

|

|

|-

! NTFS

|

|

|

|

|

|

|-

|-

! ReFS

| 불명

|

| 불명

| 불명

| 불명

|

|-

! HFS+

|

|

| 불명

|

|

|

|-

! UFS (FFS)

|

|

|

|

|

|

|-

! UFS (FFFS)

|

|

| {{

4. 2. 데이터베이스 파일 시스템

데이터베이스 기반 파일 시스템은 최근에 등장한 새로운 개념의 파일 시스템이다. 파일을 계층 구조로 관리하지 않고 파일의 형식, 주제, 만든이, 내용과 같은 여러 특성에 따라 시스템에서 자동으로 분류하여 관리한다. 따라서 쿼리 언어나 자연어 등으로 파일을 빠르게 찾을 수 있다.[16]

데이터베이스 기반 파일 시스템의 예시는 다음과 같다.

"순수한" 데이터베이스 파일 시스템은 아니지만, 데이터베이스 파일 시스템의 일부 측면을 사용하는 다른 프로젝트들도 있다. 예를 들어, 많은 웹 콘텐츠 관리 시스템은 파일을 저장하고 검색하기 위해 관계형 DBMS를 사용한다. XHTML 파일은 XML 또는 텍스트 필드로, 이미지 파일은 블롭 필드로 저장된다. SQL SELECT 문(선택적 XPath 포함)을 통해 파일을 검색하며, "일반적인 파일 시스템"보다 정교한 로직과 더 풍부한 정보 연결을 사용할 수 있다. 많은 CMS는 표준 파일 시스템을 사용하여 파일 콘텐츠를 저장하고, 데이터베이스 내에만 메타데이터를 저장하는 옵션을 제공하기도 한다.[16]

IBM DB2 for i [17](이전에는 DB2/400 및 DB2 for i5/OS로 알려짐)는 객체 기반 IBM i[18] 운영 체제의 일부로 데이터베이스 파일 시스템이며, 단일 레벨 스토어를 통합하고 IBM Power Systems(이전에는 AS/400 및 iSeries로 알려짐)에서 실행되며 IBM i의 전 수석 과학자인 Frank G. Soltis가 설계했다. 1978년부터 1988년까지 Frank G. Soltis와 IBM 로체스터 팀은 데이터베이스 파일 시스템과 같은 기술을 성공적으로 설계하고 적용했다.[19]

Apache Hadoop 및 Google File System과 같은 응용 프로그램으로 구현된 매우 큰 파일 시스템은 일부 ''데이터베이스 파일 시스템'' 개념을 사용한다.

4. 3. 트랜잭션 기반 파일 시스템

트랜잭션 기반 파일 시스템은 파일에 발생한 이벤트나 트랜잭션을 기록하는 시스템이다. 사용자가 수행하는 작업은 여러 파일의 내용을 변경할 수 있는데, 이러한 변경 사항은 서로 연관된 경우가 많다. 따라서 이러한 변경 사항이 논리적으로 서로 연결되어 있어야 하는 시스템에서는 이 변화들이 동시에 일어나는 것이 보장되어야 한다.

예를 들어, 은행 계좌에서 돈을 이체하는 경우를 생각해 보자. 온라인으로 돈을 이체할 때 은행 컴퓨터는 상대방의 은행 컴퓨터에 "전송" 명령을 보내고 동시에 사용자의 계좌에서 같은 금액을 줄인다. 그런데 이때 시스템에 사고가 발생하여 전송 명령이 보내지지 않으면, 상대방의 계좌에는 돈이 입금되지 않았는데 사용자의 계좌에서는 돈이 사라지는 문제가 발생할 수 있다.

트랜잭션 기반 시스템은 이렇게 논리적으로 동시에 수행되어야 하는 작업들을 하나의 "트랜잭션"으로 묶어 만약의 사고가 발생했을 때 양쪽에서 트랜잭션을 다시 수행하여 오류를 막는다. 또한 모든 트랜잭션은 기록으로 남아 어디서 무슨 일이 언제 수행되었는지가 기록된다. 이러한 파일 시스템은 시스템의 오류를 막기 위해 설계되었으며, 느리지만 안전하다고 볼 수 있다.

파일 조작으로 인해 발생하는 디스크상의 데이터 구조를 조작하는 이벤트나 트랜잭션을, 그것을 위해 확보해 둔 영역에 우선 기록한 다음 수행하는 방식이다. 많은 경우 데이터 구조의 조작은 서로 관련되어 있기 때문에 "어느 것도 전혀 수행되지 않음" 또는 "모두 성공적으로 완료됨" 중 어느 한쪽이 아니면 손상된 상태가 된다. 예를 들어 은행에서 은행으로 전자 송금하는 경우를 생각해 보자. 은행의 컴퓨터는 다른 은행으로 전송 명령을 "전송"하고, 자신의 기록으로 전송을 시작했음을 보존해 둔다. 만약, 컴퓨터가 기록을 갱신하기 전에 어떤 원인으로 크래시가 발생해 버린 경우, 전송했다는 기록이 남아 있지 않고 돈만 사라져 버린다. 트랜잭션 파일 시스템은 이러한 실수를 사전 기록과 대조하여 감지하고, 롤백하거나 재실행하여 건전한 상태를 유지하려는 시스템이다. 각 트랜잭션은 기록되며, 어디에서 무엇을 했는지에 대한 완전한 기록을 남긴다. 이러한 종류의 파일 시스템은 결함 허용 설계를 의도하여 설계되었기 때문에 오버헤드가 커진다.

윈도우는 비스타부터 Transactional NTFS라는 기능으로 NTFS에 트랜잭션 지원을 추가했지만, 현재 사용이 권장되지 않는다.[20] UNIX 시스템을 위한 트랜잭션 파일 시스템에 대한 여러 연구 프로토타입이 있으며, 여기에는 Valor 파일 시스템,[21] Amino,[22] LFS,[23] 및 TxOS 커널의 트랜잭션 ext3 파일 시스템,[24] 뿐만 아니라 TFFS와 같은 임베디드 시스템을 대상으로 하는 트랜잭션 파일 시스템이 포함된다.[25]

파일 시스템 트랜잭션 없이는 여러 파일 시스템 작업 전반에 걸쳐 일관성을 보장하는 것이 어렵거나 불가능하다. 파일 잠금은 개별 파일에 대한 동시성 제어 메커니즘으로 사용할 수 있지만, 일반적으로 디렉토리 구조나 파일 메타데이터를 보호하지는 않는다. 예를 들어, 파일 잠금은 심볼릭 링크에서 TOCTTOU 경쟁 조건을 방지할 수 없다. 파일 잠금은 또한 소프트웨어 업그레이드와 같은 실패한 작업을 자동으로 롤백할 수 없다. 이는 원자성이 필요하다.

저널링 파일 시스템은 파일 시스템 구조에 트랜잭션 수준의 일관성을 도입하는 데 사용되는 기술 중 하나이다. 저널 트랜잭션은 OS API의 일부로 프로그램에 노출되지 않으며, 단일 시스템 호출의 세분성에서 일관성을 보장하기 위해 내부적으로만 사용된다.

데이터 백업 시스템은 일반적으로 트랜잭션 방식으로 저장된 데이터의 직접 백업을 지원하지 않으므로 신뢰할 수 있고 일관된 데이터 세트를 복구하기가 어렵다. 대부분의 백업 소프트웨어는 전체 데이터 세트의 여러 파일에서 공유되는 트랜잭션 상태와 관계없이 특정 시점 이후에 변경된 파일만 기록한다. 해결책으로, 일부 데이터베이스 시스템은 해당 시점까지의 모든 데이터를 포함하는 보관된 상태 파일을 생성하며, 백업 소프트웨어는 해당 파일만 백업하고 활성 트랜잭션 데이터베이스와 직접 상호 작용하지 않는다. 복구하려면 백업 소프트웨어에서 파일을 복원한 후 상태 파일에서 데이터베이스를 별도로 다시 생성해야 한다.

4. 4. 특수 용도의 파일 시스템

유닉스와 같은 파일 중심의 운영 체제는 여러 가지 특수 용도의 파일 시스템을 사용한다. 예를 들어, 어떤 종류의 유닉스는 '/proc'이라는 파일 시스템에서 프로세스나 운영 체제의 여러 기능에 접근할 수 있다.[41]

심우주 탐사선인 보이저 1호2호에는 디지털 테이프 기반의 파일 시스템이 탑재되어 있다. 카시니-하위헌스 호와 같은 현대 우주선들은 실시간 운영 체제를 위한 파일 시스템을 탑재한다. 화성 탐사선들도 실시간 운영 체제를 탑재하고 있는데, 이들의 파일 시스템은 플래시 메모리를 사용한다.

일부 운영 체제에서는 시스템 관리자가 사용자의 저장 공간 사용을 제한하기 위해 디스크 할당량을 활성화할 수 있다.

플래시 메모리 장치의 특수 기능, 성능 및 제약 사항을 고려한 파일 시스템을 '''플래시 파일 시스템'''이라고 한다. 디스크 파일 시스템은 플래시 메모리 장치를 기본 저장 매체로 사용할 수 있지만, 플래시 장치에 맞게 특별히 설계된 파일 시스템을 사용하는 것이 훨씬 좋다.[15]

테이프에 파일을 저장하도록 설계된 파일 시스템 및 테이프 형식을 '''테이프 파일 시스템'''이라고 한다. 자기 테이프는 디스크보다 무작위 데이터 접근 시간이 훨씬 더 긴 순차적 저장 매체이므로 범용 파일 시스템의 생성 및 효율적인 관리에 어려움이 있다.

IBM은 선형 테이프 파일 시스템이라는 테이프용 파일 시스템을 개발했다. 이 파일 시스템의 IBM 구현은 오픈 소스 IBM 선형 테이프 파일 시스템 — 단일 드라이브 에디션(LTFS-SDE) 제품으로 출시되었다.

일부 파일 시스템은 운영 체제의 요소를 파일로 노출하여 파일 시스템 API를 통해 작업을 수행할 수 있도록 한다. 이는 유닉스 계열 운영 체제에서 흔하며, 다른 운영 체제에서도 어느 정도 사용된다. 예시는 다음과 같다.

  • devfs, udev, TOPS-10는 I/O 장치 또는 가상 장치를 특수 파일로 노출한다.
  • configfs 및 sysfs는 리눅스 커널 정보를 쿼리하고 구성하는 데 사용할 수 있는 특수 파일을 노출한다.
  • procfs는 프로세스 정보를 특수 파일로 노출한다.


1970년대에는 디스크 및 디지털 테이프 장치가 일부 초기 마이크로컴퓨터 사용자에게는 너무 비쌌다. 일반적인 오디오 카세트 테이프를 사용하는 저렴한 기본 데이터 저장 시스템이 고안되었다. 데이터는 순차적으로 저장되었으며, 일반적으로 이름이 없는 형식으로 저장되었지만 일부 시스템(예: 코모도어 PET 시리즈 컴퓨터)에서는 파일에 이름을 지정할 수 있었다.

5. 파일 시스템과 운영 체제

운영 체제는 사용자에게 파일 시스템 접근을 제공하며, 유닉스 셸, Windows 명령 프롬프트 및 PowerShell, OpenVMS DCL과 같은 명령 줄 인터페이스를 제공한다. 또한 MacOS Finder 및 Windows 파일 탐색기와 같은 그래픽 사용자 인터페이스 파일 브라우저도 제공한다.

파일 시스템은 데이터 저장 및 접근 방식을 결정하며, 저장 장치뿐만 아니라 네트워크를 통해 동적으로 생성되는 데이터에도 적용될 수 있다.[41] 일반적으로 여러 계층으로 구성되어 다양한 저장 장치를 지원하고, 하나의 시스템에서 여러 파일 시스템을 사용할 수 있게 한다. 대부분의 운영 체제는 파일을 기본 구성 요소로 사용하며, 파일 시스템을 갖추고 있다. 초기 마이크로컴퓨터 운영 체제인 도스는 파일 관리를 주 목적으로 설계되었고, 단 하나의 파일 시스템만 지원했다.

파일 시스템은 대개 파일 이름을 묶는 디렉터리를 가지며, 파일 이름은 파일 할당 테이블이나 inode와 같은 인덱스와 대응된다. 디렉터리 구조는 평면적이거나 계층적일 수 있으며, 일부 파일 시스템에서는 파일 이름에 확장자나 버전 번호와 같은 구조가 존재한다.

계층형 파일 시스템은 데니스 리치의 초기 연구 대상이었으며, UNIX의 성공 이후 다른 운영 체제 개발에도 영향을 미쳤다. 초기 파일 시스템은 파일 및 디렉터리 관리 기능을 제공했지만, 하드 링크 생성, 부모 링크 명칭 변경, 양방향 링크 생성과 같은 기능은 초기에 존재하지 않았다. 파일 내용의 부분 삭제, 연결, 삽입 등의 기능도 제한적이었다.

파일 시스템의 기본 조작에 대한 안전한 접근은 접근 제어 목록이나 케퍼빌리티를 통해 이루어진다. 상용 파일 시스템은 접근 제어 목록을 주로 사용하지만, 연구 중인 최신 운영 체제에서는 케퍼빌리티가 사용되는 경향이 있다.

일부 애플리케이션 소프트웨어는 독자적인 파일 시스템을 채용하기도 한다. (예: FMR 시리즈・FM TOWNS용 워드 프로세서 소프트웨어 「FM-OASYS」)

파일 시스템명개발자등장 연도최초 지원 OS
RT-11DEC1973년RT-11
FAT12마이크로소프트1977년Microsoft Disk BASIC
ODS-2DEC1979년VMS
UFS (FFS)커크 매큐식1983년4.2BSD
HFS애플1985년Macintosh System 2.1
FAT16마이크로소프트1987년MS-DOS 3.31
HPFSIBM & 마이크로소프트1988년OS/2
JFSIBM1990년AIX
VxFSVERITAS1991년SVR4.0
NTFS마이크로소프트1993년Windows NT
ext2레미 카를1993년리눅스
UFS (FFFS)커크 매큐식1994년4.4BSD
XFSSGI1994년IRIX
UDFISO/Ecma International/OSTA1995년-
FAT32마이크로소프트1996년Windows 95 OSR2
HFS Plus애플1998년Mac OS 8.1
ext3스티븐 트위디1999년리눅스
VMFSVMware2000년VMware ESX
ReiserFSNamesys2001년리눅스
UFS2커크 매큐식2002년FreeBSD 5.0
HFSX애플2003년Mac OS X v10.3
ZFS썬 마이크로시스템즈2004년Solaris
Reiser4Namesys2004년리눅스
NILFSNTT2005년리눅스
ext4Mingming Cao, Dave Kleikamp, Alex Tomas, Andrew Morton 외2006년리눅스
exFAT마이크로소프트2006년Windows Embedded CE 6.0
btrfs오라클2007년리눅스
HAMMER-FSMatthew Dillon2008년DragonFly BSD 2.0
ReFS마이크로소프트2012년Microsoft Windows Server 2012
APFS애플2017년macOS High Sierra


5. 1. 유닉스 계열의 파일 시스템

유닉스나 다른 유닉스 계열 운영 체제들은 여러 개의 주변 장치에 각각의 이름을 붙이지만, 그 주변 장치에 존재하는 파일들은 전부 하나의 계층 구조 아래 관리된다. 다시 말하면, 유닉스에서는 하나의 루트 디렉터리가 있고, 운영 체제에서 접근할 수 있는 모든 파일들은 전부 루트 디렉터리 아래의 어느 디렉터리에 들어 있다. 또한, 루트 디렉터리는 어떤 특정한 하드 디스크에 존재할 필요가 없고, 심지어 네트워크 위의 가상 파일 공간을 루트 디렉터리로 삼을 수도 있다.

다른 주변 장치에 있는 파일에 접근하려면, 이 주변 장치의 파일 시스템을 어떤 디렉터리로 놓을 것인지를 운영 체제에게 알려야 한다. 이것을 가리켜 "파일 시스템을 마운트한다"고 일컫는다. 예를 들어, 유닉스에서 시디롬을 읽으려면 시디롬의 파일 시스템을 루트 밑의 /mnt 디렉터리 밑에 나타나게 하는 명령을 내린다. 일반적으로 컴퓨터의 관리자만이 파일 시스템을 마운트할 수 있다.

유닉스 계열 운영 체제는 가상 파일 시스템을 생성하여 모든 장치의 모든 파일이 단일 계층 구조로 존재하는 것처럼 보이게 한다. 즉, 해당 시스템에는 하나의 루트 디렉터리가 있으며 시스템에 존재하는 모든 파일은 그 아래 어딘가에 위치한다. 유닉스 계열 시스템은 RAM 디스크 또는 네트워크 공유 리소스를 루트 디렉터리로 사용할 수 있다.

유닉스 계열 시스템은 각 장치에 장치 이름을 할당하지만, 해당 장치의 파일에 접근하는 방식은 아니다. 대신 다른 장치의 파일에 접근하려면 운영 체제가 먼저 해당 파일이 디렉터리 트리의 어디에 나타나야 하는지 알려야 한다. 이 프로세스를 파일 시스템 마운트라고 한다. 예를 들어, CD-ROM의 파일에 접근하려면 운영 체제에 "이 CD-ROM에서 파일 시스템을 가져와서 특정 디렉터리 아래에 나타나도록 하십시오."라고 알려야 한다. 운영 체제에 제공된 디렉터리를 ''마운트 지점''이라고 한다. 많은 유닉스 시스템에 존재하며 ( 파일 시스템 계층 구조 표준에 지정됨) CD, DVD, USB 드라이브 또는 플로피 디스크와 같은 이동식 미디어의 마운트 지점으로 사용하기 위해 특별히 고안되었다. 비어 있을 수도 있고, 개별 장치를 마운트하기 위한 하위 디렉터리가 포함될 수도 있다. 일반적으로 시스템 관리자 (즉, 루트 사용자)만 파일 시스템의 마운트를 승인할 수 있다.

유닉스 계열 운영 체제는 종종 마운트 프로세스를 지원하고 새로운 기능을 제공하는 소프트웨어 및 도구를 포함한다. 이러한 전략 중 일부는 목적을 반영하여 "자동 마운트"라고 명명되었다.

  • 많은 상황에서 루트 이외의 파일 시스템은 운영 체제가 부팅되자마자 사용할 수 있어야 한다. 따라서 모든 유닉스 계열 시스템은 부팅 시 파일 시스템을 마운트하는 기능을 제공한다. 시스템 관리자는 옵션과 마운트 지점도 나타내는 구성 파일 fstab ( Solaris의 경우 ''vfstab'')에서 이러한 파일 시스템을 정의한다.
  • 일부 상황에서는 사용 후 사용을 원하는 경우에도 부팅 시 특정 파일 시스템을 마운트할 필요가 없다. 유닉스 계열 시스템에는 요구 시 미리 정의된 파일 시스템을 마운트할 수 있는 유틸리티가 있다.
  • 이동식 미디어를 사용하면 물리적 연결 없이도 기계 간에 프로그램과 데이터를 전송할 수 있다. 일반적인 예로는 USB 플래시 드라이브, CD-ROMDVD가 있다. 따라서 사용자의 개입 없이 미디어의 존재 및 가용성을 감지한 다음 해당 미디어를 마운트하는 유틸리티가 개발되었다.

  • 진보적인 유닉스 계열 시스템은 또한 '''슈퍼마운트'''라는 개념을 도입했다. 예를 들어 [http://sourceforge.net/projects/supermount-ng the Linux supermount-ng project]를 참조할 수 있다. 슈퍼마운트된 플로피 디스크는 시스템에서 물리적으로 제거할 수 있다. 정상적인 상황에서는 디스크를 동기화한 다음 제거하기 전에 마운트를 해제해야 한다. 동기화가 발생했다면 다른 디스크를 드라이브에 삽입할 수 있다. 시스템은 디스크가 변경되었음을 자동으로 감지하고 마운트 지점 내용을 업데이트하여 새 미디어를 반영한다.
  • 자동 마운터는 마운트해야 하는 디렉터리를 참조하면 자동으로 파일 시스템을 마운트한다. 이는 일반적으로 이동식 미디어에 적합한 미디어 삽입과 같은 이벤트에 의존하기보다는 네트워크 서버의 파일 시스템에 사용된다.


리눅스는 수많은 파일 시스템을 지원하지만, 블록 장치의 시스템 디스크에 대한 일반적인 선택으로는 ext* 계열(ext2, ext3, ext4), XFS, JFS, btrfs 등이 있다. 플래시 변환 계층 (FTL) 또는 메모리 기술 장치 (MTD)가 없는 원시 플래시의 경우, UBIFS, JFFS2, YAFFS 등이 있다. SquashFS는 일반적인 압축된 읽기 전용 파일 시스템이다.

솔라리스의 초기 릴리스는 부팅 가능하고 보조적인 파일 시스템으로 (저널링되지 않은 또는 로깅되지 않은) UFS를 기본으로 사용했다. 솔라리스는 UFS를 기본으로 사용하고, 지원하며, 확장했다.

다른 파일 시스템에 대한 지원과 주요 개선 사항이 시간이 지남에 따라 추가되었으며, 여기에는 베리타스 소프트웨어 사의 (저널링) VxFS, 썬 마이크로시스템즈의 (클러스터링) QFS, 썬 마이크로시스템즈의 (저널링) UFS, 그리고 썬 마이크로시스템즈의 (오픈 소스, 풀링 가능, 128비트 압축 가능, 오류 수정) ZFS가 포함된다.

부팅 가능한 베리타스 VxFS 작동을 허용하기 위해 솔라리스에 커널 확장이 추가되었다. 썬의 솔라리스 7에서 UFS에 로깅 또는 저널링이 추가되었다. 솔라리스 10, 솔라리스 익스프레스, OpenSolaris 및 솔라리스 운영 체제의 기타 오픈 소스 변형 릴리스는 나중에 부팅 가능한 ZFS를 지원했다.

논리 볼륨 관리를 사용하면 중복성, 용량 및/또는 처리량을 추가하기 위해 여러 장치에 걸쳐 파일 시스템을 확장할 수 있다. 솔라리스의 레거시 환경에서는 솔라리스 볼륨 관리자 (이전에는 Solstice DiskSuite로 알려짐)를 사용할 수 있다. 여러 운영 체제 (솔라리스 포함)는 베리타스 볼륨 관리자를 사용할 수 있다. 최신 솔라리스 기반 운영 체제는 ZFS의 가상 스토리지 풀을 활용하여 볼륨 관리의 필요성을 대체한다.

macOS (구 Mac OS X)는 2017년에 클래식 Mac OS에서 물려받은 HFS Plus (HFS+)라는 파일 시스템을 대체한 Apple File System (APFS)을 사용한다. 애플은 또한 HFS+에 대해 "Mac OS Extended"라는 용어를 사용한다.[28] HFS Plus는 메타데이터가 풍부하고 대소문자를 보존하지만 (일반적으로) 대소문자를 구분하지 않는 파일 시스템이다. macOS의 Unix 뿌리 때문에 Unix 권한이 HFS Plus에 추가되었다. 이후 HFS Plus 버전에서는 파일 시스템 구조 손상을 방지하기 위해 저널링이 추가되었고, 외부 조각 모음 도구 없이 파일의 자동 조각 모음을 시도하기 위해 할당 알고리즘에 대한 여러 최적화가 도입되었다.

파일 이름은 최대 255자까지 가능하다. HFS Plus는 파일 이름을 저장하기 위해 유니코드를 사용한다. macOS에서 파일 유형은 파일의 메타데이터에 저장된 타입 코드 또는 파일 확장자에서 가져올 수 있다.

HFS Plus에는 Unix 스타일의 하드 링크와 Unix 스타일의 심볼릭 링크 및 별칭의 세 가지 종류의 링크가 있다. 별칭은 파일이 이동하거나 이름이 변경되더라도 원래 파일에 대한 링크를 유지하도록 설계되었으며, 파일 시스템 자체에서 해석되지 않고 유저랜드의 파일 관리자 코드에 의해 해석된다.

2017년 6월 5일 애플의 WWDC 행사에서 발표된 macOS 10.13 High Sierra는 솔리드 스테이트 드라이브에서 Apple File System을 사용한다.

macOS는 또한 BSD Unix Fast File System에서 파생된 UFS 파일 시스템도 지원했다. 하지만 Mac OS X Leopard부터 macOS는 더 이상 UFS 볼륨에 설치할 수 없으며, UFS 볼륨에 설치된 레오파드 이전 시스템을 레오파드로 업그레이드할 수도 없다.[29] Mac OS X Lion부터 UFS 지원은 완전히 중단되었다.

최신 버전의 macOS는 Windows에서 흔히 사용되는 레거시 FAT 파일 시스템(16 및 32)을 읽고 쓸 수 있다. 또한 Windows용 최신 NTFS 파일 시스템을 ''읽을'' 수 있다. Mac OS X Snow Leopard 이전 버전의 macOS에서 NTFS 파일 시스템에 ''쓰기'' 위해서는 타사 소프트웨어가 필요하다. Mac OS X 10.6(Snow Leopard) 이상에서는 NTFS 파일 시스템에 쓸 수 있지만, 사소하지 않은 시스템 설정 변경을 거쳐야 한다(이를 자동화하는 타사 소프트웨어가 존재한다).[30]

마지막으로 macOS는 Mac OS X Snow Leopard 이후 버전 10.6.5부터 exFAT 파일 시스템을 읽고 쓸 수 있다.[31]

Unix 계열 운영체제는 MS-DOS 계열 운영체제와 달리 가상 메모리를 위한 HDD 이용에 가상 메모리 파일 외에도 스왑 파일 시스템도 사용한다.

MS-DOS 계열 운영체제는 HDD의 파티션 내 (OS에서 드라이브로 인식되는 FAT나 NTFS 파일 시스템 내)에 스왑용 숨김 시스템 파일을 생성한다.

Unix 계열 운영체제에서는 예를 들어 리눅스에서는 스왑용 파티션을 준비하여 mkswap, swapon 명령으로 이용 가능하다. FreeBSD 등의 경우에는 BIOS에서 다루는 파티션을 슬라이스라고 칭하며, 그 안에 다시 독자적으로 관리하는 여러 파티션으로 스왑 파일 시스템을 구축한다.

macOS의 파일 시스템은 클래식 Mac OS에서 계승된 HFSX(HFS+)이다. HFSX는 메타데이터가 풍부하고 대소문자 구분(대소문자 보호)을 하는 파일 시스템이다. macOS는 POSIX를 준수하며, HFSX에도 POSIX ACL 준수의 권한 정보가 추가되어 있다. HFSX에는 저널링이 추가되어 파일 시스템 구조의 손상을 방지하며, 자동적으로 조각화된 파일을 정규 블록으로 만드는 등의 할당 기능 최적화도 일부 도입되었다.

파일 이름은 최대 255자이다. HFS+는 파일 이름 저장에 고유한 규칙으로 정규 분해된 유니코드를 사용하고 있다. macOS에서는 파일 포맷을 파일 이름의 타입 코드나 확장자 등으로 종합적으로 판단하고 있다. Mac OS X v10.5부터는 UTI를 사용하여 더 유연하게 포맷을 판단한다.

POSIX 계열 파일 시스템과는 달리, 파일을 디렉토리의 상대 위치로 접근하기 때문에 이론상 경로 길이에 제한이 없다. 다만, 기반이 되는 Darwin이 UNIX 호환성을 유지하기 위해 시스템의 많은 부분에서 1024자를 한계로 하고 있다. Carbon을 경유하여 HFSX에 직접 접근하는 경우에는 예외이다.

HFSX에는 3종류의 링크가 있다. 하드 링크심볼릭 링크 그리고 별칭이다. 별칭은 링크 대상 파일이 이동하거나 이름이 변경되어도 링크를 계속 유지하도록 되어 있다.

5. 2. 마이크로소프트 윈도우의 파일 시스템

마이크로소프트 윈도우는 초기 운영 체제인 MS-DOS를 기반으로 만들어졌지만, 유닉스나 OS/2와 같은 다른 운영 체제의 파일 시스템과 사용자 인터페이스에서 많은 아이디어를 차용했다. 윈도우는 FATNTFS를 사용한다. 초기 FAT 파일 시스템은 파일 이름 길이, 디스크 및 파티션 수에 제한이 있었다.

윈도우 NT와 함께 출시된 NTFS는 접근 제어 리스트 기반의 권한 설정, 하드 링크, 여러 파일 스트림, 쿼터 추적, 압축, 다른 파일 시스템 마운트 기능 등을 제공한다.

다른 운영 체제와 달리 윈도우는 '드라이브 문자'를 사용하여 디스크나 파티션을 구분한다. 예를 들어, C:\WINDOWS\는 C 드라이브 파티션 안에 있는 WINDOWS 디렉터리를 의미한다. C 드라이브는 운영 체제가 설치된 첫 번째 하드 디스크 파티션을 나타내는 문자로 많이 사용되는데, 이는 MS-DOS 시절 A와 B가 플로피 디스크 드라이브를, C가 하드 디스크를 가리켰기 때문이다. 이러한 전통으로 인해 운영 체제가 설치된 파티션이 C 드라이브라고 가정하는 오래된 프로그램들에서 버그가 발생하기도 한다. 네트워크 드라이브 또한 드라이브 문자로 매핑될 수 있다.

윈도 명령 셸에서 나열된 디렉터리 목록.

참조

[1] 웹사이트 5.10. Filesystems https://tldp.org/LDP[...] The Linux Document Project 2021-12-11
[2] 서적 File System Implementation http://pages.cs.wisc[...] Arpaci-Dusseau Books
[3] 웹사이트 Storage, IT Technology and Markets, Status and Evolution https://indico.cern.[...] 2018-09-20
[4] 서적 Office Practice and Business Procedure https://archive.org/[...] Gregg Publishing Company 2016-08-01
[5] 서적 Technical investigations of addition of a hardcopy output to the elements of a mechanized library system : final report, 20 Sept. 1961 Svco Corporation 1961
[6] 서적 Disc File Applications: Reports Presented at the Nation's First Disc File Symposium https://books.google[...] American Data Processing 2016-08-01
[7] 웹사이트 Operating Systems 600.418 The File System http://www.cs.jhu.ed[...] 2016-07-31
[8] 웹사이트 Component Structure of the Logical File System https://www.ibm.com/[...] IBM Corporation 2024-04-24
[9] 학회자료 Proceedings of the November 30--December 1, 1965, fall joint computer conference, Part I on XX - AFIPS '65 (Fall, part I) http://www.multician[...] AFIPS 2011-07-30
[10] 서적 Embedded Microcomputer Systems: Real Time Interfacing https://books.google[...] Cengage Learning 2022-06-30
[11] 웹사이트 KSAM: A B + -tree-based keyed sequential-access method https://www.research[...] 2016-04-29
[12] 서적 Operating Systems https://books.google[...] PHI Learning Pvt. Ltd. 2014-07-27
[13] 웹사이트 Chapter 22. The Z File System (ZFS) https://docs.freebsd[...]
[14] 웹사이트 About Apple File System (APFS) https://daisydiskapp[...]
[15] 서적 Mobile Computing USENIX 1994
[16] 웹사이트 Windows on a database – sliced and diced by BeOS vets https://www.theregis[...] theregister.co.uk 2014-02-07
[17] 웹사이트 IBM DB2 for i: Overview https://web.archive.[...] 03.ibm.com 2014-02-07
[18] 웹사이트 IBM developerWorks : New to IBM i http://www.ibm.com/d[...] Ibm.com 2014-02-07
[19] 웹사이트 XP successor Longhorn goes SQL, P2P – Microsoft leaks https://www.theregis[...] theregister.co.uk 2014-02-07
[20] 웹사이트 Alternatives to using Transactional NTFS (Windows) http://msdn.microsof[...] Msdn.microsoft.com 2014-02-07
[21] 학회자료 Enabling transactional file access via lightweight kernel extensions http://www.fsl.cs.su[...] 2009
[22] 학술지 Extending ACID Semantics to the File System http://www.fsl.cs.su[...] 2007
[23] 학회자료 Transaction Support in a Log-Structured File System http://www.eecs.harv[...] 1993
[24] 학회자료 Operating System Transactions http://www.sigops.or[...] 2009-10
[25] 학회자료 A Transactional Flash File System for Microcontrollers http://www.usenix.or[...]
[26] 서적 Sun's Network File System http://pages.cs.wisc[...] Arpaci-Dusseau Books
[27] 서적 Storage Networks Explained: Basics and Application of Fibre Channel SAN, NAS, iSCSI and InfiniBand https://books.google[...] John Wiley & Sons 2022-06-30
[28] 웹사이트 Mac OS X: About file system journaling http://support.apple[...] Apple 2014-02-08
[29] 웹사이트 Mac OS X 10.5 Leopard: Installing on a UFS-formatted volume https://web.archive.[...] 2016-04-29
[30] 웹사이트 How to Enable NTFS Write Support in Mac OS X http://osxdaily.com/[...] 2013-10-02
[31] 서적 EnCase Computer Forensics - The Official EnCE: EnCase Certified Examiner https://books.google[...] 2014-02-07
[32] 웹사이트 File system formats available in Disk Utility on Mac https://support.appl[...]
[33] 웹사이트 exFAT file system specification https://docs.microso[...]
[34] 서적 The Prospero File System: A Global File System Based on the Virtual System Model http://citeseer.ist.[...]
[35] 학술지 A file system for a general-purpose time-sharing environment https://ieeexplore.i[...] 1975-06
[36] 학술회의자료 The Protection of Information in a General Purpose Time-Sharing Environment https://docs.google.[...]
[37] 웹사이트 The Temple Operating System http://www.templeos.[...] 2017-03-30
[38] 웹사이트 How to Convert FAT Disks to NTFS https://learn.micros[...]
[39] 웹사이트 Ext4 Howto https://ext4.wiki.ke[...] 2016-04-29
[40] 웹사이트 Conversion from Ext3 https://btrfs.wiki.k[...]
[41] 웹사이트 fsspec https://filesystem-s[...]
[42] 서적 Office Practice and Business Procedure https://books.google[...] Gregg Publishing Company 2016-08-01
[43] 서적 Technical investigations of addition of a hardcopy output to the elements of a mechanized library system : final report, 20 Sept. 1961 http://www.worldcat.[...] Svco Corporation 2016-08-01
[44] 서적 Disc File Applications: Reports Presented at the Nation's First Disc File Symposium https://books.google[...] American Data Processing 2016-08-01



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com