본문 바로가기
리눅스

(번역) File system

by 다움위키 2024. 12. 16.

원문 보기: https://dawoum.duckdns.org/wiki/File_system

 

컴퓨팅에서, 파일 시스템 (file system 또는 filesystem, 종종 FS 또는 fs로 약칭)은 파일 구성과 접근을 제어합니다. 지역 파일 시스템은 같은 컴퓨터에서 실행되는 응용 프로그램을 서비스하는 운영 시스템의 기능입니다. 분산 파일 시스템은 네트워크로 연결된 컴퓨터 사이에 파일 접근을 제공하는 프로토콜입니다.

파일 시스템은 응용 프로그램이 대용량 저장소를 공유할 수 있는 데이터 저장 서비스를 제공합니다. 파일 시스템이 없이, 응용 프로그램이 호환되지 않는 방식으로 저장소에 접근하여 자원 경합, 데이터 손상, 및 데이터 손실을 발생시킬 수 있습니다.

다양한 구조와 기능을 갖춘 많은 파일 시스템 설계와 구현이 있으며, 속도, 유연성, 보안, 크기, 등 다양한 특성이 있습니다.

파일 시스템은 하드 디스크 드라이브 (HDD), 솔리드 스테이트 드라이브 (SSD), 자기 테이프, 광 디스크를 포함한 다양한 유형의 저장 장치에 대해 개발되었습니다.

컴퓨터 주요 메모리의 일부는 파일 시스템에 대한 저장 장치 역할을 하는 RAM 디스크로 설정될 수 있습니다. tmpfs와 같은 파일 시스템은 가상 메모리에 파일을 저장할 수 있습니다.

가상 파일 시스템은 요청에 따라 계산된 파일 (가상 파일이라고 함, procfs와 sysfs 참조)에 대한 접근을 제공하거나, 또 다른 백업 저장소에 매핑되는 파일에 대한 접근을 제공합니다.

Introduction

리눅스에서 사용할 수 있는 파일 시스템은 아래에 나와 있습니다.

대체로 많은 배포판에서 ext4를 기본 파일 시스템으로 삼는 경우가 많고, Fedora Linux를 비롯한 일부 배포판에서 btrfs을 기본 파일 시스템으로 삼는 경우가 생기고 있습니다.

물론, 새로운 파일 시스템은 자신만의 특징을 갖고 있어, 특수한 목적에서 해당 기능을 사용함으로써 생길 수 있는 이득이 있을 때에는 그런 기능을 지원하는 파일 시스템을 사용하는 것이 바람직합니다.

그러나, 데스크탑으로 사용하는 일반 사용자의 입장에서는 특정 기능이 필요하긴 하지만, 반대 급부를 반드시 확인해야 합니다.

예를 들어, btrfs은 예상치 못하는 셧다운에서 파일 시스템을 제대로 고쳐주지 못하는 경우가 생겨서 부팅이 되지 않을 수 있습니다. 그런 경우에서, 라이브 시디로 부팅한 후에 해당 시스템이 가진 백업 기능을 통해 복구할 수 있긴 합니다.

반면에, 수많은 셧다운에서도 ext4는 복구하지 못하는 경우를 몇 년 내에는 발견한 적이 없습니다. (가상 기계에서 디스플레이 서비스가 적절히 올라오지 않는 경우가 생기면서 수없이 강제 리부팅, 또는 강제 종료를 해 왔습니다)

그럼에도 불구하고, 비교적 최근에 만들어지고 있는 btrfs은 새로운 기능들이 포함되어 있습니다. 그런 기능이 필요한 경우에는 btrfs을 이용해 볼 수 있습니다.

이는 비교를 위한 예제일 뿐이고, 다른 파일 시스템도 나름대로의 쓰임이 있습니다.

어쨌든, 그런 부분에 대해 인식을 하지 못하고 있을 때에는 배포판에서 제공하는 기본 파일 시스템을 이용하는 것이 대체로 바람직합니다.

Etymology

1900년경부터 컴퓨터가 등장하기 전까지, 파일 시스템 (file system, filing system, 및 system for filing)이라는 용어는 종이 문서를 정리, 저장, 및 검색하는 방법을 설명하기 위해 사용되었습니다. 1961년까지, 파일 시스템이라는 용어는 원래 의미와 함께 컴퓨터화된 파일링에도 적용되었습니다. 1964년까지, 그것은 일반적으로 사용되었습니다.

Architecture

지역 파일 시스템의 아키텍처는, 심지어 특정 파일 시스템 설계가 실제로 개념을 분리하지 않더라도, 추상화의 계층으로 설명될 수 있습니다.

논리적 파일 시스템 계층은 열기, 닫기, 읽기, 및 쓰기를 포함한 파일 작업에 대한 응용 프로그램 프로그래밍 인터페이스 (API)를 통해 상대적으로 높은-수준의 접근을 제공하며, 작업은 하위 계층에 위임합니다. 이 계층은 열린 파일 테이블 항목과 프로세스-별 파일 설명자를 관리합니다. 그것은 파일 접근, 디렉토리 작업, 보안과 보호를 제공합니다.

옵션 계층인 가상 파일 시스템은 각각 파일 시스템 구현이라고 하는 여러 개의 동시 물리적 파일 시스템의 인스턴스를 지원합니다.

물리적 파일 시스템 계층은 저장 장치 (예를 들어, 디스크)에 대한 비교적 저-수준 접근을 제공합니다. 그것은 데이터 블록을 읽고 쓰고, 버퍼링과 기타 메모리 관리를 제공하고, 저장 매체의 특정 위치에 블록을 배치하는 것을 제어합니다. 이 계층은 저장 장치를 구동하기 위해 장치 드라이버 또는 채널 I/O를 사용합니다.

Attributes

File names

Main article: Filename

파일 이름(file name, 또는 filename)은 파일을 사용하는 응용 프로그램과 어떤 경우에는 사용자에게 식별시켜줍니다.

파일 이름은 고유하므로 응용 프로그램은 특정 이름으로 정확하게 하나의 파일을 참조할 수 있습니다. 만약 파일 시스템이 디렉토리를 지원하면, 일반적으로 각 디렉토리의 컨텍스트 내에서 파일 이름 고유성이 적용됩니다. 다시 말해, 저장 장치는 같은 이름의 여러 파일을 포함할 수 있지만, 같은 디렉토리에는 있을 수 없습니다.

대부분의 파일 시스템은 파일 이름의 길이를 제한합니다.

일부 파일 시스템은 파일 이름을 대소문자 구분으로 일치시키고 다른 파일 시스템은 대소문자 구분 없이 일치시킵니다. 예를 들어, MYFILE과 myfile이라는 이름은 대소문자 구분 없이 같은 파일에 열치하지만, 대소문자 구분에 대해 다른 파일에 일치합니다.

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

Directories

Main article: Directory (computing)

파일 시스템은 전형적으로 파일을 디렉토리 (폴더라고도 함)로 구성하는 기능을 지원하며, 디렉토리는 파일을 그룹으로 분류합니다.

이것은 파일 이름을 목차의 인덱스나 유닉스-계열 파일 시스템의 inode와 결합함으로써 구현될 수 있습니다.

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

디렉토리의 임의적인 계층 구조를 지원하는 최초의 파일 시스템은 Multics 운영 시스템에서 사용되었습니다. 유닉스-계열 시스템의 기본 파일 시스템도 임의적인 디렉토리 계층 구조를 지원하며, 클래식 Mac OS에서 Apple의 계층 파일 시스템과 그 후속 버전인 HFS+, MS-DOS 2.0 및 이후 버전의 MS-DOS와 Microsoft Windows의 FAT 파일 시스템, Windows NT 가족의 운영 시스템의 NTFS 파일 시스템, 및 OpenVMS의 ODS-2 (On-Disk Structure-2) 및 상위 레벨의 Files-11 파일 시스템도 마찬가지입니다.

 

Metadata

데이터 외에도, 파일 시스템은 파일 콘텐츠와 결합된 메타데이터도 관리합니다. 여기에는 다음이 포함될 수 있지만 이에 국한되지 않습니다:

파일 시스템은 파일 컨텐츠와 별도로 결합된 메타데이터를 저장합니다.

대부분의 파일 시스템은 한 디렉토리에 있는 모든 파일의 이름을 한 곳—해당 디렉토리에 대한 디렉토리 테이블—에 저장하며, 이는 종종 다른 파일과 마찬가지로 저장됩니다. 많은 파일 시스템은 파일에 대한 일부 메타데이터만 디렉토리 테이블에 저장하고, 해당 파일에 대한 나머지 메타데이터를 inode와 같은 완전히 별도의 구조에 저장합니다.

대부분의 파일 시스템은 역시 어떤 특정 파일과도 결합되지 않은 메타데이터를 저장합니다. 그러한 메타데이터에는 사용되지 않는 영역—여유 공간 비트맵, 블록 가용성 맵—에 대한 정보와 불량 섹터에 대한 정보를 포함합니다. 종종 할당 그룹에 대한 그러한 정보는 할당 그룹 자체 내부에 저장됩니다.

추가 속성은 NTFS, XFS, ext2, ext3, 일부 버전의 UFS, 및 HFS+와 같은 파일 시스템에서 확장 파일 속성을 사용하여 결합될 수 있습니다. 일부 파일 시스템은 문서의 작성자, 문서의 문자 인코딩 또는 이미지 크기와 같은 사용자 정의 속성을 제공합니다.

일부 파일 시스템은 서로 다른 데이터 모음을 하나의 파일 이름과 결합시킬 수 있습니다. 이들 별도의 모음을 스트림(streams) 또는 포크(forks)라고 합니다. Apple은 오랫동안 Macintosh에서 포크 파일 시스템을 사용했고, Microsoft는 NTFS에서 스트림을 지원합니다. 일부 파일 시스템은 단일 파일 이름아래에서 파일의 여러 이전 개정판을 유지합니다; 파일 이름 자체만으로 가장 최신 버전을 검색하고, 반면에 이전에 저장된 버전은 "filename;4" 또는 "filename(-4)"와 같은 특수 명명 규칙을 사용하여 4번 저장된 버전에 접근할 수 있습니다.

각 파일 시스템이 어떤 종류의 메타데이터를 지원하는지 자세히 알아보려면 comparison of file systems#Metadata를 참조하십시오.

Storage space organization

지역 파일 시스템은 어떤 저장 영역이 어떤 파일에 속하는지, 어떤 영역이 사용되지 않는지를 추적합니다.

파일 시스템이 파일을 만들 때, 데이터를 위한 공간을 할당합니다. 일부 파일 시스템은 파일이 커짐에 따라 초기 공간 할당과 이후 증분 할당을 지정하도록 허용하거나 요구합니다.

파일을 삭제하기 위해, 파일 시스템이 해당 파일의 공간이 비어 있고 또 다른 파일에 사용할 수 있다고 기록해야 합니다.

지역 파일 시스템은 저장 공간을 관리하여 안정성과 효율성 수준을 제공합니다. 일반적으로, 그것은 저장 장치 공간을 세분화된 방식, 보통 여러 개의 물리적 단위 (예를 들어, 바이트)로 할당합니다. 예를 들어, 1980년대 초 Apple DOS에서, 140킬로바이트 플로피 디스크의 256-바이트 섹터는 트랙/섹터 맵을 사용했습니다.[citation needed]

세분화된 특성으로 인해 각 파일에 대해 사용되지 않는 공간 (때로는 여유 공간이라고도 함)이 생기지만, 세분화된 할당의 배수인 드문 크기를 갖는 파일은 예외입니다. 512-바이트 할당에 대해, 사용되지 않는 평균 공간은 256바이트입니다. 64KB 클러스터에 대해, 사용되지 않는 평균 공간은 32KB입니다.

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

Fragmentation

파일 시스템이 파일을 생성, 수정, 및 삭제함에 따라, 기본 저장소 표현이 조각화될 수 있습니다. 파일과 파일 사이의 사용되지 않은 공간은 연속되지 않은 할당 블록을 차지합니다.

파일의 컨텐츠를 저장하기 위해 필요한 공간을 연속된 블록으로 할당할 수 없으면 파일이 조각화됩니다. 파일이 삭제될 때 여유 공간이 조각화됩니다.

이는 최종 사용자에게는 보이지 않고 시스템은 여전히 ​​올바르게 작동합니다. 어쨌든, 이것은 하드 디스크 드라이브와 같이 연속 블록에서 더 잘 작동하는 일부 저장 장치 하드웨어에서 성능을 저하시킬 수 있습니다. 솔리드-스테이트 드라이브와 같은 다른 하드웨어는 조각화의 영향을 받지 않습니다.

Access control

파일 시스템은 종종 자신이 관리하는 데이터의 접근 제어를 지원합니다.

접근 제어의 목적은 특정 사용자가 특정 파일을 읽거나 수정하는 것을 방지하는 것입니다.

접근 제어는 데이터가 제어된 방식으로 수정되도록 하기 위해 프로그램-별 접근을 제한할 수도 있습니다. 예를 들어 파일이나 다른 곳의 메타데이터에 저장된 비밀번호와 권한 비트, 접근 제어 목록 또는 기능 형태의 파일 권한이 있습니다. 파일 시스템 유틸리티가 미디어 수준에서 데이터에 접근하여 구조를 재구성하고 효율적인 백업을 제공해야 하는 필요성은 보통 이들 유틸리티가 예의 바른 사용자에게만 효과적이며 침입자에게는 효과적이지 않음을 의미합니다.

파일 데이터를 암호화하는 방법은 때때로 파일 시스템에 포함됩니다. 이것은 파일 시스템 유틸리티가 데이터를 효과적으로 관리하기 위해 암호화 시드를 알 필요가 없기 때문에 매우 효과적입니다. 암호화에 의존하는 위험에는 공격자가 데이터를 복사하고 무차별 대입 공격을 사용하여 데이터를 해독할 수 있다는 사실이 포함됩니다. 추가적으로, 시드를 잃으면 데이터를 잃는다는 것을 의미합니다.

Storage quota

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

Data integrity

파일 시스템은 전형적으로 저장된 데이터가 일반 작업과 다음과 같은 예외 상황에서 모두 일관되게 유지되도록 보장합니다:

  • 프로그램 접근이 파일 접근을 완료했다는 사실을 파일 시스템에 알리지 않음 (파일 닫기)
  • 프로그램 접근이 비정상적으로 종료됩니다 (충돌)
  • 미디어 실패
  • 원격 시스템과의 연결 끊김
  • 운영 시스템 실패
  • 시스템 리셋 (소프트 리부팅)
  • 파워 실패 (하드 리부팅)

예외적인 상황에서 복구하려면 메타데이터, 디렉토리 항목을 업데이트하고 버퍼링은 되었지만 저장 매체에 기록되지 않은 데이터를 처리하는 작업이 포함될 수 있습니다.

Recording

파일 시스템은 다음과 같은 문제를 분석할 수 있도록 이벤트를 기록할 수 있습니다:

  • 파일 또는 시스템 문제 및 성능
  • 사악한 접근

Data access

Byte stream access

많은 파일 시스템은 바이트 스트림으로 데이터에 접근합니다. 전형적으로, 파일 데이터를 읽기 위해, 프로그램은 메모리 버퍼를 제공하고 파일 시스템은 매체에서 데이터를 검색하고 그런-다음 버퍼에 데이터를 씁니다. 쓰기는 프로그램이 파일 시스템이 읽고 매체에 저장하는 바이트 버퍼를 제공하는 것을 포함합니다.

Record access

일부 파일 시스템, 또는 파일 시스템의 꼭대기 계층은 프로그램이 데이터를 구조로서 읽고 쓸 수 있도록 레코드를 정의할 수 있도록 허용합니다; 즉, 정리되지 않은 바이트 시퀀스가 ​​아닌 구조로서 데이터를 읽고 쓸 수 있습니다.

만약 고정 길이 레코드 정의가 사용되면, n번째 레코드를 찾는 것을 수학적으로 계산할 수 있으며, 이는 레코드 구분 기호에 대한 데이터 구문 분석에 비해 상대적으로 빠릅니다.

각 레코드에 대한 식별 (키라고도 함)을 통해 프로그램은 저장소의 위치와 관계없이 레코드를 읽고, 쓰고, 업데이트할 수 있습니다. 그러한 저장소에는 미디어 블록을 관리해야 하며, 보통 키 블록과 데이터 블록을 분리해야 합니다. 레코드를 찾기 위한 피라미드 구조로 효율적인 알고리즘을 개발할 수 있습니다.

Utilities

전형적으로, 파일 시스템은 사용자가 다양한 유틸리티 프로그램을 통해 관리할 수 있습니다.

일부 유틸리티는 사용자가 파일 시스템의 인스턴스를 만들고, 구성하고, 제거할 수 있도록 합니다. 그것은 파일 시스템에 할당된 공간을 확장하거나 잘라낼 수 있습니다.

디렉토리 유틸리티는 디렉토리 항목을 만들고, 이름을 바꾸고, 삭제하는 데 사용할 수 있으며, 이는 dentries (단수형: dentry)라고도 하고, 디렉토리와 결합된 메타데이터를 변경합니다. 디렉토리 유틸리티에는 디렉토리에 대한 추가 링크 (유닉스에서 하드 링크)를 만들고, 부모 링크의 이름을 바꾸는 기능 (유닉스-계열 운영 시스템에서 "..")과 파일에 대한 양방향 링크를 만드는 기능도 포함될 수 있습니다.

파일 유틸리티는 파일을 생성, 나열, 복사, 이동, 및 삭제하고 메타데이터를 변경합니다. 그것들은 데이터를 잘라내고, 공간 할당을 잘라내거나 확장하고, 파일을 제자리에 덧붙이고, 이동하고, 수정할 수 있습니다. 파일 시스템의 기본 구조에 따라, 그것들은 파일의 시작 부분에 추가하거나 잘라내고, 파일 중간에 항목을 삽입하거나, 파일에서 항목을 삭제하는 메커니즘을 제공할 수 있습니다. 만약 파일 시스템이 삭제 취소 기능을 제공하면, 삭제된 파일의 공간을 확보하는 유틸리티도 이 카테고리에 속합니다.

일부 파일 시스템은 여유 공간의 재조직, 여유 공간의 안전한 지우기, 계층적 구조의 재구축과 같은 작업을 최소한의 활동 시간에 이들 기능을 수행하는 유틸리티를 제공함으로써 연기합니다. 한 가지 예제가 파일 시스템 조각 모으기 유틸리티입니다.

파일 시스템 유틸리티의 가장 중요한 기능 중 일부는 기본 장치에 대한 소유권이나 직접 접근을 우회하는 것을 포함할 수 있는 감독 활동입니다. 여기에는 고성능 백업 및 복구, 데이터 복제, 파일 시스템 내의 다양한 데이터 구조 및 할당 테이블의 재구성이 포함됩니다.

File system API

유틸리티, 라이브러리 및 프로그램은 파일 시스템 API를 사용하여 파일 시스템에 대한 요청을 합니다. 여기에는 데이터 전송, 위치 지정, 메타데이터 업데이트, 디렉토리 관리, 접근 사양 관리, 및 제거가 포함됩니다.

Multiple file systems within a single system

자주, 소매 시스템은 전체 저장 장치를 차지하는 단일 파일 시스템으로 구성됩니다.

또 다른 방법은 서로 다른 속성을 갖는 여러 파일 시스템이 사용할 수 있도록 디스크를 파티셔닝하는 것입니다. 브라우저 캐시 또는 이메일 저장소로 사용하기 위한 하나의 파일 시스템은 작은 할당 크기로 구성될 수 있습니다. 이렇게 하면 브라우저 활동에서 일반적으로 발생하는 파일 생성과 삭제 활동이 다른 파일 할당을 방해하지 않는 디스크의 좁은 영역에 유지됩니다. 비교적 큰 블록 크기를 가진 오디오 또는 비디오 파일을 저장하기 위한 또 다른 파티션이 생성될 수 있습니다. 또 다른 파티션은 통상적으로 읽기-전용으로 설정되고 주기적으로만 쓰기-가능으로 설정될 수 있습니다. ZFS and APFS와 같은, 일부 파일 시스템은 공통적인 여유 블록 풀을 공유하는 여러 파일 시스템을 지원하여 각 파일 시스템에 대해 고정된 양의 공간을 예약하지 않고도 서로 다른 속성을 가진 여러 파일 시스템을 지원합니다.

세 번째 접근 방식은, 이는 대부분 클라우드 시스템에서 사용되며, "디스크 이미지"를 사용하여 또 다른 (호스트) 파일 시스템 내에 동일한 속성이 있거나 없는 추가 파일 시스템을 파일로 보관하는 것입니다. 공통적인 예로는 가상화가 있습니다: 한 사용자는 자신의 프로덕션 윈도우 환경 (NTFS 사용) 아래에서 가상 기계에서 실험적 리눅스 배포판 (ext4 파일 시스템 사용)을 실행할 수 있습니다. ext4 파일 시스템은 디스크 이미지에 상주하며, 디스크 이미지가 NTFS 호스트 파일 시스템에서 파일 (또는 하이퍼바이저 및 설정에 따라 여러 파일)로 처리됩니다.

단일 시스템에 여러 파일 시스템을 가지는 것은 단일 파일 시스템의 손상의 사건에서, 남아있는 파일 시스템은 종종 손상되지 않는다는 추가적인 이점이 있습니다. 여기에는 시스템 파일 시스템의 바이러스 파괴 또는 심지어 부팅되지 않는 시스템이 포함됩니다. 전용 접근이 필요한 파일 시스템 유틸리티는 효과적으로 조각조각 완료될 수 있습니다. 게다가, 조각 모으기가 더 효과적일 수 있습니다. 바이러스 검사와 백업과 같은 여러 시스템 유지 관리 유틸리티도 세그먼트로 처리될 수 있습니다. 예를 들어, 마지막 백업 이후에 아무것도 추가되지 않은 경우 비디오가 포함된 파일 시스템을 다른 모든 파일과 함께 백업할 필요가 없습니다. 이미지 파일에 대해, 마스터 (원본) 이미지에 기록된 "새로운" 데이터만 포함된 차이 이미지를 쉽게 "분할"할 수 있습니다. 차이 이미지는 안전 문제 (바이러스에 의해 파괴되거나 오염되면, 빠르게 복구할 수 있는 "일회용" 시스템, 자동화된 절차 없이도 기존 이미지를 제거하고 몇 초 만에 새 이미지를 만들 수 있으므로)와 빠른 가상 기계 배포 (배치별로 스크립트를 사용하여 차이 이미지를 빠르게 생성할 수 있으므로)를 위해 모두 사용할 수 있습니다.

Types

Disk file systems

디스크 파일 시스템은 디스크 저장 매체가 짧은 시간 내에 데이터를 무작위로 주소 지정할 수 있는 기능을 활용합니다. 추가 고려 사항으로는 처음 요청한 데이터에 접근하는 속도와 그 다음 데이터도 요청될 수 있다는 예상이 있습니다. 이를 통해 여러 사용자 (또는 프로세스)가 데이터의 순차적 위치에 관계없이 디스크의 다양한 데이터에 접근할 수 있습니다. 예로는 FAT (FAT12, FAT16, FAT32), exFAT, NTFS, ReFS, HFS and HFS+, HPFS, APFS, UFS, ext2, ext3, ext4, XFS, btrfs, Files-11, Veritas File System, VMFS, ZFS, ReiserFS, NSS, 및 ScoutFS가 있습니다. 일부 디스크 파일 시스템은 저널링 파일 시스템 또는 버전 관리 파일 시스템입니다.

Optical discs

ISO 9660과 Universal Disk Format (UDF)는 컴팩트 디스크, DVD, 및 블루레이 디스크를 대상으로 하는 두 가지 공통적인 형식입니다. Mount Rainier는 리눅스 커널 2.6 시리즈와 Windows Vista부터 지원되는 UDF 확장으로 DVD에 다시 쓰기를 용이하게 합니다.

Flash file systems

Main article: Flash file system

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

Tape file systems

테이프 파일 시스템은 테이프에 파일을 저장하도록 설계된 파일 시스템과 테이프 형식입니다. 자기 테이프는 디스크보다 훨씬 긴 무작위 데이터 접근 시간을 가진 순차적 저장 매체로, 일반적인-목적 파일 시스템의 생성과 효율적인 관리에 어려움을 줍니다.

디스크 파일 시스템에서, 전형적으로 마스터 파일 디렉토리가 있고, 사용된 데이터 영역과 여유 데이터 영역의 맵이 있습니다. 임의의 파일 추가, 변경, 또는 제거는 디렉토리와 사용된/여유 맵 업데이트를 요구합니다. 데이터 영역에 대한 무작위 접근은 밀리초 단위로 측정되므로 이 시스템은 디스크에 대해 적합합니다.

테이프는 매우 긴 미디어 릴을 감고 푸는 데 선형 운동이 필요합니다. 이 테이프 운동은 읽기/쓰기 헤드를 테이프의 한쪽 끝에서 다른 쪽 끝으로 옮기는 데 몇 초에서 몇 분이 걸릴 수 있습니다.

결과적으로, 마스터 파일 디렉토리와 사용 맵은 테이프에서 매우 느리고 비효율적일 수 있습니다. 쓰기는 전형적으로 블록 사용 맵을 읽어 쓰기에 사용할 수 있는 빈 블록을 찾고, 사용 맵과 디렉토리를 업데이트하여 데이터를 추가하고, 그런-다음 테이프를 진행하여 올바른 위치에 데이터를 쓰는 것을 포함합니다. 각 추가 파일 쓰기는 맵과 디렉토리를 업데이트하고 데이터를 쓰기를 요구하며, 이는 각 파일에 대해 몇 초가 걸릴 수 있습니다.

이에 반해 테이프 파일 시스템은 전형적으로 시간이 많이 걸리고 반복적인 테이프 동작이 새 데이터를 쓰기 위해 필요하지 않도록 파일 디렉토리를 데이터와 섞어 테이프에 분산시키는 것을 허용하며, 이를 스트리밍이라고 합니다.

어쨌든, 이 설계의 부작용은 테이프의 파일 디렉토리를 읽는 것이 보통 테이프 전체를 스캔하여 분산된 모든 디렉토리 항목을 읽어야 한다는 것입니다. 테이프 저장 장치를 갖는 작동하는 대부분의 데이터 보관 소프트웨어는 테이프에 파일을 추가하는 것이 테이프 미디어를 다시 스캔하지 않고도 빠르게 추가될 수 있도록 테이프 카탈로그의 지역 사본을 디스크 파일 시스템에 저장할 것입니다. 지역 테이프 카탈로그 사본은 보통 지정된 기간 동안 사용되지 않으면 폐기되며, 이 시점에서 테이프를 나중에 사용하려면 다시 스캔해야 합니다.

IBM은 선형 테이프 파일 시스템이라는 테이프에 대한 파일 시스템을 개발했습니다. 이 파일 시스템의 IBM 구현은 오픈-소스 IBM 선형 테이프 파일 시스템 — Single Drive Edition (LTFS-SDE) 제품으로 출시되었습니다. 선형 테이프 파일 시스템은 테이프의 별도 파티션을 사용하여 인덱스 메타데이터를 기록하므로, 전체 테이프에 디렉토리 항목을 분산시키는 것과 관련된 문제를 피할 수 있습니다.

Tape formatting

테이프에 데이터를 쓰거나, 지우거나, 테이프를 포맷하는 것은 종종 상당히 시간이 많이 걸리는 프로세스이고 대형 테이프에서는 몇 시간이 걸릴 수 있습니다. 많은 데이터 테이프 기술과 함께, 테이프에 새 데이터를 덮어쓰기 전에 테이프를 포맷할 필요가 없습니다. 이것은 순차적 미디어에서 데이터를 덮어쓰기하는 것이 본질적으로 파괴적이기 때문입니다.

테이프를 포맷하는 데 시간이 걸릴 수 있기 때문에, 전형적으로 테이프는 미리-포맷되어 테이프 사용자가 새 테이프를 사용할 준비를 하는 데 시간을 할애할 필요가 없습니다. 보통 필요한 것은 사용하기 전에 테이프에 식별 미디어 레이블을 쓰는 것뿐이고, 심지어 새 테이프를 처음 사용할 때 소프트웨어에서 자동으로 쓸 수도 있습니다.

Database file systems

파일 관리에 대한 또 다른 개념은 데이터베이스-기반 파일 시스템이라는 개념입니다. 계층적 구조 관리 대신 또는 이에 추가하여, 파일은 파일 유형, 주제, 작성자, 또는 이와 유사한 풍부한 메타데이터와 같은 특성으로 식별됩니다.

IBM DB2 for i (이전 명칭 DB2/400 및 DB2 for i5/OS)는 대상 기반 IBM i 운영 시스템 (이전 명칭 OS/400 및 i5/OS)의 일부인 데이터베이스 파일 시스템으로, 단일 수준 저장소를 통합하고 IBM Power Systems (이전 명칭 AS/400 및 iSeries)에서 실행되며, IBM의 이전 IBM i 수석 과학자인 Frank G. Soltis가 설계했습니다. 1978년에서 1988년 사이에, Frank G. Soltis와 IBM Rochester에서 그의 팀은 Microsoft와 같은 다른 회사가 나중에 달성하지 못한 데이터베이스 파일 시스템과 같은 기술을 성공적으로 설계하고 적용했습니다. 이들 기술은 비공식적으로 'Fortress Rochester'로 알려져 있고 몇 가지 기본적인 측면에서 초기 메인프레임 기술에서 확장되었지만 기술적 관점에서 여러 면에서 더 발전했습니다.

"순수한" 데이터베이스 파일 시스템이 아니지만 데이터베이스 파일 시스템의 일부 측면을 사용하는 다른 프로젝트:

  • 많은 웹 컨텐츠 관리 시스템은 관계형 DBMS를 사용하여 파일을 저장하고 검색합니다. 예를 들어, XHTML 파일은 XML 또는 텍스트 필드로 저장되고, 반면에 이미지 파일은 blob 필드로 저장됩니다; SQL SELECT (선택 사항인 XPath와 함께) 문은 파일을 검색하고, "보통의 파일 시스템"보다 정교한 논리와 더 풍부한 정보 연결을 사용할 수 있습니다. 많은 CMS는 역시 표준 파일 시스템과 함께 파일의 컨텐츠를 저장하기 위해 사용되며, 데이터베이스 내에 메타데이터만 저장하는 옵션이 있습니다.
  • Apache Hadoop 및 Google File System과 같은 응용 프로그램으로 구현된 매우 큰 파일 시스템은 일부 데이터베이스 파일 시스템 개념을 사용합니다.

Transactional file systems

일부 프로그램은 여러 파일 시스템을 변경해야 하거나, 변경 중 하나 이상이 어떤 이유로 실패하면 변경을 전혀 하지 않습니다. 예를 들어, 소프트웨어를 설치하거나 업데이트하는 프로그램은 실행 파일, 라이브러리, 및/또는 구성 파일을 쓸 수 있습니다. 만약 쓰기 중 일부가 실패하고 소프트웨어가 부분적으로 설치되거나 업데이트된 상태로 남아 있으면, 소프트웨어가 손상되거나 사용할 수 없게 될 수 있습니다. 명령 쉘과 같은 주요 시스템 유틸리티의 업데이트가 완료되지 않는 것은 전체 시스템을 사용할 수 없는 상태로 남겨둘 수 있습니다.

트랜잭션 처리에서는 원자성(atomicity) 보장을 도입하여, 트랜잭션 내부의 작업이 모두 커밋되거나 트랜잭션이 중단될 수 있고 시스템이 모든 부분 결과를 삭제하도록 보장합니다. 이것은 복구 후 충돌이나 전원 장애가 발생하더라도, 저장된 상태가 일관되게 유지됨을 의미합니다. 소프트웨어가 완전히 설치되거나 실패된 설치가 완전히 롤백되지만, 사용할 수 없는 부분 설치가 시스템에 남지 않을 것입니다. 트랜잭션은 역시 격리 보장을 제공하며, 트랜잭션 내의 작업이 트랜잭션이 커밋될 때까지 시스템의 다른 스레드에서 숨겨지고, 시스템에서 간섭하는 작업이 트랜잭션과 함께 적절하게 직렬화됨을 의미합니다.

Vista부터 시작하는 Windows는 Transactional NTFS라는 기능에서 NTFS에 트랜잭션 지원을 추가했지만, 현재는 사용이 권장되지 않습니다. Valor 파일 시스템, Amino, LFS, 및 TxOS 커널의 트랜잭션 ext3 파일 시스템을 비롯하여, 유닉스 시스템에 대한 트랜잭션 파일 시스템의 여러 연구 프로토타입이 있고, TFFS와 같은 임베디드 시스템을 타겟으로 하는 트랜잭션 파일 시스템도 있습니다.

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

저널링 파일 시스템은 파일 시스템 구조에 트랜잭션-수준의 일관성을 도입하기 위해 사용되는 한 가지 기술입니다. 저널 트랜잭션은 OS API의 일부로 프로그램에 노출되지 않습니다; 그것들은 단일 시스템 호출의 세분성에서 일관성을 보장하기 위해 내부적으로만 사용됩니다.

데이터 백업 시스템은 전형적으로 트랜잭션 방식으로 저장된 데이터의 직접 백업에 대한 지원을 제공하지 않으며, 이는 안정적이고 일관된 데이터 집합을 복구하기 어렵게 만듭니다. 대부분의 백업 소프트웨어는 전체 데이터 집합의 여러 파일에서 공유되는 트랜잭션 상태에 관계없이 특정 시간 이후에 변경된 파일을 간단히 기록합니다. 해결 방법으로, 일부 데이터베이스 시스템은 해당 지점까지의 모든 데이터를 포함하는 보관된 상태 파일을 간단히 생성하고, 백업 소프트웨어는 해당 파일만 백업하고 활성 트랜잭션 데이터베이스와 직접 상호 작용하지 않습니다. 복구는 백업 소프트웨어에 의해 파일이 복원된 후 상태 파일에서 별도로 데이터베이스를 재생성하도록 요구합니다.

Network file systems

네트워크 파일 시스템은 원격 파일 접근 프로토콜의 클라이언트 역할을 하는 파일 시스템으로, 서버의 파일에 대한 접근을 제공합니다. 지역 인터페이스를 사용하는 프로그램은 원격 네트워크-연결 컴퓨터에서 계층적 디렉토리와 파일을 투명하게 생성, 관리, 및 접근할 수 있습니다. 네트워크 파일 시스템의 예로는 NFS, AFS, SMB 프로토콜에 대한 클라이언트, 및 FTP와 WebDAV에 대한 파일 시스템과 유사한 클라이언트가 있습니다.

Shared disk file systems

공유 디스크 파일 시스템은 여러 기계 (보통 서버)가 모두 같은 외부 디스크 하위 시스템 (보통 저장 장치 영역 네트워크)에 접근할 수 있는 시스템입니다. 파일 시스템은 해당 하위 시스템에 대한 접근을 중재하여, 쓰기 충돌을 방지합니다. 예로는 Red Hat으로부터 GFS2, IBM으로부터 GPFS (현재 Spectrum Scale로 알려짐), DataPlow로부터 SFS, SGI로부터 CXFS, Quantum Corporation로부터 StorNext, 및 Versity로부터 ScoutFS가 있습니다.

Special file systems

 

일부 파일 시스템은 운영 시스템의 요소를 파일로 노출하여 파일 시스템 API를 통해 작동될 수 있도록 합니다. 이것은 유닉스-계열 운영 시스템에서 공통적이고, 다른 운영 시스템에서는 덜 일반적입니다. 예제는 다음을 포함합니다:

 

  • devfs, udev, TOPS-10는 I/O 장치 또는 가상-장치를 특수 파일로 노출합니다
  • configfs와 sysfs는 리눅스 커널 정보를 질의하고 구성하기 위해 사용될 수 있는 특수 파일을 노출합니다
  • procfs는 프로세스 정보를 특수 파일로 노출합니다

Minimal file system / audio-cassette storage

1970년대에 디스크와 디지털 테이프 장치는 일부 초기 마이크로컴퓨터 사용자에게는 너무 비쌌습니다. 공통적인 오디오 카세트 테이프를 사용하는 저렴한 기본 데이터 저장 시스템이 고안되었습니다.

시스템에서 데이터를 써야 할 때, 사용자는 카세트 레코더에서 "RECORD"를 누르고, 그런-다음 키보드에서 "RETURN"을 눌러 카세트 레코더가 녹음 중임을 시스템에 알리라는 알림을 받았습니다. 시스템은 시간 동기화를 제공하기 위해 소리를 쓰고, 그런-다음 접두사, 데이터, 체크섬, 및 접미사를 인코딩한 소리를 변조했습니다. 시스템에서 데이터를 읽어야 할 때, 사용자는 카세트 레코더에서 "PLAY"를 누르라는 지시를 받았습니다. 시스템은 테이프의 소리를 듣고 소리의 폭발이 동기화로 인식될 때까지 기다렸습니다. 그런 다음 시스템은 이후의 소리를 데이터로 해석했습니다. 데이터 읽기가 완료될 때, 시스템은 사용자에게 카세트 레코더에서 "STOP"을 누르라는 알림을 보냈습니다. 그것은 원시적이었지만, (대부분) 작동했습니다. 데이터는 순차적으로 저장되었으며, 보통 이름이 지정되지 않은 형식이었지만 일부 시스템 (예를 들어, Commodore PET 시리즈 컴퓨터)에서는 파일에 이름을 지정할 수 있었습니다. 여러 데이터의 집합을 쓰고 위치를 알아내기 위해 테이프를 빨리 감고 테이프 카운터를 관찰하여 테이프의 다음 데이터 영역의 대략적인 시작 위치를 찾을 수 있습니다. 사용자는 다음 데이터 영역의 재생을 시작할 적절한 지점을 찾기 위해 소리를 들어야 할 수도 있습니다. 일부 구현에는 데이터 사이에 들리는 소리가 포함되기도 했습니다.

Flat file systems

Not to be confused with Flat file database.

플랫 파일 시스템에서, 하위 디렉토리가 없습니다; 모든 파일에 대해 디렉토리 엔트리가 단일 디렉토리에 저장됩니다.

플로피 디스크 매체가 처음 출시되었을 때, 이 유형의 파일 시스템은 사용 가능한 데이터 공간이 비교적 적었기 때문에 적합했습니다. CP/M 기계는 플랫 파일 시스템을 특징으로 했으며, 여기서 파일은 16개 사용자 영역 중 하나에 할당될 수 있었고 일반적인 파일 작업은 모든 영역에서 작동하는 대신 한 영역에서 작동하도록 좁혀졌습니다.이들 사용자 영역은 파일과 결합된 특수 속성에 불과했습니다; 즉, 이들 각 영역에 대한 특정 할당량을 정의할 필요가 없었고 디스크에 여전히 사용 가능한 저장 공간이 있는 한 파일을 그룹에 추가할 수 있었습니다. 초기 Apple Macintosh도 플랫 파일 시스템인 Macintosh File System을 특징으로 했습니다. 파일 관리 프로그램 (Macintosh Finder)이 EMFS 꼭대기에 부분적으로 계층적 파일 시스템의 환상을 만들었다는 점에서 특이했습니다. 이 구조는 별도의 폴더에 있는 것처럼 보이더라도 모든 파일에 고유한 이름이 있어야 했습니다. IBM DOS/360과 OS/360은 디스크 팩 (볼륨)에 있는 모든 파일의 항목을 볼륨 목차 (VTOC)라는 팩 내의 디렉토리에 저장합니다.

간단한 플랫 파일 시스템은 파일 수가 늘어나면 사용하기 불편해지고, 데이터를 관련 파일 그룹으로 정리하기 어려워집니다.

플랫 파일 시스템 가족에 최근 추가된 것은 Amazon의 S3이며, 이는 원격 스토리지 서비스로, 사용자가 데이터를 저장하는 방식을 사용자 정의할 수 있도록 의도적으로 단순화되었습니다. 유일한 구성 요소는 버킷 (무제한 크기의 디스크 드라이브를 상상해보십시오)과 대상 (파일의 표준 개념과 비슷하지만 동일하지는 않음)입니다. 대상 이름에 거의 임의의 문자 ('/' 포함)를 사용할 수 있고 동일한 접두사를 기반으로 버킷 컨텐츠의 부분집합을 선택할 수 있으므로 고급 파일 관리가 가능합니다.

Implementations

운영 시스템은 전형적으로 하나 이상의 파일 시스템을 지원합니다. 때로는 OS와 파일 시스템이 너무 밀접하게 얽혀 있어서 독립적으로 설명하기 어려울 때가 있습니다.

OS는 전형적으로 사용자에게 파일 시스템 접근을 제공합니다. 종종 OS는 유닉스 쉘, Windows 명령 프롬프트와 PowerShell, 및 OpenVMS DCL과 같은 명령줄 인터페이스를 제공합니다. OS는 종종 MacOS Finder와 Windows 파일 탐색기와 같은 그래픽 사용자 인터페이스 파일 브라우저도 제공합니다.

Unix and Unix-like operating systems

유닉스-계열 운영 시스템은 가상 파일 시스템을 생성하여, 모든 장치의 모든 파일이 단일 계층 구조로 존재하는 것처럼 보이게 합니다. 즉, 이러한 시스템에서, 루트 디렉토리가 하나 있고, 시스템에 있는 모든 각 파일이 어딘가에 그 아래에 위치합니다. 유닉스-계열 시스템은 RAM 디스크나 네트워크 공유 자원을 루트 디렉토리로 사용할 수 있습니다.

유닉스-계열 시스템은 각 장치에 장치 이름을 할당하지만, 이는 해당 장치의 파일에 액세스하는 방법이 아닙니다. 대신, 또 다른 장치의 파일에 접근하기 위해, 운영 시스템에 먼저 해당 파일이 디렉토리 트리에서 어디에 나타나야 하는지 알려야 합니다. 이 과정은 파일 시스템 마운트라고 불립니다. 예를 들어, CD-ROM의 파일에 접근하기 위해, 운영 시스템에 "이 CD-ROM에서 파일 시스템을 가져와서 이런저런 디렉토리에 나타나게 하세요"라고 알려야 합니다. 운영 시스템에 제공된 디렉토리를 마운트 지점(mount point)이라고 하며, 예를 들어 /media일 수 있습니다. /media 디렉토리는 많은 유닉스 시스템에 존재하고 (파일 시스템 계층 표준에 지정된 대로) CD, DVD, USB 드라이브, 또는 플로피 디스크와 같은 이동식 미디어의 마운트 지점으로 특별히 사용하도록 설계되었습니다. 그것은 비어 있을 수도 있고, 개별 장치를 마운트하기 위한 하위 디렉토리를 포함할 수도 있습니다. 일반적으로 관리자 (즉, 루트 사용자)만 파일 시스템의 마운트를 승인할 수 있습니다.

유닉스-계열 운영 시스템은 종종 마운팅 과정을 지원하고 새로운 기능을 제공하는 소프트웨어와 도구를 포함합니다. 이들 전략 중 일부는 목적을 반영하여 "자동 마운팅"이라는 용어로 불립니다:

  • 많은 상황에서, 루트가 아닌 파일 시스템은 운영 시스템이 부팅되자마자 사용할 수 있어야 합니다. 따라서 모든 유닉스-계열 시스템은 부팅 시 파일 시스템을 마운트하는 기능을 제공합니다. 시스템 관리자는 구성 파일 fstab (Solaris에서는 vfstab)에서 이러한 파일 시스템을 정의하며, 여기에는 옵션과 마운트 지점도 표시됩니다.
  • 일부 상황에서, 부팅 시 특정 파일 시스템을 마운트할 필요가 없지만, 그 이후에는 사용하고 싶을 수도 있습니다. 유닉스-계열 시스템에 대해 유틸리티 중에는 필요에 따라 미리 정의된 파일 시스템을 마운트할 수 있는 유틸리티가 있습니다.
  • 이동식 미디어를 사용하면 물리적 연결 없이도 프로그램과 데이터를 기계 사이에 전송할 수 있습니다. 공통적인 예로는 USB 플래시 드라이브, CD-ROM, 및 DVD가 있습니다. 따라서 유틸리티가 개발되어 미디어의 존재와 가용성을 감지하고 그런-다음 사용자 개입 없이 해당 미디어를 마운트합니다.
  • 진보적인 유닉스-계열 시스템은 역시 슈퍼마운팅이라는 개념을 도입했습니다; 예를 들어 Linux supermount-ng project 참조하십시오. 예를 들어, 슈퍼마운트된 플로피 디스크는 시스템에서 물리적으로 제거될 수 있습니다. 통상적인 환경 아래에서, 디스크를 동기화한 다음 제거하기 전에 언마운트해야 합니다. 동기화가 이루어졌다면, 다른 디스크를 드라이브에 삽입할 수 있습니다. 시스템은 자동으로 디스크가 변경되었음을 알아차리고 새 미디어를 반영하도록 마운트 지점 내용을 업데이트합니다.
  • 자동 마운터는 마운트해야 할 디렉토리에 대한 참조가 있을 때 파일 시스템을 자동으로 마운트합니다. 이것은 보통 이동식 미디어에 적합할 미디어 삽입과 같은 이벤트에 의존하기보다는 네트워크 서버의 파일 시스템에 사용됩니다.

Linux

Linux는 수많은 파일 시스템을 지원하지만, 블록 장치의 시스템 디스크에 대한 공통적인 선택은 ext* 가족 (ext2, ext3, 및 ext4), XFS, JFS, 및 btrfs입니다. 플래시 변환 계층 (FTL) 또는 메모리 기술 장치 (MTD)가 없는 원시 플래시에 대해, 다른 것들 중에서 UBIFS, JFFS2, 및 YAFFS가 있습니다. SquashFS는 공통적인 압축 읽기 전용 파일 시스템입니다.

Solaris

이전 릴리스에서 Solaris는 부팅 가능하고 보충적인 파일 시스템에 대해 (저널링되지 않거나 로깅되지 않는) UFS를 기본값으로 사용했습니다. Solaris는 UFS를 기본값으로 사용하고, 지원하고, 확장했습니다.

시간이 지남에 따라 Veritas Software Corp. (저널링) VxFS, Sun Microsystems (클러스터링) QFS, Sun Microsystems (저널링) UFS, 및 Sun Microsystems (오픈 소스, 풀링 가능, 128비트 압축 가능, 및 오류 수정) ZFS 등 다른 파일 시스템에 대한 지원과 상당한 개선 사항이 추가되었습니다.

부팅 가능한 Veritas VxFS 작업을 허용하기 위해 Solaris에 커널 확장이 추가되었습니다. 로깅 또는 저널링은 Sun의 Solaris 7에서 UFS에 추가되었습니다. Solaris 10, Solaris Express, OpenSolaris, 및 Solaris 운영 시스템의 다른 오픈-소스 변형 릴리스는 나중에 부팅 가능한 ZFS를 지원했습니다.

논리적 볼륨 관리를 사용하면 중복성, 용량, 및/또는 처리량을 추가하는 목적으로 여러 장치에 걸쳐 파일 시스템을 확장할 수 있습니다. Solaris에서 레거시 환경은 Solaris Volume Manager (이전 명칭: Solstice DiskSuite)를 사용할 수 있습니다. 여러 운영 시스템 (Solaris 포함)은 Veritas Volume Manager를 사용할 수 있습니다. 현대 Solaris 기반 운영 시스템은 ZFS에서 가상 스토리지 풀을 활용하여 볼륨 관리에 대한 필요성을 능가합니다.

macOS

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

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

HFS Plus에는 세 가지 종류의 링크가 있습니다: 유닉스-스타일 하드 링크, 유닉스-스타일 심볼릭 링크, 및 별칭입니다. 별칭은 이동되거나 이름이 변경되더라도 원래 파일에 대한 링크를 유지하도록 설계되었습니다; 그것들은 파일 시스템 자체가 아니라 userland에서 파일 관리자 코드에 의해 해석됩니다.

2017년 6월 5일 Apple WWDC 이벤트에서 발표된 macOS 10.13 High Sierra는 솔리드-스테이드 드라이브에서 Apple 파일 시스템을 사용합니다.

macOS는 NeXTSTEP을 통해 BSD Unix Fast File System에서 파생된 UFS 파일 시스템도 지원했습니다. 어쨌든, Mac OS X Leopard부터, macOS는 더 이상 UFS 볼륨에 설치할 수 없었고, UFS 볼륨에 설치된 Leopard 이전 시스템은 Leopard로 업그레이드할 수 없습니다. 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 파일 시스템에 쓸 수 있지만, 비-자명한 시스템 설정을 변경한 후에만 가능합니다 (이를 자동화하는 타사 소프트웨어가 있습니다).

마지막으로, macOS는 Mac OS X Snow Leopard 10.6.5 버전부터 exFAT 파일 시스템의 읽기 및 쓰기를 지원합니다.

OS/2

OS/2 1.2는 High Performance File System (HPFS)을 도입했습니다. HPFS는 다양한 코드 페이지에서 대소문자를 혼합한 파일 이름, 긴 파일 이름 (255자), 디스크 공간의 보다 효율적인 사용, 디스크 볼륨에서 관련 항목을 각각 서로 가깝게 유지하는 아키텍처, 데이터의 조각화 감소, 익스텐트-기반 공간 할당, 디렉토리에 대해 B+ 트리 구조, 및 디스크의 중간에 위치한 루트 디렉토리를 지원하여 평균 접근 속도를 높였습니다. journaled filesystem (JFS)은 1999년에 출시되었습니다.

PC-BSD

PC-BSD는 FreeBSD의 데스크톱 버전으로, FreeNAS와 마찬가지로 FreeBSD의 ZFS 지원을 계승합니다. PC-BSD의 새로운 그래픽 설치 프로그램은 처음부터 쉽고 편리한 (GUI) 방식으로 Geli를 사용하여 ZFS 및 RAID-Z 풀 설치 및 디스크 암호화에서 / (root)를 처리할 수 있습니다. 현재 PC-BSD 9.0+ 'Isotope Edition'에는 ZFS 파일 시스템 버전 5와 ZFS 스토리지 풀 버전 28이 있습니다.

Plan 9

Bell Labs에서 Plan 9은 모든 것을 파일로 취급하고 모든 대상을 파일에 접근하는 것처럼 접근합니다 (즉, ioctl 또는 mmap이 없습니다): 네트워킹, 그래픽, 디버깅, 인증, 기능, 암호화, 및 기타 서비스는 파일 설명자의 I/O 작업을 통해 접근합니다. 9P 프로토콜은 지역 파일과 원격 파일의 차이를 제거합니다. Plan 9에서 파일 시스템은 비공개, 프로세스-별 이름공간의 도움으로 구성되어, 각 프로세스가 분산 시스템에서 자원을 제공하는 많은 파일 시스템을 다르게 볼 수 있도록 합니다.

Inferno 운영 시스템은 이들 개념을 Plan 9과 공유합니다.

Microsoft Windows

Windows는 FAT, NTFS, exFAT, Live File System, 및 ReFS 파일 시스템을 사용합니다 (이들 중 마지막은 Windows Server 2012, Windows Server 2016, Windows 8, Windows 8.1, 및 Windows 10에서만 지원되고 사용할 수 있습니다; Windows는 그것에서 부팅할 수 없습니다).

Windows는 사용자 수준에서 드라이브 문자 추상화를 사용하여 하나의 디스크 또는 파티션을 또 다른 디스크 또는 파티션과 구별합니다. 예를 들어, 경로 C:\WINDOWS는 문자 C로 표현된 파티션의 디렉토리 WINDOWS를 나타냅니다. 드라이브 C:는 공통적으로 Windows가 보통 설치되고 부팅되는 주요 하드 디스크 드라이브 파티션에 가장 많이 사용됩니다. 이 "전통"은 너무 굳건히 자리 잡았기 때문에 많은 응용 프로그램에서 운영 시스템이 설치된 드라이브가 C라는 가정을 하는 버그가 있습니다. 드라이브 문자 사용과 주요 하드 디스크 드라이브 파티션의 드라이브 문자로 "C"를 사용하는 전통은 MS-DOS에서 유래되었으며, 여기서 문자 A와 B는 최대 2개의 플로피 디스크 드라이브에 예약되었습니다. 이는 차례로 1970년대에서 CP/M으로부터 파생되었고, 궁극적으로는 1967년 IBM의 CP/CMS에서 파생되었습니다.

FAT

Main article: File Allocation Table

FAT 파일 시스템의 가족은 Windows의 모든 버전과 MS-DOS/PC DOS, OS/2, 및 DR-DOS를 포함한 거의 모든 개인용 컴퓨터 운영 시스템에서 지원됩니다. (PC DOS는 MS-DOS의 OEM 버전이고, MS-DOS는 원래 SCP의 86-DOS를 기반으로 했습니다. DR-DOS는 CP/M-86의 후속 제품인 Digital Research의 Concurrent DOS를 기반으로 했습니다.) 따라서 FAT 파일 시스템은 거의 임의의 유형과 연령대의 컴퓨터와 장치 사이의 범용 교환 형식으로 적합합니다.

FAT 파일 시스템은 Standalone Disk BASIC의 (호환되지 않는) 8-비트 FAT 전임자와 단명한 MDOS/MIDAS 프로젝트에서 유래되었습니다.

수년에 걸쳐, 파일 시스템은 FAT12에서 FAT16와 FAT32로 확장되었습니다. 하위 디렉터리, 코드 페이지 지원, 확장된 속성, 및 긴 파일 이름을 포함한 다양한 기능이 파일 시스템에 추가되었습니다. Digital Research와 같은 타사는 삭제 추적에 대한 선택적 지원과 볼륨/디렉토리/파일-기반 다중 사용자 보안 체계를 통합하여 파일과 디렉터리 암호 및 읽기/쓰기/실행/삭제 접근 권한과 같은 권한을 지원합니다. 이들 확장자 대부분은 Windows에서 지원되지 않습니다.

FAT12와 FAT16 파일 시스템은 파일 시스템의 루트 디렉토리에 들어갈 수 있는 엔트리의 개수에 제한이 있었고 FAT로 포맷된 디스크나 파티션의 최대 크기에도 제한이 있었습니다.

FAT32는 파일 크기 제안이 4GB에 가깝다는 점을 제외하고 FAT12와 FAT16의 제한 사항을 해결하지만, 그것은 NTFS에 비해서는 여전히 제한적입니다.

FAT12, FAT16, 및 FAT32도 파일 이름에 대해 8자 제한을 가지고 확장자 (예를 들어, .exe)에 대해 3자로 제한을 가집니다. 이를 공통적으로 8.3 파일 이름 제한이라고 합니다. Windows 95와 Windows NT 3.5에 도입된 FAT12, FAT16 및 FAT32의 선택적 확장자인 VFAT를 사용하면 긴 파일 이름 (LFN)을 이전 버전과 호환되는 방식으로 FAT 파일 시스템에 저장할 수 있습니다.

NTFS

Main article: NTFS

1993년 Windows NT 운영 시스템과 함께 도입된 NTFS는 ACL-기반 권한 제어를 허용했습니다. NTFS에서 지원하는 다른 기능으로는 하드 링크, 다중 파일 스트림, 속성 인덱싱, 할당량 추적, 스파스 파일, 암호화, 압축, 및 재분석 지점 (다른 파일 시스템에 대한 마운트-지점으로 작동하는 디렉터리, 심볼릭 링크, 접합부, 원격 저장소 링크)이 있습니다.

exFAT

Main article: exFAT

exFAT는 파일 시스템 오버헤드와 관련하여 NTFS에 비해 특정한 장점을 가지고 있습니다.

exFAT는 FAT12, FAT16, 또는 FAT32와 같은 FAT 파일 시스템과 이전 버전으로 호환되지 않습니다. 그 파일 시스템은 Windows XP, Windows Server 2003, Windows Vista, Windows 2008, Windows 7, Windows 8, Windows 8.1, Windows 10, 및 Windows 11과 같은 최신 Windows 시스템에서 지원됩니다.

exFAT는 버전 10.6.5 (Snow Leopard)부터 macOS에서 지원됩니다. exFAT 지원을 구현하려면 라이선스가 필요하므로 다른 운영 시스템에서는 지원이 부족합니다. exFAT는 4GB보다 큰 파일을 보관할 수 있는 macOS와 Windows에서 모두 완벽하게 지원되는 유일한 파일 시스템입니다.

OpenVMS

Main article: Files-11

MVS

VSAM의 도입 전에, OS/360 시스템은 하이브리드 파일 시스템을 구현했습니다. 그 시스템은 이동식 디스크 팩을 쉽게 지원하도록 설계되었으므로, 한 디스크 (IBM 용어로는 볼륨)에 있는 모든 파일과 관련된 정보는 볼륨 목차 (VTOC)라는 플랫 시스템 파일에 해당 디스크에 저장됩니다. VTOC는 파일에 대해 모든 메타데이터를 저장합니다. 나중에, 시스템 카탈로그의 도입과 함께 계층적 디렉토리 구조가 적용되었으며, 이는 선택적으로 상주 및 이동식 볼륨에 있는 파일 (데이터집합)을 카탈로그화할 수 있습니다. 카탈로그에는 데이터집합을 특정 볼륨과 연결하는 정보만 포함됩니다. 만약 사용자가 오프라인 볼륨의 데이터집합에 대한 접근을 요청하고, 그것들이 적절한 권한을 가지면, 시스템은 필요한 볼륨을 마운트하려고 시도합니다. 카탈로그화된 데이터집합과 카탈로그화되지 않은 데이터집합은 OPEN 요청에 필요한 볼륨 ID가 제공되면, 카탈로그를 우회함으로써 VTOC에서 정보를 사용하여 계속 접근할 수 있습니다. 그 후 VTOC가 인덱싱되어 접근 속도가 빨라졌습니다.

Conversational Monitor System

Main article: CMS file system

VM/370의 IBM Conversational Monitor System (CMS) 구성 요소는 각 가상 디스크 (미니디스크)에 대해 별도의 플랫 파일 시스템을 사용합니다. 파일 데이터와 제어 정보는 분산되어 섞여 있습니다. 앵커는 Master File Directory (MFD)라는 레코드로, 항상 디스크의 네 번째 블록에 위치합니다. 원래 CMS는 고정된-길이 800-바이트 블록을 사용했지만, 이후 버전에서는 최대 4K까지 더 큰 크기의 블록을 사용했습니다. 데이터 레코드에 접근하려면 두 단계의 간접 참조가 필요하며, 여기서 파일의 디렉토리 항목 (File Status Table (FST) 항목이라고 함)은 개별 레코드의 주소 목록이 포함된 블록을 가리킵니다.

AS/400 file system

AS/400 및 후속 제품의 데이터는 단일-수준 저장소의 시스템 가상 주소 공간에 매핑된 시스템 객체로 구성됩니다. 다른 파일 시스템에서 발견되는 디렉토리와 파일을 포함하여 많은 유형의 대상이 정의됩니다. 파일 대상은, 다른 유형의 대상과 함께, 통합된 관계형 데이터베이스에 대한 AS/400의 지원의 기반을 형성합니다.

Other file systems

  • Prospero 파일 시스템은 가상 시스템 모델을 기반으로 하는 파일 시스템입니다. 이 시스템은 남부 캘리포니아 대학교 정보 과학 연구소의 B. Clifford Neuman이 만들었습니다.
  • RSRE FLEX file system - ALGOL 68로 작성됨
  • Michigan Terminal System (MTS)의 파일 시스템은 다음과 같은 이유로 흥미롭습니다: (i) 그것은 레코드 길이와 줄 번호가 파일에서 각 레코드와 메타데이터로 결합된 "줄 파일"을 제공하며, 줄은 같은 길이 레코드 또는 다른 길이 레코드로 추가, 교체, 업데이트되고, 전체 파일을 읽고 다시 쓸 필요 없이 파일에서 어느 곳에서나 삭제될 수 있습니다; (ii) 프로그램 키를 사용하여 파일은 사용자와 그룹 외에도 명령과 프로그램에 공유되거나 허용될 수 있습니다; 그리고 (iii) 파일의 데이터와 메타데이터를 모두 보호하는 포괄적인 파일 잠금 메커니즘이 있습니다.
  • TempleOS는 Terry A. Davis가 만든 파일 시스템, ReadSea를 사용합니다.

Limitations

Design limitations

파일 시스템은 저장할 수 있는 데이터 용량을 제한합니다 – 일반적으로 파일 시스템이 설계되고 가까운 미래에 저장될 것으로 예상되는 당시의 저장 장치의 일반적인 크기에 따라 결정됩니다.

저장 용량이 거의 지수적으로 증가했기 때문에 (무어의 법칙 참조), 새로운 저장 장치는 종종 도입 후 불과 몇 년 만에 기존 파일 시스템 한계를 초과합니다. 이를 위해서는 용량이 계속 증가하는 새로운 파일 시스템이 필요합니다.

용량이 클수록, 기능에 대한 필요성과 따라서 복잡성도 커집니다. 파일 시스템 복잡성은 전형적으로 사용 가능한 저장 용량에 비례하여 달라집니다. 용량 문제를 제외하면, 50KB~512KB의 저장 용량을 갖춘 1980년대 초반 가정용 컴퓨터의 파일 시스템은 수백 기가바이트의 용량을 갖춘 최신 저장 시스템에 적합한 선택이 아닙니다. 마찬가지로, 최신 파일 시스템은 이들 초기 시스템에 적합한 선택이 아닌데, 왜냐하면 최신 파일 시스템 구조의 복잡성으로 인해 초기 저장 시스템의 제한된 용량이 빠르게 소모되기 때문입니다.

Converting the type of a file system

파일들이 현재 존재하는 것과 다른 파일 시스템에 파일을 두는 것이 유리하거나 필요할 수 있습니다. 그 이유에는 현재 파일 시스템의 한계를 넘어 공간 요구 사항을 늘려야 할 필요성이 있습니다. 경로의 깊이를 파일 시스템의 제한을 넘어 늘려야 할 수도 있습니다. 성능이나 안정성을 고려해야 할 수도 있습니다. 기존 파일 시스템을 지원하지 않는 다른 운영 시스템에 대한 접근을 제공하는 것도 또 다른 이유입니다.

In-place conversion

어떤 경우에는 변환을 그 자리에서 수행할 수 있지만, 파일 시스템을 마이그레이션하는 것이 더 보수적인데, 왜냐하면 그것이 데이터 복사본을 생성해야 하고 권장되기 때문입니다. Windows에서 FAT와 FAT32 파일 시스템은 convert.exe 유틸리티를 통해 NTFS로 변환할 수 있지만, 그 반대로는 변환할 수 없습니다. Linux에서, ext2는 ext3으로 변환할 수 있고 (그리고 반대로 변환할 수 있음), ext3은 ext4로 변환할 수 있지만 (그 반대로는 변환할 수 없음), ext3과 ext4는 모두 btrfs로 변환할 수 있고, 실행 취소 정보가 삭제될 때까지 다시 변환할 수 있습니다. 이들 변환은 파일 데이터 자체에 같은 형식을 사용하고, 어떤 경우에는 스파스 파일 지원을 사용하여 메타데이터를 빈 공간으로 다시 배치하기 때문에 가능합니다.

Migrating to a different file system

마이그레이션은 더 빠를 수 있지만 추가 공간이 필요하다는 단점이 있습니다. 가장 좋은 경우는 최종 파일 시스템을 포함할 미디어에 사용되지 않은 공간이 있는 경우입니다.

예를 들어, FAT32 파일 시스템을 ext2 파일 시스템으로 마이그레이션하기 위해, 새 ext2 파일 시스템을 만듭니다. 그런-다음 FAT32 파일 시스템의 데이터를 ext2로 복사하고 이전 파일 시스템을 삭제합니다.

새 파일 시스템을 만들 때까지 원래 파일 시스템을 유지할 공간이 충분하지 않은 경우 대안은 작업 영역 (예를 들어, 이동식 미디어)을 사용하는 것입니다. 시간이 더 오래 걸리지만 백업을 생성하는 이점이 있습니다.

Long file paths and long file names

계층적 파일 시스템에서, 파일은 해당 파일을 포함하는 디렉토리의 분기 목록인 경로(path)를 수단으로 접근됩니다. 파일 시스템마다 경로 깊이에 대한 제한이 다릅니다. 파일 시스템에는 개별 파일 이름의 길이에도 제한이 있습니다.

긴 이름을 가진 파일이나 상당한 깊이의 경로에 있는 파일을 한 파일 시스템에서 또 다른 파일 시스템으로 복사하는 것은 바람직하지 않은 결과를 초래할 수 있습니다. 이는 복사를 수행하는 유틸리티가 불일치를 처리하는 방법에 따라 달라집니다.

Sources

Further reading

Books

Online

 

 

 

 

 

 

관련글

티스토리툴바