파일 시스템

운영 체제
공통 기능
공정관리 인터럽트 메모리 관리 파일 시스템 장치 드라이버 네트워킹 보안. 입출력
v t

컴퓨팅에서 파일 시스템 또는 파일 시스템(종종 FS 또는 FS로 약칭됨)은 파일 구성 및 액세스를 제어합니다. 로컬 파일 시스템은 동일한 컴퓨터에서 실행되는 응용 프로그램을 서비스하는 운영 체제의 기능입니다.^[1][2] 분산 파일 시스템은 네트워크로 연결된 컴퓨터 간에 파일 액세스를 제공하는 프로토콜입니다.

파일 시스템은 애플리케이션이 대용량 스토리지를 공유할 수 있는 데이터 스토리지 서비스를 제공합니다. 파일 시스템이 없으면 애플리케이션이 스토리지에 호환되지 않는 방식으로 액세스하여 리소스 경합, 데이터 손상 및 데이터 손실을 초래할 수 있습니다.

다양한 구조 및 기능과 속도, 유연성, 보안, 크기 등 다양한 결과 특성을 가진 파일 시스템 설계 및 구현이 많이 있습니다.

파일 시스템은 하드 디스크 드라이브(HDD), 솔리드 스테이트 드라이브(SSD), 자기 테이프 및 광학 디스크를 포함한 다양한 유형의 스토리지 장치를 위해 개발되었습니다.^[3]

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

가상 파일 시스템은 요청에 따라 계산되거나 가상 파일(procfs 및 sysfs 참조) 또는 다른 백업 저장소로 매핑되는 파일에 대한 액세스를 제공합니다.

어원

1900년부터 컴퓨터가 등장하기 전까지 파일 시스템이라는 용어를 사용하여 종이 문서를 정리, 저장 및 검색하는 방법을 설명했습니다.^[4] 1961년까지 파일 시스템이라는 용어는 원래의 의미와 함께 컴퓨터화된 파일링에 적용되었습니다.^[5] 1964년까지, 그것은 일반적으로 사용되었습니다.^[6]

건축

로컬 파일 시스템의 아키텍처는 특정 파일 시스템 설계가 실제로 개념을 분리하지 않더라도 추상화 계층으로 설명할 수 있습니다.^[7]

논리 파일 시스템은 사용자 애플리케이션과의 상호 작용을 담당합니다. 하위 계층에 작업을 위임하는 열림, 닫힘, 읽기 및 쓰기를 포함한 파일 작업을 위한 응용 프로그램 인터페이스(API)를 제공합니다. 논리 파일 시스템은 열린 파일 테이블 항목과 프로세스별 파일 설명자를 관리합니다.^[8] 파일 액세스, 디렉토리 작업, 보안 및 보호 기능을 제공합니다.^[7]

옵션 계층인 가상 파일 시스템은 물리적 파일 시스템의 여러 동시 인스턴스를 지원하며, 이들 각각을 파일 시스템 구현이라고 합니다.^[8]

물리적 파일 시스템은 저장 장치(예: 디스크)에 대한 물리적 액세스를 제공하는 계층입니다. 읽거나 쓰는 물리적 블록을 처리합니다. 버퍼링 및 메모리 관리를 처리하며 저장 매체의 특정 위치에 블록의 물리적 배치를 담당합니다. 물리적 파일 시스템은 장치 드라이버 또는 채널과 상호 작용하여 저장 장치를 구동합니다.^[7]

특성

저장공간 구성

로컬 파일 시스템은 저장 공간을 관리하여 안정성과 효율성 수준을 제공합니다. 일반적으로 스토리지 디바이스 공간을 세분화된 방식(일반적으로 여러 물리적 유닛(즉, 바이트)으로 할당합니다. 예를 들어, 1980년대 초의 애플 도스에서는 140 킬로바이트 플로피 디스크의 256 바이트 섹터가 트랙/섹터 맵을 사용했습니다.^{[citation needed]}

세분화된 특성으로 인해 각 파일에 대해 사용되지 않는 공간(때로는 슬랙 공간이라고도 함)이 발생하며, 이 경우 희귀한 크기가 세분화된 할당의 배수인 파일을 제외하고는 사용되지 않습니다.^[9] 512바이트 할당의 경우 평균 사용되지 않은 공간은 256바이트입니다. 64KB 클러스터의 경우 평균 미사용 공간은 32KB입니다.

일반적으로 할당 단위 크기는 스토리지를 구성할 때 설정됩니다. 저장된 파일에 비해 상대적으로 작은 크기를 선택하면 과도한 액세스 오버헤드가 발생합니다. 상대적으로 큰 사이즈를 선택하면 사용하지 않는 공간이 과도하게 발생합니다. 스토리지에 있을 것으로 예상되는 평균 파일 크기를 기반으로 할당 크기를 선택하면 사용할 수 없는 공간이 최소화됩니다.

운영

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

파일 시스템이 파일을 생성하면 데이터를 위한 공간을 할당합니다. 일부 파일 시스템은 파일이 증가함에 따라 초기 공간 할당 및 이후 증분 할당을 허용하거나 지정해야 합니다.

파일을 삭제하기 위해 파일 시스템은 파일의 공간이 비어 있으며 다른 파일에 사용할 수 있음을 기록합니다.

단편화

파일 시스템이 파일을 생성, 수정 및 삭제함에 따라 스토리지가 파편화되는 경향이 있습니다. 파일과 파일 사이의 사용되지 않은 공간은 연속되지 않은 할당 블록을 차지합니다.

콘텐츠를 저장하는 데 필요한 공간을 연속된 블록에 할당할 수 없는 경우 파일이 조각난 상태가 됩니다. 파일이 삭제되면 사용 가능한 공간이 조각난 상태가 됩니다.

파일명

파일 이름 또는 파일 이름은 파일을 나타냅니다. 이름은 응용 프로그램이 특정 이름에 대해 정확히 하나의 파일을 참조할 수 있도록 고유합니다. 파일 시스템이 디렉토리를 지원하는 경우 일반적으로 각 디렉토리의 컨텍스트 내에서 파일 이름 고유성이 적용됩니다. 즉, 저장소에는 이름이 있는 여러 개의 파일이 포함될 수 있지만 동일한 디렉터리에는 포함되지 않습니다.

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

일부 파일 시스템은 대소문자 구분으로 파일 이름을 일치시키고 다른 파일 시스템은 대소문자 구분으로 일치시킵니다. 예를 들어, 그 이름들은 MYFILE 그리고. myfile 대소문자를 구분하지 않는 경우에는 동일한 파일을 일치시키지만 대소문자를 구분하는 경우에는 다른 파일을 일치시킵니다.

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

디렉토리

파일 시스템은 일반적으로 파일을 그룹으로 분리하는 폴더라고도 하는 디렉토리로 구성하는 것을 지원합니다.

이는 유닉스 계열 파일 시스템에서 파일 이름을 목차의 인덱스나 아이노드와 연관시켜 구현할 수 있습니다.

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

디렉터리의 임의 계층을 지원하는 최초의 파일 시스템은 멀틱스 운영 체제에서 사용되었습니다.^[11] 유닉스 계열 시스템의 네이티브 파일 시스템은 또한 애플의 계층 파일 시스템과 그 후속 파일 시스템인 클래식 맥 OS의 HFS+, MS-DOS 2.0 이상 버전의 FAT 파일 시스템, 마이크로소프트 윈도우의 NTFS 파일 시스템과 같이 임의의 디렉토리 계층을 지원합니다. 그리고 OpenVMS의 파일-11 파일 시스템의 ODS-2(On-Disk Structure-2) 및 상위 레벨.

메타데이터

파일 시스템은 파일 내용 외에도 다음을 포함할 수 있지만 이에 제한되지 않는 관련 메타데이터도 관리합니다.

• 이름.
• 할당된 블록 수 또는 바이트 카운트로 저장할 수 있는 크기
• 생성된 경우, 마지막으로 액세스한 경우, 마지막으로 백업한 경우
• 소유자 사용자 및 그룹
• 접근 권한
• 파일의 읽기 전용 여부, 실행 파일 등과 같은 파일 속성.
• 장치 유형(예: 블록, 문자, 소켓, 하위 디렉토리 등)

파일 시스템은 파일의 내용과 별개로 연관된 메타데이터를 저장합니다.

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

대부분의 파일 시스템은 또한 어느 하나의 특정 파일과 연관되지 않은 메타데이터를 저장합니다. 이러한 메타데이터에는 사용되지 않는 영역(사용 가능한 공간 비트맵, 블록 가용성 맵) 및 불량 섹터에 대한 정보가 포함됩니다. 할당 그룹에 대한 이러한 정보는 할당 그룹 자체 내부에 저장되는 경우가 많습니다.

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

일부 파일 시스템에서는 서로 다른 데이터 컬렉션을 하나의 파일 이름과 연결할 수 있습니다. 이러한 별도의 컬렉션을 스트림 또는 포크라고 할 수 있습니다. Apple은 오랫동안 Macintosh에서 포크 파일 시스템을 사용해 왔으며 Microsoft는 NTFS에서 스트림을 지원합니다. 일부 파일 시스템은 하나의 파일 이름으로 파일의 여러 과거 수정 사항을 유지하며, 파일 이름 자체는 가장 최근 버전을 검색하는 반면, 이전에 저장된 버전은 "filename;4" 또는 "filename(-4)"과 같은 특별한 이름 지정 규칙을 사용하여 액세스하여 4개의 저장 전 버전에 액세스할 수 있습니다.

파일 시스템 비교 참조#어떤 파일 시스템이 어떤 종류의 메타데이터를 지원하는지에 대한 세부 정보를 나타내는 메타데이터입니다.

쿼터

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

추상적 사용자 인터페이스로서의 파일 시스템

어떤 경우에는 파일 시스템이 저장 장치를 사용하지 않을 수도 있지만, 저장된 데이터든 동적으로 생성된 데이터(예: procfs)에 대한 액세스를 구성하고 표현하는 데 사용될 수 있습니다.

유틸리티

파일 시스템에는 파일 시스템의 인스턴스를 초기화, 변경 및 제거하는 유틸리티가 포함됩니다. 파일 시스템에 할당된 공간을 확장하거나 잘라내는 기능도 있습니다.

디렉토리 유틸리티는 디렉토리 항목을 만들고, 이름을 바꾸고, 삭제하는 데 사용될 수 있으며, 이 항목은 덴트리(싱글: 덴트리)라고도 하며,^[12] 디렉토리와 관련된 메타데이터를 변경하는 데 사용될 수 있습니다. 디렉터리 유틸리티에는 디렉터리에 대한 추가 링크(유닉스의 하드 링크), 상위 링크(유닉스 계열 운영 체제의 경우 ".")의 이름을 바꾸는 기능,^{[clarification needed]} 파일에 대한 양방향 링크를 만드는 기능도 포함될 수 있습니다.

파일 유틸리티는 파일을 생성, 나열, 복사, 이동 및 삭제하고 메타데이터를 변경합니다. 데이터를 잘라낼 수도 있고, 공간 할당을 잘라내거나 확장할 수도 있으며, 제자리에 파일을 추가, 이동 및 수정할 수도 있습니다. 파일 시스템의 기본 구조에 따라 파일 처음부터 파일을 준비하거나 잘라내거나 파일 중간에 항목을 삽입하거나 파일에서 항목을 삭제하는 메커니즘을 제공할 수 있습니다. 파일 시스템에서 삭제되지 않은 기능을 제공하는 경우 삭제된 파일의 공간을 확보하는 유틸리티도 이 범주에 속합니다.

일부 파일 시스템은 최소한의 활동 시간에 이러한 기능을 수행할 수 있는 유틸리티를 제공하여 사용 가능한 공간 재구성, 사용 가능한 공간의 안전한 삭제, 계층 구조의 재구축 등의 작업을 연기합니다. 파일 시스템 조각 모음 유틸리티가 그 예입니다.

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

접근 제한 및 허용

파일 시스템에서 데이터에 대한 액세스를 제어하기 위해 사용하는 몇 가지 메커니즘이 있습니다. 일반적으로 사용자 또는 사용자 그룹이 파일을 읽거나 수정하는 것을 방지하는 것이 목적입니다. 또 다른 이유는 데이터가 통제된 방식으로 수정되어 특정 프로그램에 대한 액세스가 제한될 수 있도록 하기 위함입니다. 파일 또는 다른 곳의 메타데이터에 저장된 암호와 권한 비트, 액세스 제어 목록 또는 기능 형태의 파일 권한 등이 그 예입니다. 파일 시스템 유틸리티가 미디어 수준에서 데이터에 액세스하여 구조를 재구성하고 효율적인 백업을 제공해야 한다는 것은 일반적으로 이러한 유틸리티가 예의 바른 사용자에게만 효과적일 뿐 침입자에게는 효과적이지 않다는 것을 의미합니다.

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

무결성 유지

파일 시스템의 중요한 책임 중 하나는 파일 시스템에 액세스하는 프로그램의 작업에 관계없이 보조 스토리지의 파일 시스템 구조가 일관되게 유지되도록 하는 것입니다. 여기에는 파일 시스템을 수정하는 프로그램이 비정상적으로 종료되거나 파일 시스템에 작업을 완료했음을 알리는 것을 소홀히 할 경우 수행되는 작업이 포함됩니다. 여기에는 메타데이터 업데이트, 디렉토리 항목 및 버퍼링되었지만 물리적 저장 매체에서 아직 업데이트되지 않은 모든 데이터를 처리하는 것이 포함될 수 있습니다.

파일 시스템이 처리해야 하는 다른 장애에는 미디어 장애 또는 원격 시스템에 대한 연결 끊김이 포함됩니다.

운영 체제에 장애가 발생하거나 "소프트" 전원 장애가 발생할 경우 개별 프로그램에 장애가 발생할 때와 마찬가지로 파일 시스템의 특수 루틴을 호출해야 합니다.

파일 시스템은 손상된 구조물도 수정할 수 있어야 합니다. OS가 파일 시스템에 알리지 못한 운영 체제 장애, 전원 장애 또는 재설정으로 인해 발생할 수 있습니다.

또한 파일 시스템은 시스템 문제뿐만 아니라 특정 파일 또는 디렉터리의 문제를 분석할 수 있도록 이벤트를 기록해야 합니다.

사용자 데이터

파일 시스템의 가장 중요한 목적은 사용자 데이터를 관리하는 것입니다. 여기에는 데이터 저장, 검색 및 업데이트가 포함됩니다.

일부 파일 시스템은 저장을 위한 데이터를 미디어에 효율적인 방식으로 수집 및 저장되는 바이트 스트림으로 받아들입니다. 프로그램이 데이터를 검색할 때 메모리 버퍼의 크기를 지정하고 파일 시스템이 미디어에서 버퍼로 데이터를 전송합니다. 런타임 라이브러리 루틴은 때때로 사용자 프로그램이 길이를 지정하는 라이브러리 호출에 기초하여 레코드를 정의하도록 허용할 수 있습니다. 사용자 프로그램이 데이터를 읽을 때 라이브러리는 파일 시스템을 통해 데이터를 검색하고 레코드를 반환합니다.

일부 파일 시스템에서는 모든 쓰기 및 읽기에 사용되는 고정 레코드 길이를 지정할 수 있습니다. 이렇게^th 하면 레코드를 쉽게 찾을 수 있을 뿐만 아니라 레코드를 업데이트할 수 있습니다.

키라고도 하는 각 레코드에 대한 식별 기능을 통해 보다 정교한 파일 시스템을 구축할 수 있습니다. 사용자 프로그램은 위치에 관계없이 기록을 읽고 쓰고 업데이트할 수 있습니다. 이를 위해서는 일반적으로 키 블록과 데이터 블록을 분리하는 미디어 블록의 복잡한 관리가 필요합니다. 기록을 찾기 위한 피라미드 구조로 매우 효율적인 알고리즘을 개발할 수 있습니다.^[13]

파일 시스템 사용

유틸리티, 언어별 런타임 라이브러리 및 사용자 프로그램은 파일 시스템 API를 사용하여 파일 시스템의 요청을 수행합니다. 여기에는 데이터 전송, 포지셔닝, 메타데이터 업데이트, 디렉토리 관리, 액세스 사양 관리 및 제거가 포함됩니다.

단일 시스템 내의 여러 파일 시스템

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

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

클라우드 시스템에서 주로 사용되는 세 번째 접근 방식은 "디스크 이미지"를 사용하여 동일한 속성을 가지든 아니든 다른 (호스트) 파일 시스템 내에 추가 파일 시스템을 파일로 저장하는 것입니다. 일반적인 예는 가상화입니다. 한 사용자가 자신의 프로덕션 윈도우즈 환경(NTFS 사용)에서 가상 시스템에서 ext4 파일 시스템을 사용하여 실험적인 리눅스 배포를 실행할 수 있습니다. ext4 파일 시스템은 NTFS 호스트 파일 시스템에서 파일(또는 하이퍼바이저 및 설정에 따라 여러 파일)로 취급되는 디스크 이미지에 있습니다.

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

설계상의 한계

모든 파일 시스템에는 해당 시스템 내에서 최대 저장 가능한 데이터 용량을 정의하는 몇 가지 기능 제한이 있습니다. 이러한 기능적 한계는 현재 스토리지 시스템의 규모와 향후 스토리지 시스템의 규모를 기준으로 설계자가 가장 잘 예측할 수 있는 노력입니다. 디스크 스토리지는 기하급수적인 속도로 계속 증가해 왔기 때문에(무어의 법칙 참조), 몇 년이 지난 지금, 파일 시스템은 컴퓨터 사용자가 계속해서 더 큰 용량을 가진 새로운 시스템으로 반복적으로 이동해야 하는 설계상의 한계에 도달했습니다.

파일 시스템 복잡성은 일반적으로 사용 가능한 스토리지 용량에 비례하여 달라집니다. 저장 용량이 50KB에서 512KB인 1980년대 초 가정용 컴퓨터의 파일 시스템은 수백 기가바이트에 달하는 최신 스토리지 시스템에서 합리적인 선택이 되지 못할 것입니다. 마찬가지로, 현대 파일 시스템 구조의 복잡성은 초기 스토리지 시스템의 매우 제한된 용량을 빠르게 소비하거나 초과할 수 있기 때문에 현대 파일 시스템은 이러한 초기 시스템에 합리적인 선택이 아닙니다.

종류들

디스크 파일 시스템

디스크 파일 시스템은 디스크 저장 매체가 짧은 시간 내에 임의로 데이터 주소를 지정하는 기능을 이용합니다. 추가적으로 고려해야 할 사항으로는 처음에 요청한 데이터 팔로우에 대한 액세스 속도와 다음 데이터도 요청할 수 있다는 예상이 있습니다. 따라서 데이터의 순차적 위치와 관계없이 디스크의 다양한 데이터에 여러 사용자(또는 프로세스)가 액세스할 수 있습니다. 예를 들어 FAT(FAT12, FAT16, FAT32), exFAT, NTFS, ReFS, HFS 및 HFS+, HPFS, APFS, UFS, ext2, ext3, ext4, XFS, btrfs, 파일-11, Veritas 파일 시스템, VMFS, ZFS, ReiserFS, NSS 및 ScoutFS가 있습니다. 일부 디스크 파일 시스템은 문서철 파일 시스템 또는 버전 파일 시스템입니다.

광학 디스크

ISO 9660 및 범용 디스크 포맷(UDF)은 콤팩트 디스크, DVD 및 블루레이 디스크를 대상으로 하는 두 가지 일반적인 포맷입니다. 마운트 레이니어(Mount Rainier)는 리눅스 커널 2.6 시리즈부터 지원되는 UDF의 확장판으로, DVD로의 재작성을 용이하게 해줍니다.

플래시 파일 시스템

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

테이프 파일 시스템

테이프 파일 시스템은 파일을 테이프에 저장하도록 설계된 파일 시스템 및 테이프 형식입니다. 마그네틱 테이프는 디스크보다 랜덤 데이터 액세스 시간이 훨씬 긴 순차적 저장 매체이므로 범용 파일 시스템을 생성하고 효율적으로 관리하는 데 어려움이 있습니다.

디스크 파일 시스템에는 일반적으로 마스터 파일 디렉토리와 사용된 데이터 영역 및 사용 가능한 데이터 영역의 지도가 있습니다. 파일을 추가하거나 변경하거나 제거하려면 디렉토리와 사용/사용되지 않은 지도를 업데이트해야 합니다. 데이터 영역에 대한 랜덤 액세스는 밀리초 단위로 측정되므로 이 시스템은 디스크에 대해 잘 작동합니다.

테이프는 매우 긴 미디어 릴을 감거나 풀기 위해 선형 운동을 필요로 합니다. 이 테이프 모션은 테이프의 한쪽 끝에서 다른 쪽 끝으로 읽기/쓰기 헤드를 이동하는 데 몇 초에서 몇 분 정도 걸릴 수 있습니다.

따라서 마스터 파일 디렉토리 및 사용 맵은 테이프를 사용하면 매우 느리고 비효율적일 수 있습니다. 쓰기에는 일반적으로 블록 사용 맵을 읽고 쓰기에 필요한 여유 블록을 찾고, 데이터를 추가하기 위해 사용 맵과 디렉터리를 업데이트한 다음 테이프를 전진시켜 올바른 위치에 데이터를 쓰는 작업이 포함됩니다. 각 추가 파일 쓰기에는 지도 및 디렉터리를 업데이트하고 데이터를 작성해야 하며, 각 파일에 대해 몇 초가 걸릴 수 있습니다.

대신 테이프 파일 시스템을 사용하면 파일 디렉토리를 데이터와 혼합된 테이프 전체에 분산할 수 있으며, 이를 스트리밍이라고 합니다. 따라서 새로운 데이터를 작성하는 데 시간이 많이 걸리고 반복되는 테이프 동작이 필요하지 않습니다.

그러나 이 설계의 부작용은 테이프의 파일 디렉토리를 읽으려면 일반적으로 흩어져 있는 모든 디렉토리 항목을 읽기 위해 전체 테이프를 스캔해야 한다는 것입니다. 테이프 저장소와 함께 작동하는 대부분의 데이터 보관 소프트웨어는 테이프 카탈로그의 로컬 복사본을 디스크 파일 시스템에 저장하므로 테이프 미디어를 다시 검색하지 않고도 테이프에 파일을 추가할 수 있습니다. 로컬 테이프 카탈로그 복사본은 지정된 기간 동안 사용하지 않으면 일반적으로 폐기되며, 이 시점에서 나중에 사용하려면 테이프를 다시 스캔해야 합니다.

IBM은 리니어 테이프 파일 시스템(Linear Tape File System)이라고 불리는 테이프용 파일 시스템을 개발했습니다. 이 파일 시스템의 IBM 구현은 오픈 소스 IBM LTFS-SDE(Single Drive Edition) 제품으로 출시되었습니다. 선형 테이프 파일 시스템은 테이프에 별도의 파티션을 사용하여 인덱스 메타 데이터를 기록하므로 전체 테이프에 걸쳐 디렉터리 항목이 흩어져 있는 문제를 피할 수 있습니다.

테이프 포맷

테이프에 데이터를 기록하거나, 테이프를 지우거나, 포맷하는 작업은 종종 시간이 많이 걸리고, 대형 테이프에서 몇 시간이 걸릴 수 있습니다.^[a] 많은 데이터 테이프 기술을 사용하기 때문에 새 데이터를 테이프에 덮어쓰기 전에 테이프를 포맷할 필요가 없습니다. 이는 순차적 미디어에서 데이터를 덮어쓰는 본질적으로 파괴적인 특성 때문입니다.

테이프를 포맷하는 데 걸리는 시간 때문에 일반적으로 테이프 사용자가 사용할 새 테이프를 준비하는 데 시간을 들일 필요가 없도록 테이프를 미리 포맷합니다. 일반적으로 필요한 것은 사용 전에 테이프에 식별 미디어 레이블을 작성하는 것뿐이며, 이마저도 새 테이프를 처음 사용할 때 소프트웨어에 의해 자동으로 작성될 수 있습니다.

데이터베이스 파일 시스템

파일 관리를 위한 또 다른 개념은 데이터베이스 기반 파일 시스템 아이디어입니다. 파일은 계층 구조화된 관리 대신 파일 유형, 주제, 작성자 또는 이와 유사한 리치 메타데이터와 같은 특성에 따라 식별됩니다.^[17]

IBM DB2 for i(이전에는 DB2/400 및 DB2 for i5/OS)는 객체 기반 IBM i 운영^[19] 체제(이전에는 OS/400 및 i5/OS로 알려짐)의 일부로서 단일 레벨 스토어를 통합하고 IBM 파워 시스템(이전에는 AS/400 및 iSeries로 알려짐)에서 실행되는 데이터베이스 파일 시스템입니다. IBM i의 전 수석 과학자인 프랭크 G. 솔티스가 디자인했습니다. 1978년에서 1988년 사이에 프랭크 G. 솔티스와 IBM 로체스터의 그의 팀은 데이터베이스 파일 시스템과 같은 기술을 성공적으로 설계하고 적용했지만 나중에 마이크로소프트와 같은 다른 회사들은 이를 달성하지 못했습니다.^[20] 이러한 기술은 비공식적으로 '포트리스 로체스터'^{[citation needed]}라고 알려져 있으며, 초기 메인프레임 기술에서 확장된 기본적인 측면은 거의 없었지만, 여러 면에서 기술적^{[citation needed]} 관점에서 더 발전했습니다.

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

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

트랜잭션 파일 시스템

일부 프로그램은 여러 개의 파일 시스템을 변경하거나 하나 이상의 변경 사항이 어떤 이유로든 실패할 경우 변경 사항을 변경하지 않아야 합니다. 예를 들어, 소프트웨어를 설치 또는 업데이트 중인 프로그램은 실행 파일, 라이브러리 및/또는 구성 파일을 작성할 수 있습니다. 일부 작성에 실패하고 소프트웨어가 부분적으로 설치되거나 업데이트된 상태로 방치되면 소프트웨어가 고장나거나 사용할 수 없게 될 수 있습니다. 명령 셸과 같은 키 시스템 유틸리티의 불완전한 업데이트는 전체 시스템을 사용할 수 없는 상태로 만들 수 있습니다.

트랜잭션 처리는 트랜잭션 내부의 작업이 모두 커밋되거나 트랜잭션이 중단되고 시스템이 부분적인 결과를 모두 폐기할 수 있도록 보장하는 원자성 보장을 도입합니다. 즉, 충돌이나 정전이 발생하면 복구 후 저장된 상태가 일관되게 유지됩니다. 소프트웨어가 완전히 설치되거나 실패한 설치가 완전히 롤백되지만 사용할 수 없는 부분 설치는 시스템에 남겨지지 않습니다. 트랜잭션은 또한 격리 보장을^{[clarification needed]} 제공합니다. 즉, 트랜잭션 내의 작업은 트랜잭션이 커밋될 때까지 시스템의 다른 스레드로부터 숨겨져 있으며, 시스템의 간섭 작업은 트랜잭션과 적절히 직렬화됩니다.

Windows(윈도우)는 Vista(비스타)부터 트랜잭션 NTFS(Transactional NTFS)라는 기능으로 NTFS에 트랜잭션 지원을 추가했지만 현재는 사용하지 않습니다.^[21] TxOS 커널의 Valor 파일 시스템,^[22] Amino,^[23] LFS ^[24]및 transactional ext3 파일 시스템을 비롯하여 ^[25]TFFS와 같은 임베디드 시스템을 대상으로 하는 Transactional 파일 시스템 등 UNIX 시스템용 트랜잭션 파일 시스템의 연구 프로토타입이 많이 있습니다.^[26]

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

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

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

네트워크 파일 시스템

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

공유 디스크 파일 시스템

공유 디스크 파일 시스템은 다수의 시스템(일반적으로 서버)이 모두 동일한 외부 디스크 하위 시스템(일반적으로 스토리지 영역 네트워크)에 액세스할 수 있는 시스템입니다. 파일 시스템은 해당 하위 시스템에 대한 액세스를 조정하여 쓰기 충돌을 방지합니다.^[28] 예를 들어 Red Hat의 GFS2, 현재 Spectrum Scale로 알려진 GPFS, IBM의 DataPlow의 SFS, SGI의 CXFS, Quantum Corporation의 StorNext 및 Scout 등이 있습니다.버시티에서 온 FS.

특수 파일 시스템

특수 파일 시스템은 파일 시스템 API를 사용하여 작업할 수 있도록 운영 체제의 비파일 요소를 파일로 표시합니다. 이 작업은 유닉스 계열 운영 체제에서 가장 일반적으로 수행되지만 일부 비유닉스 계열 운영 체제에서는 장치에 파일 이름이 부여됩니다.

장치 파일 시스템

장치 파일 시스템은 I/O 장치와 의사 장치를 장치 파일이라고 하는 파일로 나타냅니다. 유닉스 계열 시스템의 예로는 devfs와 리눅스 2.6 시스템의 udev가 있습니다. 파일의 전체 파일 이름 또는 경로 이름이 디바이스 접두사를 포함할 수 있는 TOPS-10 및 그에 의해 영향을 받는 다른 운영 체제와 같은 비유닉스 계열 시스템에서는, 파일 시스템을 포함하는 장치 이외의 장치는 그 장치를 따르는 것 없이 디바이스를 지정하는 디바이스 접두사에 의해 참조됩니다.

기타 특수 파일 시스템

• 리눅스 커널에서 configfs와 sysfs는 커널에 정보를 조회하고 커널의 엔티티를 구성하는 데 사용할 수 있는 파일을 제공합니다.
• procfs는 리눅스에서 프로세스와 다른 운영 체제 구조를 파일 공간에 매핑합니다.

최소 파일 시스템 / 오디오 카세트 스토리지

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

시스템이 데이터를 작성해야 할 경우 사용자에게 카세트 레코더의 "RECORD"를 누른 다음 키보드의 "RETURN"을 눌러 카세트 레코더가 녹음 중임을 시스템에 알리도록 알렸습니다. 시스템은 시간 동기화를 제공하기 위해 소리를 작성한 다음 접두사, 데이터, 체크섬 및 접미사를 인코딩하는 변조된 소리를 작성했습니다. 시스템이 데이터를 읽을 필요가 있을 때 사용자에게 카세트 레코더의 "PLAY"를 누르도록 지시했습니다. 시스템은 폭발음이 동기화로 인식될 때까지 대기하는 테이프의 소리를 듣습니다. 그런 다음 시스템은 후속 소리를 데이터로 해석합니다. 데이터 판독이 완료되면 시스템은 카세트 레코더의 "STOP"을 누르도록 사용자에게 알립니다. 원시적이었지만 (대부분) 효과가 있었습니다. 데이터는 순차적으로 저장되었지만 일반적으로 이름이 지정되지 않은 형식으로 저장되었지만 일부 시스템(예: 코모도어 PET 시리즈 컴퓨터)에서는 파일의 이름을 지정할 수 있었습니다. 테이프를 빠르게 포워딩하고 테이프 카운터에서 관찰하여 테이프 상의 다음 데이터 영역의 대략적인 시작점을 찾음으로써 여러 세트의 데이터를 기록하고 찾을 수 있습니다. 사용자는 다음 데이터 영역 재생을 시작하기 위한 적절한 지점을 찾기 위해 소리를 들어야 할 수도 있습니다. 일부 구현에는 데이터에 분산된 가청음도 포함되었습니다.

플랫 파일 시스템

플랫 파일 시스템에는 하위 디렉토리가 없으며 모든 파일의 디렉토리 항목이 단일 디렉토리에 저장됩니다.

플로피 디스크 미디어를 처음 사용할 수 있었을 때는 사용 가능한 데이터 공간이 상대적으로 적었기 때문에 이러한 유형의 파일 시스템이 적합했습니다. CP/M 머신은 파일을 16개의 사용자 영역 중 하나에 할당할 수 있는 플랫 파일 시스템을 특징으로 하며 일반 파일 작업은 기본적으로 모든 작업을 수행하는 대신 하나에서 작업할 수 있도록 좁혔습니다. 이러한 사용자 영역은 파일과 관련된 특별한 특성에 지나지 않습니다. 즉, 디스크에 사용 가능한 저장 공간이 남아 있는 한 이러한 각 영역에 대한 특정 할당량을 정의할 필요가 없으며 파일을 그룹에 추가할 수 있습니다. 초기의 애플 매킨토시는 플랫 파일 시스템인 매킨토시 파일 시스템을 특징으로 하기도 했습니다. 파일 관리 프로그램(Macintosh Finder)이 EMFS 위에 부분적으로 계층화된 파일링 시스템을 만들어낸 것은 이례적이었습니다. 이 구조는 모든 파일이 별도의 폴더에 있는 것처럼 보이더라도 고유한 이름을 가져야 합니다. IBM DOS/360 및 OS/360은 디스크 팩(볼륨)의 모든 파일에 대한 항목을 VTOC(Volume Table of Contents)라는 팩의 디렉토리에 저장합니다.

단순한 반면, 플랫 파일 시스템은 파일 수가 증가함에 따라 어색해지고 데이터를 관련된 파일 그룹으로 구성하기가 어려워집니다.

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

구현

운영 체제(OS)는 일반적으로 하나 이상의 파일 시스템을 지원합니다. 때로는 OS와 파일 시스템이 너무 긴밀하게 얽혀 있어서 독립적으로 설명하기 어려울 때도 있습니다.

OS는 일반적으로 사용자에게 파일 시스템 액세스를 제공합니다. 종종 OS는 유닉스 셸, 윈도우즈 Command Prompt and PowerShell, OpenVMS DCL과 같은 명령줄 인터페이스를 제공합니다. OS는 또한 종종 맥OS 파인더와 윈도우즈 파일 탐색기와 같은 그래픽 사용자 인터페이스 파일 브라우저를 제공합니다.

유닉스 및 유닉스 계열 운영 체제

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

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

유닉스 계열 운영 체제에는 마운트 프로세스를 지원하고 새로운 기능을 제공하는 소프트웨어와 도구가 포함되어 있는 경우가 많습니다. 이러한 전략 중 일부는 이러한 목적을 반영하여 "자동 장착"이라는 용어로 만들어졌습니다.

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

리눅스

Linux는 수많은 파일 시스템을 지원하지만 블록 장치의 시스템 디스크에 대한 일반적인 선택 사항에는 ext* 제품군(ext2, ext3 및 ext4), XFS, JFS 및 btrf가 포함됩니다. FTL(Flash Translation Layer) 또는 MTD(Memory Technology Device)가 없는 원시 플래시의 경우 UBIFS, JFFS2 및 YAFS 등이 있습니다. 스쿼시FS는 일반적인 압축 읽기 전용 파일 시스템입니다.

솔라리스

이전 릴리스의 Solaris는 부팅 가능한 파일 시스템 및 보조 파일 시스템에 대해 UFS(non-journaled 또는 non-logging)로 기본 설정되어 있습니다. Solaris는 기본적으로 UFS, 지원 및 확장되었습니다.

Veritas Software Corp. (Journaling) VxFS, Sun Microsystems (클러스터링) QFS, Sun Microsystems (Journaling) UFS, Sun Microsystems (오픈 소스, 풀링 가능, 128비트 압축 및 오류 수정) ZFS를 비롯한 기타 파일 시스템에 대한 지원이 시간이 지남에 따라 크게 향상되었습니다.

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

Logical Volume Management를 사용하면 이중화, 용량 및/또는 처리량을 추가하기 위해 여러 장치에 걸쳐 파일 시스템을 확장할 수 있습니다. Solaris의 기존 환경에서는 Solaris Volume Manager(이전 Sotice Disk Suite)를 사용할 수 있습니다. 여러 운영 체제(솔라리스 포함)에서 Veritas Volume Manager를 사용할 수 있습니다. 최신 Solaris 기반 운영 체제는 ZFS의 가상 스토리지 풀을 활용하여 볼륨 관리의 필요성을 제거합니다.

macOS

맥OS(이전의 맥 OS X)는 2017년에 HFS 플러스(HFS+)라는 고전적인 맥 OS에서 물려받은 파일 시스템을 대체한 애플 파일 시스템(APFS)을 사용합니다. 애플은 또한 HFS+^[29]에 "Mac OS Extended"라는 용어를 사용합니다. HFS Plus는 메타데이터가 풍부하고 대소문자를 보존하지만 (보통) 대소문자를 구분하지 않는 파일 시스템입니다. macOS의 유닉스 루트 때문에 HFS Plus에 유닉스 권한이 추가되었습니다. 나중의 HFS Plus 버전은 파일 시스템 구조의 손상을 방지하기 위해 저널링을 추가했으며 외부 조각 모음을 사용하지 않고 자동으로 파일 조각 모음을 해제하기 위해 할당 알고리즘에 여러 가지 최적화를 도입했습니다.

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

HFS Plus에는 세 가지 종류의 링크가 있습니다. 유닉스 스타일 하드 링크, 유닉스 스타일 심볼 링크 및 별칭. 별칭은 원래 파일을 이동하거나 이름을 바꾸더라도 원래 파일에 대한 링크를 유지하도록 설계되었으며, 파일 시스템 자체에서 해석되지 않고 사용자 국가의 파일 관리자 코드에서 해석됩니다.

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

macOS는 또한 NEXTSTEP을 통해 BSD 유닉스 패스트 파일 시스템에서 파생된 UFS 파일 시스템을 지원했습니다. 그러나 Mac OS X Leopard에서는 더 이상 macOS를 UFS 볼륨에 설치할 수 없으며 UFS 볼륨에 설치된 Pre-Leopard 시스템을 Leopard로 업그레이드할 수 없습니다.^[30] 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 파일 시스템에 쓰기를 허용하지만 사소한 시스템 설정 변경 후에만 사용할 수 있습니다(이를 자동화하는 타사 소프트웨어가 존재합니다).^[31]

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