상위 질문
타임라인
채팅
관점
파일 시스템
컴퓨터에서 파일이나 자료를 쉽게 발견 및 접근할 수 있도록 보관 또는 조직하는 체제 위키백과, 무료 백과사전
Remove ads
파일 시스템(file system)은 파일 구성 및 접근을 관리한다. 로컬 파일 시스템은 동일한 컴퓨터에서 실행되는 응용 프로그램에 서비스를 제공하는 운영체제의 기능이다.[1][2] 분산 파일 시스템은 네트워크에 연결된 컴퓨터 간의 파일 접근을 제공하는 통신 프로토콜이다.
파일 시스템은 응용 프로그램이 대용량 스토리지를 공유할 수 있도록 데이터 스토리지 서비스를 제공한다. 파일 시스템이 없으면 응용 프로그램은 호환되지 않는 방식으로 스토리지에 접근하여 리소스 경합, 데이터 손상 및 데이터 손실을 초래할 수 있다.
다양한 구조와 기능, 그리고 속도, 유연성, 보안, 크기 등 다양한 특성을 가진 많은 파일 시스템 설계 및 구현이 있다.
파일 시스템은 하드 디스크 드라이브(HDD), 솔리드 스테이트 드라이브(SSD), 자기 테이프 및 광 디스크를 포함한 많은 유형의 스토리지 장치를 위해 개발되었다.[3]
컴퓨터 주 메모리의 일부를 파일 시스템의 저장 장치 역할을 하는 RAM 디스크로 설정할 수 있다. tmpfs와 같은 파일 시스템은 가상 메모리에 파일을 저장할 수 있다.
가상 파일 시스템은 요청 시 계산되는 가상 파일(예: procfs 및 sysfs에서 제공하는 파일) 또는 다른 지원 스토리지로 매핑되는 파일에 대한 접근을 제공한다.
Remove ads
어원
1900년경부터 컴퓨터가 등장하기 전까지 파일 시스템, 파일링 시스템 및 파일링을 위한 시스템이라는 용어는 종이 문서를 구성, 저장 및 검색하는 방법을 설명하는 데 사용되었다.[4] 1961년에는 파일 시스템이라는 용어가 원래의 의미와 함께 전산화된 파일링에도 적용되기 시작했다.[5] 1964년에는 일반적인 용어가 되었다.[6]
아키텍처
로컬 파일 시스템의 아키텍처는 특정 파일 시스템 설계가 실제로 개념을 분리하지 않을 수도 있지만 추상화 계층으로 설명할 수 있다.[7]
논리 파일 시스템 계층은 열기, 닫기, 읽기 및 쓰기를 포함한 파일 작업을 위한 응용 프로그래밍 인터페이스(API)를 통해 상대적으로 높은 수준의 접근을 제공하며 하위 계층에 작업을 위임한다. 이 계층은 열린 파일 테이블 항목과 프로세스별 파일 서술자를 관리한다.[8] 파일 접근, 디렉토리 작업, 보안 및 보호를 제공한다.[7]
선택적 계층인 가상 파일 시스템은 여러 물리적 파일 시스템의 동시 인스턴스를 지원하며, 각 인스턴스를 파일 시스템 구현이라고 한다.[8]
물리적 파일 시스템 계층은 스토리지 장치(예: 디스크)에 대한 상대적으로 낮은 수준의 접근을 제공한다. 데이터 블록을 읽고 쓰고, 버퍼링 및 기타 메모리 관리를 제공하며, 스토리지 미디어의 특정 위치에 블록 배치를 제어한다. 이 계층은 장치 드라이버 또는 입출력 채널을 사용하여 스토리지 장치를 구동한다.[7]
Remove ads
속성
요약
관점
파일 이름
파일 이름은 사용하는 응용 프로그램과 경우에 따라 사용자에게 파일을 식별한다.
파일 이름은 고유하여 응용 프로그램이 특정 이름으로 정확히 하나의 파일을 참조할 수 있도록 한다. 파일 시스템이 디렉토리를 지원하는 경우, 일반적으로 파일 이름 고유성은 각 디렉토리의 컨텍스트 내에서 강제된다. 즉, 스토리지는 동일한 이름을 가진 여러 파일을 포함할 수 있지만 동일한 디렉토리에는 포함할 수 없다.
대부분의 파일 시스템은 파일 이름의 길이를 제한한다.
일부 파일 시스템은 대소문자 구분 방식으로 파일 이름을 일치시키고 다른 파일 시스템은 대소문자를 구분하지 않는다. 예를 들어, 대소문자를 구분하지 않는 경우 MYFILE과 myfile은 동일한 파일에 일치하지만, 대소문자를 구분하는 경우 다른 파일에 일치한다.
대부분의 최신 파일 시스템은 파일 이름에 유니코드 문자 집합의 광범위한 문자를 포함할 수 있도록 허용한다. 일부는 장치, 장치 유형, 디렉토리 접두사, 파일 경로 구분 기호 또는 파일 유형과 같은 특수 속성을 나타내는 데 사용되는 문자를 제한한다.
디렉토리
파일 시스템은 일반적으로 파일을 그룹으로 분리하는 디렉토리(폴더라고도 함)로 파일을 구성하는 것을 지원한다.
이는 파일 이름을 목차의 인덱스 또는 유닉스 계열 파일 시스템의 아이노드와 연결하여 구현할 수 있다.
디렉토리 구조는 평면적(즉, 선형)이거나, 디렉토리가 하위 디렉토리를 포함하도록 허용하여 계층 구조를 허용할 수 있다.
임의의 디렉토리 계층을 지원하는 최초의 파일 시스템은 멀틱스 운영체제에서 사용되었다.[9] 유닉스 계열 시스템의 기본 파일 시스템은 애플의 계층적 파일 시스템 및 클래식 Mac OS의 후속 HFS+, MS-DOS 2.0 및 이후 버전의 MS-DOS 및 마이크로소프트 윈도우의 FAT 파일 시스템, 윈도우 NT 운영체제 계열의 NTFS 파일 시스템, OpenVMS의 Files-11 파일 시스템의 ODS-2(On-Disk Structure-2) 및 상위 수준과 마찬가지로 임의의 디렉토리 계층을 지원한다.
메타데이터
데이터(파일 내용) 외에도 파일 시스템은 다음과 같은 관련 메타데이터를 관리하며, 이에 국한되지 않는다.
- 이름
- 크기(할당된 블록 수 또는 바이트 수로 저장될 수 있음)
- 생성, 마지막 접근, 마지막 수정 시점
- 소유자 사용자 및 그룹
- 접근 권한
- 파일 속성(예: 읽기 전용, 실행 파일 여부 등)
- 장치 유형(예: 블록, 문자, 소켓, 하위 디렉토리 등)
파일 시스템은 관련 메타데이터를 파일 내용과 별도로 저장한다.
대부분의 파일 시스템은 한 디렉토리의 모든 파일 이름을 한 곳(해당 디렉토리의 디렉토리 테이블)에 저장하며, 이는 종종 다른 파일과 마찬가지로 저장된다. 많은 파일 시스템은 파일의 메타데이터 중 일부만 디렉토리 테이블에 넣고, 나머지 메타데이터는 아이노드와 같은 완전히 별개의 구조에 저장한다.
대부분의 파일 시스템은 특정 파일과 관련되지 않은 메타데이터도 저장한다. 이러한 메타데이터에는 사용되지 않은 영역에 대한 정보(여유 공간 비트맵, 블록 가용성 맵)와 불량 섹터에 대한 정보가 포함된다. 종종 할당 그룹에 대한 이러한 정보는 할당 그룹(allocation group) 자체 내에 저장된다.
NTFS, XFS, Ext2, Ext3, 일부 버전의 UFS 및 HFS+와 같은 파일 시스템에는 확장 파일 속성을 사용하여 추가 속성을 연결할 수 있다. 일부 파일 시스템은 문서 작성자, 문서의 문자 인코딩 또는 이미지 크기와 같은 사용자 정의 속성을 제공한다.
일부 파일 시스템은 하나의 파일 이름에 여러 데이터 컬렉션을 연결할 수 있도록 한다. 이러한 개별 컬렉션은 스트림 또는 포크라고 불릴 수 있다. 애플은 오랫동안 매킨토시에 포크형 파일 시스템을 사용해 왔으며, 마이크로소프트는 NTFS에서 스트림을 지원한다. 일부 파일 시스템은 단일 파일 이름으로 파일의 여러 과거 버전을 유지한다. 파일 이름 자체는 최신 버전을 검색하고, 이전 저장 버전은 "filename;4" 또는 "filename(-4)"와 같은 특별한 명명 규칙을 사용하여 4번 이전에 저장된 버전에 접근할 수 있다.
어떤 파일 시스템이 어떤 종류의 메타데이터를 지원하는지에 대한 자세한 내용은 파일 시스템 비교 § 메타데이터를 참조할 것.
저장 공간 구성
로컬 파일 시스템은 어떤 저장 영역이 어떤 파일에 속하고 어떤 영역이 사용되지 않는지 추적한다.
파일 시스템이 파일을 생성할 때 데이터에 대한 공간을 할당한다. 일부 파일 시스템은 파일이 커짐에 따라 초기 공간 할당 및 후속 증분 할당을 지정하는 것을 허용하거나 요구한다.
파일을 삭제하려면 파일 시스템은 파일의 공간이 비어 있음을 기록하며, 이는 다른 파일에 사용할 수 있음을 의미한다.
로컬 파일 시스템은 신뢰성과 효율성을 제공하기 위해 저장 공간을 관리한다. 일반적으로 여러 물리적 단위(즉, 바이트)인 세분화된 방식으로 저장 장치 공간을 할당한다. 예를 들어, 1980년대 초반의 애플 도스에서는 140킬로바이트 플로피 디스크의 256바이트 섹터가 트랙/섹터 맵을 사용했다.
세분화된 특성으로 인해 세분화된 할당의 배수인 희귀한 크기를 가진 파일을 제외하고는 각 파일에 대해 슬랙 공간이라고 하는 사용되지 않는 공간이 발생한다.[10] 512바이트 할당의 경우 평균 사용되지 않는 공간은 256바이트이다. 64KB 클러스터의 경우 평균 사용되지 않는 공간은 32KB이다.
일반적으로 할당 단위 크기는 스토리지를 구성할 때 설정된다. 저장되는 파일에 비해 상대적으로 작은 크기를 선택하면 과도한 접근 오버헤드가 발생한다. 상대적으로 큰 크기를 선택하면 과도한 사용되지 않는 공간이 발생한다. 저장소에 있을 것으로 예상되는 파일의 평균 크기를 기반으로 할당 크기를 선택하면 사용 불가능한 공간을 최소화하는 경향이 있다.
단편화
파일 시스템이 파일을 생성, 수정 및 삭제함에 따라 기본 저장소 표현이 조각화될 수 있다. 파일과 파일 사이의 사용되지 않는 공간은 연속적이지 않은 할당 블록을 차지하게 된다.
파일 콘텐츠를 저장하는 데 필요한 공간이 연속된 블록에 할당될 수 없는 경우 파일이 조각화된다. 파일이 삭제되면 여유 공간이 조각화된다.[11]
조각화는 최종 사용자에게는 보이지 않으며 시스템은 여전히 올바르게 작동한다. 그러나 이는 하드 디스크 드라이브와 같이 연속적인 블록에서 더 잘 작동하는 일부 스토리지 하드웨어의 성능을 저하시킬 수 있다. 솔리드 스테이트 드라이브와 같은 다른 하드웨어는 조각화의 영향을 받지 않는다.
접근 제어
파일 시스템은 종종 자신이 관리하는 데이터에 대한 접근 제어를 지원한다.
접근 제어의 목적은 종종 특정 사용자가 특정 파일을 읽거나 수정하는 것을 방지하는 것이다.
접근 제어는 또한 데이터가 통제된 방식으로 수정되도록 보장하기 위해 프로그램에 의한 접근을 제한할 수 있다. 예를 들어 파일의 메타데이터나 다른 곳에 저장된 암호와 권한 비트, 접근 제어 목록 또는 기능 형태의 파일 시스템 권한이 있다. 파일 시스템 유틸리티가 구조를 재구성하고 효율적인 백업을 제공하기 위해 미디어 수준에서 데이터에 접근할 수 있어야 한다는 필요성은 일반적으로 이러한 것들이 예의 바른 사용자에게만 효과적이고 침입자에게는 효과적이지 않음을 의미한다.
파일 데이터 암호화 방법은 때때로 파일 시스템에 포함된다. 이는 파일 시스템 유틸리티가 데이터를 효과적으로 관리하기 위해 암호화 시드를 알 필요가 없기 때문에 매우 효과적이다. 암호화에 의존하는 위험에는 공격자가 데이터를 복사하여 무차별 대입 공격으로 데이터를 해독할 수 있다는 사실이 포함된다. 또한 시드를 잃어버리면 데이터를 잃게 된다.
스토리지 할당량
일부 운영 체제에서는 시스템 관리자가 디스크 할당량을 활성화하여 사용자의 저장 공간 사용을 제한할 수 있다.
데이터 무결성
파일 시스템은 일반적으로 정상 작동 시는 물론 다음과 같은 예외적인 상황에서도 저장된 데이터가 일관성을 유지하도록 보장한다.
- 파일 접근 프로그램이 파일 시스템에 파일 접근이 완료되었음을 알리지 않는 경우(파일 닫기)
- 접근 프로그램이 비정상적으로 종료되는 경우(충돌)
- 미디어 오류
- 원격 시스템과의 연결 끊김
- 운영 체제 오류
- 시스템 재설정(소프트 재부팅)
- 전원 오류(하드 리부트)
예외적인 상황에서의 복구는 메타데이터, 디렉토리 항목 업데이트 및 버퍼링되었지만 저장 미디어에 기록되지 않은 데이터 처리를 포함할 수 있다.
기록
파일 시스템은 다음과 같은 문제 분석을 허용하기 위해 이벤트를 기록할 수 있다.
- 파일 또는 시스템 문제 및 성능
- 악의적인 접근
데이터 접근
바이트 스트림 접근
많은 파일 시스템은 데이터를 바이트 스트림으로 접근한다. 일반적으로 파일 데이터를 읽기 위해 프로그램은 메모리 버퍼를 제공하고 파일 시스템은 미디어에서 데이터를 검색한 다음 데이터를 버퍼에 기록한다. 쓰기 작업은 프로그램이 파일 시스템이 읽은 다음 미디어에 저장하는 바이트 버퍼를 제공하는 것을 포함한다.
레코드 접근
일부 파일 시스템 또는 파일 시스템 위의 계층은 프로그램이 레코드를 정의하여 프로그램이 데이터를 구조로 읽고 쓸 수 있도록 허용한다. 즉, 조직화되지 않은 바이트 시퀀스가 아니다.
고정 길이 레코드 정의를 사용하는 경우, n번째 레코드를 찾는 것은 수학적으로 계산할 수 있어 레코드 구분자를 파싱하는 것에 비해 상대적으로 빠르다.
각 레코드에 대한 식별자(키라고도 함)는 프로그램이 저장 위치에 관계없이 레코드를 읽고 쓰고 업데이트할 수 있도록 한다. 이러한 저장소는 미디어 블록을 관리해야 하며, 일반적으로 키 블록과 데이터 블록을 분리한다. 효율적인 알고리즘은 레코드를 찾는 피라미드 구조로 개발될 수 있다.[12]
유틸리티
일반적으로 파일 시스템은 다양한 유틸리티 프로그램을 통해 사용자가 관리할 수 있다.
일부 유틸리티는 사용자가 파일 시스템의 인스턴스를 생성, 구성 및 제거할 수 있도록 한다. 파일 시스템에 할당된 공간을 확장하거나 축소할 수 있도록 할 수도 있다.
디렉토리 유틸리티는 dentry로도 알려진 디렉토리 항목을 생성, 이름 변경 및 삭제하는 데 사용될 수 있으며,[13] 디렉토리와 관련된 메타데이터를 변경할 수 있다. 디렉토리 유틸리티에는 디렉토리에 추가 링크(유닉스의 하드 링크)를 생성하고, 상위 링크(유닉스 계열 운영 체제의 "..")의 이름을 변경하고, 파일에 양방향 링크를 생성하는 기능도 포함될 수 있다.
파일 유틸리티는 파일을 생성, 목록화, 복사, 이동 및 삭제하며 메타데이터를 변경한다. 데이터 잘라내기, 공간 할당 잘라내기 또는 확장, 추가, 이동 및 파일을 제자리에서 수정할 수 있다. 파일 시스템의 기본 구조에 따라 파일 시작 부분에 추가하거나 잘라내는 메커니즘, 파일 중간에 항목 삽입 또는 파일에서 항목 삭제 기능을 제공할 수 있다. 파일 시스템이 삭제 취소 기능을 제공하는 경우 삭제된 파일의 공간을 확보하는 유틸리티도 이 범주에 속한다.
일부 파일 시스템은 여유 공간 재구성, 여유 공간 보안 삭제, 계층 구조 재구성과 같은 작업을 최소 활동 시점에 수행하는 유틸리티를 제공하여 지연시킨다. 예를 들어 단편화 제거 유틸리티가 있다.
파일 시스템 유틸리티의 가장 중요한 기능 중 일부는 소유권을 우회하거나 기본 장치에 직접 접근하는 것을 포함할 수 있는 감독 활동이다. 여기에는 고성능 백업 및 복구, 데이터 복제, 파일 시스템 내의 다양한 데이터 구조 및 할당 테이블 재구성이 포함된다.
파일 시스템 API
유틸리티, 라이브러리 및 프로그램은 파일 시스템 API를 사용하여 파일 시스템에 요청을 보낸다. 여기에는 데이터 전송, 위치 지정, 메타데이터 업데이트, 디렉토리 관리, 접근 사양 관리 및 제거가 포함된다.
단일 시스템 내의 여러 파일 시스템
종종 소매 시스템은 전체 저장 장치를 차지하는 단일 파일 시스템으로 구성된다.
다른 접근 방식은 디스크를 분할하여 여러 속성을 가진 여러 파일 시스템을 사용할 수 있도록 하는 것이다. 브라우저 캐시 또는 이메일 저장에 사용되는 파일 시스템은 작은 할당 크기로 구성될 수 있다. 이는 브라우저 활동의 일반적인 파일 생성 및 삭제 활동을 디스크의 좁은 영역에 유지하여 다른 파일 할당과 간섭하지 않도록 한다. 다른 파티션은 비교적 큰 블록 크기로 오디오 또는 비디오 파일 저장용으로 생성될 수 있다. 또 다른 파티션은 일반적으로 읽기 전용으로 설정되고 주기적으로 쓰기 가능으로 설정될 수 있다. ZFS 및 APFS와 같은 일부 파일 시스템은 공통 여유 블록 풀을 공유하는 여러 파일 시스템을 지원하여 각 파일 시스템에 고정된 공간을 예약할 필요 없이 다른 속성을 가진 여러 파일 시스템을 지원한다.[14][15]
주로 클라우드 시스템에서 사용되는 세 번째 접근 방식은 "디스크 이미지"를 사용하여 다른 (호스트) 파일 시스템 내에 추가 파일 시스템(동일한 속성 여부와 관계없이)을 파일로 보관하는 것이다. 일반적인 예는 가상화이다. 한 사용자는 프로덕션 Windows 환경(NTFS 파일 시스템 사용)에서 가상 머신 내에서 실험적인 리눅스 배포판(Ext4 파일 시스템 사용)을 실행할 수 있다. ext4 파일 시스템은 디스크 이미지 내에 존재하며, 이는 NTFS 호스트 파일 시스템에서 파일(하이퍼바이저 및 설정에 따라 여러 파일일 수 있음)로 처리된다.
단일 시스템에 여러 파일 시스템을 사용하면 단일 파일 시스템의 손상 시 나머지 파일 시스템은 자주 손상되지 않은 상태로 유지된다는 추가적인 이점이 있다. 여기에는 시스템 파일 시스템의 바이러스 파괴 또는 부팅되지 않는 시스템도 포함된다. 전용 접근이 필요한 파일 시스템 유틸리티는 효과적으로 부분적으로 완료될 수 있다. 또한 단편화 제거가 더 효과적일 수 있다. 바이러스 스캔 및 백업과 같은 여러 시스템 유지 관리 유틸리티도 세그먼트별로 처리될 수 있다. 예를 들어, 마지막 백업 이후 비디오를 포함하는 파일 시스템에 추가된 파일이 없는 경우 다른 모든 파일과 함께 백업할 필요는 없다. 이미지 파일의 경우 마스터(원본) 이미지에 새로 작성된 데이터만 포함하는 차등 이미지를 쉽게 "생성"할 수 있다. 차등 이미지는 안전상의 문제(폐기 가능한 시스템으로, 바이러스에 의해 파괴되거나 오염된 경우 빠르게 복원할 수 있으며, 이전 이미지를 제거하고 자동화된 절차 없이도 몇 초 만에 새 이미지를 생성할 수 있음)와 빠른 가상 머신 배포(차등 이미지는 배치로 스크립트를 사용하여 빠르게 생성될 수 있음) 모두에 사용할 수 있다.
Remove ads
종류
요약
관점
디스크 파일 시스템
디스크 파일 시스템은 디스크 저장 매체가 짧은 시간 내에 데이터를 임의로 주소 지정할 수 있는 기능을 활용한다. 추가적인 고려 사항으로는 처음 요청된 데이터에 이어지는 데이터에 접근하는 속도와 이어지는 데이터도 요청될 수 있다는 예측이 포함된다. 이를 통해 여러 사용자(또는 프로세스)가 데이터의 순차적 위치에 관계없이 디스크의 다양한 데이터에 접근할 수 있다. 예시로는 FAT (FAT12, FAT16, FAT32), ExFAT, NTFS, ReFS, HFS 및 HFS+, 고성능 파일 시스템, APFS, UFS, Ext2, Ext3, Ext4, XFS, Btrfs, Files-11, Veritas File System, VMFS, ZFS, ReiserFS, NSS 및 ScoutFS가 있다. 일부 디스크 파일 시스템은 저널링 파일 시스템 또는 버전 관리 파일 시스템이다.
광 디스크
ISO 9660 및 유니버설 디스크 포맷(UDF)은 콤팩트 디스크, DVD 및 블루레이 디스크를 대상으로 하는 두 가지 일반적인 형식이다. 마운트 레이니어는 Linux 커널 2.6 시리즈 이후 및 Windows Vista 이후 지원되는 UDF 확장으로, DVD에 재쓰기를 용이하게 한다.
플래시 파일 시스템
플래시 파일 시스템은 플래시 메모리 장치의 특수 기능, 성능 및 제약을 고려한다. 종종 디스크 파일 시스템은 플래시 메모리 장치를 기본 저장 매체로 사용할 수 있지만, 플래시 장치용으로 특별히 설계된 파일 시스템을 사용하는 것이 훨씬 좋다.[16]
테이프 파일 시스템
테이프 파일 시스템은 테이프에 파일을 저장하도록 설계된 파일 시스템 및 테이프 형식이다. 자기 테이프는 디스크보다 무작위 데이터 접근 시간이 훨씬 긴 순차적 저장 매체로, 범용 파일 시스템의 생성 및 효율적인 관리에 어려움을 제기한다.
디스크 파일 시스템에서는 일반적으로 마스터 파일 디렉토리와 사용 및 여유 데이터 영역의 맵이 존재한다. 파일 추가, 변경 또는 제거에는 디렉토리와 사용/여유 맵을 업데이트해야 한다. 데이터 영역에 대한 무작위 접근은 밀리초 단위로 측정되므로 이 시스템은 디스크에 잘 작동한다.
테이프는 잠재적으로 매우 긴 미디어 릴을 감고 풀기 위해 선형 운동이 필요하다. 이러한 테이프 이동은 읽기/쓰기 헤드를 테이프의 한쪽 끝에서 다른 쪽 끝으로 이동하는 데 몇 초에서 몇 분이 걸릴 수 있다.
결과적으로 마스터 파일 디렉토리 및 사용 맵은 테이프에서 매우 느리고 비효율적일 수 있다. 쓰기 작업은 일반적으로 블록 사용 맵을 읽어 쓰기할 여유 블록을 찾고, 사용 맵 및 디렉토리를 업데이트하여 데이터를 추가한 다음, 테이프를 진행시켜 올바른 위치에 데이터를 쓰는 것을 포함한다. 각 추가 파일 쓰기에는 맵 및 디렉토리 업데이트와 데이터 쓰기가 필요하며, 이는 각 파일에 대해 몇 초가 걸릴 수 있다.
대신 테이프 파일 시스템은 일반적으로 파일 디렉토리가 데이터와 혼합되어 테이프 전체에 분산되도록 허용하여 스트리밍이라고 부르며, 새로운 데이터를 쓰기 위해 시간이 많이 걸리고 반복적인 테이프 이동이 필요하지 않도록 한다.
그러나 이러한 설계의 부작용은 테이프의 파일 디렉토리를 읽으려면 일반적으로 테이프 전체를 스캔하여 모든 분산된 디렉토리 항목을 읽어야 한다는 것이다. 테이프 저장소와 함께 작동하는 대부분의 데이터 아카이빙 소프트웨어는 테이프 카탈로그의 로컬 복사본을 디스크 파일 시스템에 저장하여, 테이프를 다시 스캔할 필요 없이 테이프에 파일을 빠르게 추가할 수 있도록 한다. 로컬 테이프 카탈로그 복사본은 일반적으로 지정된 기간 동안 사용되지 않으면 삭제되며, 이 시점에서 나중에 사용하려면 테이프를 다시 스캔해야 한다.
IBM은 리니어 테이프 파일 시스템이라는 테이프용 파일 시스템을 개발했다. 이 파일 시스템의 IBM 구현은 오픈 소스 IBM 리니어 테이프 파일 시스템 — 단일 드라이브 에디션(LTFS-SDE) 제품으로 출시되었다. 리니어 테이프 파일 시스템은 테이프에 별도의 파티션을 사용하여 인덱스 메타데이터를 기록함으로써 전체 테이프에 디렉토리 항목이 분산되는 문제점을 피한다.
= 테이프 포맷
테이프에 데이터를 쓰거나, 지우거나, 포맷하는 것은 종종 상당히 시간이 많이 걸리는 과정이며 대용량 테이프에서는 몇 시간이 걸릴 수 있다.[a] 많은 데이터 테이프 기술에서는 새 데이터를 덮어쓰기 전에 테이프를 포맷할 필요가 없다. 이는 순차 미디어에 데이터를 덮어쓰는 것의 본질적으로 파괴적인 특성 때문이다.
테이프 포맷에 시간이 오래 걸릴 수 있으므로, 일반적으로 테이프는 미리 포맷되어 테이프 사용자가 각 새 테이프를 사용하기 위해 시간을 들여 준비할 필요가 없도록 한다. 보통 필요한 것은 사용하기 전에 테이프에 식별 미디어 레이블을 쓰는 것뿐이며, 심지어 이것도 새 테이프를 처음 사용할 때 소프트웨어에 의해 자동으로 작성될 수 있다.
데이터베이스 파일 시스템
파일 관리의 또 다른 개념은 데이터베이스 기반 파일 시스템에 대한 아이디어이다. 계층적 구조 관리 대신 또는 그 외에 파일은 파일 유형, 주제, 작성자 또는 유사한 풍부한 메타데이터와 같은 특성으로 식별된다.[17]
IBM i[18] 운영 체제(이전에는 OS/400 및 i5/OS로 알려짐)의 일부인 DB2 for i[19](이전에는 DB2/400 및 DB2 for i5/OS로 알려짐)는 단일 레벨 저장소를 통합하고 IBM Power Systems(이전에는 AS/400 및 iSeries로 알려짐)에서 실행되는 객체 기반 데이터베이스 파일 시스템이며, 프랭크 G. 솔티스(IBM의 IBM i 담당 수석 과학자)가 설계했다. 1978년에서 1988년 사이에 프랭크 G. 솔티스와 IBM 로체스터 팀은 다른 마이크로소프트와 같은 회사들이 나중에 실패한 데이터베이스 파일 시스템과 같은 기술을 성공적으로 설계하고 적용했다.[20] 이러한 기술은 비공식적으로 '요새 로체스터'로 알려져 있으며, 몇 가지 기본 측면에서는 초기 메인프레임 기술에서 확장되었지만 많은 면에서 기술적 관점에서 더 진보적이었다.
"순수한" 데이터베이스 파일 시스템은 아니지만 데이터베이스 파일 시스템의 일부 측면을 사용하는 다른 프로젝트는 다음과 같다.
- 많은 웹 콘텐츠 관리 시스템은 관계형 DBMS를 사용하여 파일을 저장하고 검색한다. 예를 들어, XHTML 파일은 XML 또는 텍스트 필드로 저장되고, 이미지 파일은 blob 필드로 저장된다. SQL SELECT (선택적 XPath 포함) 문은 파일을 검색하고, "일반 파일 시스템"보다 정교한 논리와 더 풍부한 정보 연결을 사용할 수 있도록 한다. 많은 CMS에는 파일 내용을 저장하는 데 표준 파일 시스템을 사용하고 데이터베이스 내에 메타데이터만 저장하는 옵션도 있다.
- 아파치 하둡 및 구글 파일 시스템과 같은 응용 프로그램으로 구현된 매우 큰 파일 시스템은 일부 데이터베이스 파일 시스템 개념을 사용한다.
트랜잭션 파일 시스템
일부 프로그램은 여러 파일 시스템 변경 사항을 모두 적용하거나, 하나 이상의 변경 사항이 어떤 이유로든 실패하면 변경 사항을 전혀 적용하지 않아야 한다. 예를 들어, 소프트웨어를 설치하거나 업데이트하는 프로그램은 실행 파일, 라이브러리 및 구성 파일을 작성할 수 있다. 쓰기 작업 중 일부가 실패하고 소프트웨어가 부분적으로 설치되거나 업데이트되면 소프트웨어가 손상되거나 사용할 수 없게 될 수 있다. 명령 셸과 같은 주요 시스템 유틸리티의 불완전한 업데이트는 전체 시스템을 사용할 수 없는 상태로 만들 수 있다.
트랜잭션 처리는 원자성 보장을 도입하여 트랜잭션 내의 모든 작업이 커밋되거나 트랜잭션이 중단되고 시스템이 모든 부분 결과를 폐기하도록 보장한다. 이는 충돌이나 전원 장애 발생 후 복구 시 저장된 상태가 일관성을 유지함을 의미한다. 소프트웨어는 완전히 설치되거나 실패한 설치가 완전히 롤백되지만, 사용할 수 없는 부분 설치는 시스템에 남아 있지 않는다. 트랜잭션은 또한 격리 보장을 제공한다. 이는 트랜잭션 내의 작업이 트랜잭션이 커밋될 때까지 시스템의 다른 스레드로부터 숨겨지고, 시스템의 간섭 작업이 트랜잭션과 함께 올바르게 직렬화됨을 의미한다.
윈도우는 Vista부터 NTFS에 트랜잭션 지원을 추가했지만, 현재는 사용이 권장되지 않는다.[21] Valor 파일 시스템,[22] Amino,[23] LFS,[24] TxOS 커널의 트랜잭션 Ext3 파일 시스템,[25] 및 TFFS와 같은 임베디드 시스템을 대상으로 하는 트랜잭션 파일 시스템에 대한 많은 연구 프로토타입이 있다.[26]
여러 파일 시스템 작업 전반에 걸쳐 일관성을 보장하는 것은 파일 시스템 트랜잭션 없이는 어렵거나 불가능하다. 파일 잠금은 개별 파일에 대한 동시성 제어 메커니즘으로 사용될 수 있지만, 일반적으로 디렉토리 구조 또는 파일 메타데이터를 보호하지 않는다. 예를 들어, 파일 잠금은 TOCTTOU 경합 조건을 막을 수 없다. 파일 잠금은 소프트웨어 업그레이드와 같은 실패한 작업을 자동으로 롤백할 수도 없다. 이는 원자성을 요구한다.
저널링 파일 시스템은 파일 시스템 구조에 트랜잭션 수준의 일관성을 도입하는 데 사용되는 한 가지 기술이다. 저널 트랜잭션은 OS API의 일부로 프로그램에 노출되지 않으며, 단일 시스템 호출의 세분성에서 일관성을 보장하기 위해 내부적으로만 사용된다.
데이터 백업 시스템은 일반적으로 트랜잭션 방식으로 저장된 데이터의 직접 백업을 지원하지 않아 신뢰할 수 있고 일관된 데이터 세트의 복구가 어렵다. 대부분의 백업 소프트웨어는 전체 데이터 세트의 여러 파일에 걸쳐 공유되는 트랜잭션 상태와 관계없이 특정 시간 이후 변경된 파일만 기록한다. 해결 방법으로 일부 데이터베이스 시스템은 해당 시점까지의 모든 데이터를 포함하는 보관 상태 파일을 생성하며, 백업 소프트웨어는 해당 파일만 백업하고 활성 트랜잭션 데이터베이스와는 전혀 직접 상호 작용하지 않는다. 복구는 백업 소프트웨어로 파일이 복원된 후 상태 파일에서 데이터베이스를 별도로 재구성해야 한다.
네트워크 파일 시스템
네트워크 파일 시스템은 원격 파일 접근 프로토콜의 클라이언트 역할을 하는 파일 시스템으로, 서버에 있는 파일에 대한 접근을 제공한다. 로컬 인터페이스를 사용하는 프로그램은 원격 네트워크 연결 컴퓨터의 계층적 디렉토리와 파일을 투명하게 생성, 관리 및 접근할 수 있다. 네트워크 파일 시스템의 예로는 NFS,[27] AFS, SMB 프로토콜의 클라이언트, FTP 및 WebDAV를 위한 파일 시스템과 유사한 클라이언트가 있다.
공유 디스크 파일 시스템
이 부분의 본문은 공유 디스크 파일 시스템입니다.공유 디스크 파일 시스템은 여러 컴퓨터(일반적으로 서버)가 모두 동일한 외부 디스크 서브시스템(일반적으로 스토리지 에어리어 네트워크)에 접근할 수 있도록 하는 파일 시스템이다. 파일 시스템은 해당 서브시스템에 대한 접근을 중재하여 쓰기 충돌을 방지한다.[28] 예시로는 레드햇의 GFS2, IBM의 GPFS(현재 Spectrum Scale로 알려짐), DataPlow의 SFS, SGI의 CXFS, Quantum Corporation의 StorNext 및 Versity의 ScoutFS가 있다.
특수 파일 시스템
일부 파일 시스템은 운영 체제의 요소를 파일로 노출하여 파일 시스템 API를 통해 작업할 수 있도록 한다. 이는 유닉스 계열 운영 체제에서 흔하며, 다른 운영 체제에서는 정도가 덜하다. 예시는 다음과 같다.
최소 파일 시스템 / 오디오 카세트 저장 장치
1970년대에 디스크와 디지털 테이프 장치는 일부 초기 마이크로컴퓨터 사용자에게 너무 비쌌다. 일반적인 오디오 카세트 테이프를 사용하는 저렴한 기본 데이터 저장 시스템이 고안되었다.
시스템이 데이터를 쓸 때, 사용자에게 카세트 레코더에서 "RECORD"를 누른 다음 키보드에서 "RETURN"을 눌러 시스템에 카세트 레코더가 녹음 중임을 알리도록 통지했다. 시스템은 시간 동기화를 제공하는 소리를 쓴 다음, 접두사, 데이터, 체크섬 및 접미사를 인코딩하는 변조된 소리를 썼다. 시스템이 데이터를 읽을 때, 사용자에게 카세트 레코더에서 "PLAY"를 누르도록 지시했다. 시스템은 테이프의 소리를 듣다가 소리의 폭발이 동기화로 인식될 때까지 기다렸다. 그런 다음 시스템은 후속 소리를 데이터로 해석했다. 데이터 읽기가 완료되면 시스템은 사용자에게 카세트 레코더에서 "STOP"을 누르도록 통지했다. 그것은 원시적이었지만 (대부분) 작동했다. 데이터는 일반적으로 이름 없는 형식으로 순차적으로 저장되었지만, 일부 시스템(코모도어 PET 컴퓨터 시리즈 등)은 파일에 이름을 지정할 수 있도록 허용했다. 여러 데이터 세트를 작성하고 테이프를 빨리 감고 테이프 카운터를 관찰하여 테이프의 다음 데이터 영역의 대략적인 시작 위치를 찾음으로써 찾을 수 있었다. 사용자는 다음 데이터 영역을 재생하기 시작할 올바른 위치를 찾기 위해 소리를 들어야 할 수도 있었다. 일부 구현은 데이터와 혼합된 들리는 소리까지 포함했다.
플랫 파일 시스템
플랫 파일 시스템에는 하위 디렉토리가 없다. 모든 파일의 디렉토리 항목은 단일 디렉토리에 저장된다.
플로피 디스크 미디어가 처음 사용 가능했을 때 이 유형의 파일 시스템은 상대적으로 적은 데이터 공간으로 인해 적절했다. CP/M 기계는 플랫 파일 시스템을 특징으로 했으며, 파일은 16개의 사용자 영역 중 하나에 할당될 수 있었고 일반 파일 작업은 모든 파일에 기본적으로 작동하는 대신 하나에만 작동하도록 좁혀졌다. 이러한 사용자 영역은 파일과 관련된 특수 속성일 뿐이었다. 즉, 각 영역에 특정 디스크 할당량을 정의할 필요가 없었으며 디스크에 여유 저장 공간이 있는 한 파일을 그룹에 추가할 수 있었다. 초기 애플 매킨토시도 플랫 파일 시스템인 매킨토시 파일 시스템을 특징으로 했다. 파일 관리 프로그램(파인더)이 EMFS 위에 부분적으로 계층적인 파일링 시스템의 환상을 만들어냈다는 점에서 특이했다. 이 구조는 모든 파일이 별도의 폴더에 있는 것처럼 보이더라도 고유한 이름을 가져야 했다. IBM DOS/360 및 OS/360은 디스크 팩(볼륨)의 모든 파일에 대한 항목을 볼륨 목록(VTOC)이라는 팩의 디렉토리에 저장한다. VTOC는 파일의 모든 메타데이터를 저장한다. 나중에 시스템 카탈로그가 도입되면서 계층적 디렉토리 구조가 적용되었으며, 이는 상주 및 이동식 볼륨의 파일(데이터 세트)을 선택적으로 카탈로그화할 수 있다. 카탈로그는 데이터 세트를 특정 볼륨에 연결하는 정보만 포함한다. 사용자가 오프라인 볼륨의 데이터 세트에 대한 접근을 요청하고 적절한 권한을 가진 경우 시스템은 필요한 볼륨을 마운트하려고 시도한다. 카탈로그화된 데이터 세트와 카탈로그화되지 않은 데이터 세트는 필요한 볼륨 ID가 OPEN 요청에 제공되면 카탈로그를 우회하여 VTOC의 정보를 사용하여 계속 접근할 수 있다. 나중에는 VTOC가 접근 속도를 높이기 위해 인덱싱되었다.
간단하지만 파일 수가 증가하고 데이터를 관련 파일 그룹으로 구성하기 어려워지면 플랫 파일 시스템이 번거로워진다.
플랫 파일 시스템 제품군에 최근 추가된 것은 아마존의 S3로, 원격 저장 서비스이며, 사용자가 데이터를 저장하는 방식을 사용자 정의할 수 있도록 의도적으로 단순하게 설계되었다. 유일한 구성 요소는 버킷(무제한 크기의 디스크 드라이브를 상상해보라)과 객체(파일의 표준 개념과 유사하지만 동일하지는 않다)이다. 고급 파일 관리는 객체 이름에 거의 모든 문자( '/' 포함)를 사용할 수 있고 동일한 접두사를 기반으로 버킷 콘텐츠의 하위 집합을 선택할 수 있는 기능으로 허용된다.
Remove ads
구현
요약
관점
운영체제(OS)는 일반적으로 하나 이상의 파일 시스템을 지원한다. 때로는 OS와 해당 파일 시스템이 너무 긴밀하게 엮여 있어 독립적으로 설명하기 어렵다.
OS는 일반적으로 사용자에게 파일 시스템 접근을 제공한다. 종종 OS는 유닉스 셸과 같은 명령줄 인터페이스, 윈도우 명령 프롬프트 및 파워셸, 또는 OpenVMS DCL을 제공한다. OS는 종종 MacOS의 파인더 또는 윈도우의 파일 탐색기와 같은 그래픽 사용자 인터페이스에서 파일 관리자도 제공한다.
유닉스 및 유닉스 계열 운영 체제
유닉스 계열 운영 체제는 가상 파일 시스템을 생성하여 모든 연결된 저장 장치의 모든 파일이 단일 계층 구조에 존재하는 것처럼 보이게 한다. 즉, 이러한 시스템에서는 하나의 루트 디렉토리가 있으며, 시스템에 존재하는 모든 파일은 그 아래 어딘가에 위치한다. 유닉스 계열 시스템은 RAM 디스크 또는 네트워크 공유 리소스를 루트 디렉토리로 사용할 수 있다.
유닉스 계열 시스템은 각 장치에 장치 이름을 할당하지만, 이는 해당 장치의 파일에 접근하는 방식이 아니다. 대신, 다른 장치의 파일에 접근하려면 운영 체제에 해당 파일이 디렉토리 트리의 어느 위치에 나타나야 하는지 먼저 알려야 한다. 이 프로세스를 파일 시스템 마운트라고 한다. 예를 들어, CD-ROM의 파일에 접근하려면 운영 체제에 "이 CD-ROM에서 파일 시스템을 가져와서 해당 디렉토리 아래에 나타나게 하라"고 알려야 한다. 운영 체제에 제공되는 디렉토리를 마운트 포인트라고 한다. 예를 들어, /media일 수 있다. /media 디렉토리는 많은 유닉스 시스템에 존재하며(파일시스템 계층구조 표준에 명시됨) CD, DVD, USB 드라이브 또는 플로피 디스크와 같은 이동식 미디어의 마운트 포인트로 특별히 사용하기 위한 것이다. 비어 있거나 개별 장치를 마운트하기 위한 하위 디렉토리를 포함할 수 있다. 일반적으로 시스템 관리자 (즉, 루트 사용자)만이 파일 시스템 마운트를 승인할 수 있다.
유닉스 계열 운영 체제는 종종 마운트 프로세스를 돕고 새로운 기능을 제공하는 소프트웨어 및 도구를 포함한다. 이러한 전략 중 일부는 목적을 반영하여 "자동 마운트"라고 불린다.
- 많은 상황에서 운영 체제가 부팅되자마자 루트 이외의 파일 시스템을 사용할 수 있어야 한다. 따라서 모든 유닉스 계열 시스템은 부팅 시 파일 시스템을 마운트하는 기능을 제공한다. 시스템 관리자는 이러한 파일 시스템을 구성 파일 fstab(Solaris에서는 vfstab)에 정의하며, 옵션 및 마운트 포인트도 표시한다.
- 일부 상황에서는 부팅 시 특정 파일 시스템을 마운트할 필요는 없지만, 그 이후에 사용이 필요할 수 있다. 유닉스 계열 시스템에는 필요에 따라 미리 정의된 파일 시스템을 마운트할 수 있도록 하는 유틸리티가 있다.
- 이동식 미디어를 사용하면 물리적 연결 없이 컴퓨터 간에 프로그램과 데이터를 전송할 수 있다. 일반적인 예로는 USB 플래시 드라이브, CD-ROM 및 DVD가 있다. 따라서 미디어의 존재와 가용성을 감지한 다음 사용자 개입 없이 해당 미디어를 마운트하는 유틸리티가 개발되었다.
- 진보적인 유닉스 계열 시스템은 또한 슈퍼마운팅이라는 개념을 도입했다. 예를 들어, 리눅스 supermount-ng 프로젝트를 참조하라. 예를 들어, 슈퍼마운트된 플로피 디스크는 시스템에서 물리적으로 제거될 수 있다. 정상적인 상황에서는 디스크를 제거하기 전에 동기화하고 마운트 해제해야 한다. 동기화가 이루어졌다면 다른 디스크를 드라이브에 삽입할 수 있다. 시스템은 디스크가 변경되었음을 자동으로 감지하고 마운트 포인트 내용을 업데이트하여 새 미디어를 반영한다.
- 오토마운터는 마운트해야 할 디렉토리에 대한 참조가 이루어질 때 파일 시스템을 자동으로 마운트한다. 이것은 일반적으로 이동식 미디어에 적합한 미디어 삽입과 같은 이벤트에 의존하기보다는 네트워크 서버의 파일 시스템에 사용된다.
리눅스
리눅스는 수많은 파일 시스템을 지원하지만, 블록 장치의 시스템 디스크에 대한 일반적인 선택은 ext* 계열(Ext2, Ext3 및 Ext4), XFS, JFS 및 Btrfs이다. 플래시 변환 계층(FTL) 또는 메모리 테크놀로지 디바이스(MTD)가 없는 원시 플래시의 경우 UBIFS, JFFS2 및 YAFFS 등이 있다. SquashFS는 일반적인 압축된 읽기 전용 파일 시스템이다.
솔라리스
초기 릴리스의 솔라리스는 부팅 가능 및 보조 파일 시스템의 기본값으로 (저널링되지 않거나 로깅되지 않은) UFS를 사용했다. 솔라리스는 UFS를 기본값으로 사용하고 지원하며 확장했다.
시간이 지남에 따라 다른 파일 시스템에 대한 지원 및 상당한 개선이 추가되었으며, 여기에는 Veritas Software Corp. (저널링) VxFS, 썬 마이크로시스템즈 (클러스터링) QFS, 썬 마이크로시스템즈 (저널링) UFS, 그리고 썬 마이크로시스템즈 (오픈 소스, 풀링 가능, 128비트 압축 가능, 오류 수정) ZFS가 포함되었다.
솔라리스에 커널 확장이 추가되어 부팅 가능한 Veritas VxFS 작업을 허용했다. 썬의 솔라리스 7에서는 UFS에 로깅 또는 저널링이 추가되었다. 솔라리스 10, Solaris Express, 오픈솔라리스 및 솔라리스 운영 체제의 다른 오픈 소스 변형 릴리스는 나중에 부팅 가능한 ZFS를 지원했다.
논리 볼륨 관리는 중복성, 용량 및 처리량을 추가하기 위해 여러 장치에 파일 시스템을 확장할 수 있도록 한다. 솔라리스의 레거시 환경에서는 솔라리스 볼륨 관리자(이전에는 Solstice DiskSuite로 알려짐)를 사용할 수 있다. 여러 운영 체제(솔라리스 포함)는 Veritas Volume Manager를 사용할 수 있다. 최신 솔라리스 기반 운영 체제는 ZFS의 가상 스토리지 풀을 활용하여 볼륨 관리의 필요성을 넘어선다.
macOS
macOS (이전에는 Mac OS X)는 2017년에 클래식 Mac OS에서 계승된 HFS+ 파일 시스템을 대체한 APFS를 사용한다. 애플은 HFS+를 "Mac OS Extended"라고도 부른다.[29] HFS+는 메타데이터가 풍부하고 대소문자 보존형이지만 (일반적으로) 대소문자 비구분형 파일 시스템이다. macOS의 유닉스 뿌리 때문에 유닉스 권한이 HFS+에 추가되었다. 나중에 HFS+ 버전은 파일 시스템 구조의 손상을 방지하기 위해 저널링을 추가하고 외부 조각 모음 프로그램 없이 파일을 자동으로 조각 모음하려는 시도로 할당 알고리즘에 여러 최적화를 도입했다.
파일 이름은 최대 255자까지 가능하다. HFS+는 파일 이름을 저장하기 위해 유니코드를 사용한다. macOS에서 파일 유형은 파일의 메타데이터에 저장된 타입 코드 또는 파일 확장자에서 가져올 수 있다.
HFS+에는 세 가지 종류의 링크가 있다: 유닉스 스타일 하드 링크, 유닉스 스타일 심볼릭 링크, 그리고 별칭. 별칭은 원래 파일이 이동되거나 이름이 변경되더라도 해당 파일에 대한 링크를 유지하도록 설계되었다. 파일 시스템 자체에서 해석되지 않고 사용자 공간의 파일 관리자 코드에서 해석된다.
2017년 6월 5일 Apple의 WWDC 행사에서 발표된 macOS 10.13 High Sierra는 솔리드 스테이트 드라이브에서 애플 파일 시스템을 사용한다.
macOS는 BSD 유닉스 Fast File System에서 파생된 NeXTSTEP을 통해 UFS 파일 시스템도 지원했다. 그러나 Mac OS X Leopard부터 macOS는 더 이상 UFS 볼륨에 설치할 수 없었고, UFS 볼륨에 설치된 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는 Mac OS X Snow Leopard 버전 10.6.5부터 exFAT 파일 시스템을 읽고 쓰는 것을 지원한다.[32] exFAT 지원을 구현하려면 라이센스가 필요하므로 다른 운영 체제에서는 지원이 드물다. exFAT는 macOS와 Windows 모두에서 완벽하게 지원되며 4GB보다 큰 파일을 저장할 수 있는 유일한 파일 시스템이다.[33][34]
OS/2
OS/2 1.2는 고성능 파일 시스템(HPFS)을 도입했다. HPFS는 다른 코드 페이지의 대소문자 혼합 파일 이름, 긴 파일 이름(255자), 디스크 공간의 효율적인 사용, 디스크 볼륨에서 관련 항목을 서로 가깝게 유지하는 아키텍처, 데이터 단편화 감소, 익스텐트 기반 공간 할당, 디렉토리를 위한 B+ 트리 구조, 더 빠른 평균 접근을 위한 디스크 중간 지점에 위치한 루트 디렉토리를 지원한다. 저널링 파일 시스템(JFS)은 1999년에 출시되었다.
PC-BSD
PC-BSD는 FreeBSD의 데스크톱 버전으로, FreeBSD의 ZFS 지원을 FreeNAS와 유사하게 계승한다. PC-BSD의 새로운 그래픽 설치 프로그램은 /를 ZFS 및 RAID-Z 풀 설치에서 처리할 수 있으며, Geli를 사용하여 디스크 암호화를 처음부터 쉽고 편리한 GUI 방식으로 수행할 수 있다. 현재 PC-BSD 9.0+ 'Isotope Edition'은 ZFS 파일 시스템 버전 5와 ZFS 스토리지 풀 버전 28을 사용한다.
플랜 9
Bell Labs의 플랜 9은 모든 것을 파일로 취급하며 모든 객체에 파일처럼 접근한다(즉, ioctl 또는 mmap이 없음). 네트워킹, 그래픽, 디버깅, 인증, 기능, 암호화 및 기타 서비스는 파일 서술자에 대한 I/O 작업을 통해 접근된다. 9P 프로토콜은 로컬 파일과 원격 파일 간의 차이를 제거한다. 플랜 9의 파일 시스템은 사적인 프로세스별 네임스페이스를 통해 구성되어 각 프로세스가 분산 시스템에서 리소스를 제공하는 여러 파일 시스템을 다르게 볼 수 있도록 한다.
인페르노 운영 체제는 플랜 9와 이러한 개념을 공유한다.
마이크로소프트 윈도우
윈도우는 FAT, NTFS, ExFAT, 라이브 파일 시스템 및 ReFS 파일 시스템을 사용한다(이 중 마지막은 윈도우 서버 2012, 윈도우 서버 2016, 윈도우 8, 윈도우 8.1 및 윈도우 10에서만 지원되고 사용 가능하며, 윈도우는 이 시스템으로 부팅할 수 없다).
윈도우는 사용자 수준에서 드라이브 문자 추상화를 사용하여 디스크 또는 파티션을 구분한다. 예를 들어, 경로 C:\WINDOWS는 문자 C로 표시되는 파티션의 디렉토리 WINDOWS를 나타낸다. 드라이브 C:는 일반적으로 윈도우가 설치되고 부팅되는 기본 하드 디스크 드라이브 파티션에 사용된다. 이 "전통"은 운영 체제가 설치된 드라이브가 C라고 가정하는 많은 응용 프로그램에 버그가 존재할 정도로 확고히 자리 잡았다. 드라이브 문자의 사용과 "C"를 기본 하드 디스크 드라이브 파티션에 대한 드라이브 문자로 사용하는 전통은 MS-DOS로 거슬러 올라가며, 거기서 문자 A와 B는 최대 두 개의 플로피 디스크 드라이브용으로 예약되었다. 이는 다시 1970년대의 CP/M에서, 궁극적으로는 1967년 IBM의 CP/CMS에서 파생되었다.
FAT
FAT 파일 시스템 계열은 마이크로소프트 윈도우의 모든 버전과 MS-DOS/PC DOS, OS/2 및 DR-DOS를 포함하여 거의 모든 개인용 컴퓨터 운영 체제에서 지원된다. (PC DOS는 MS-DOS의 OEM 버전이며, MS-DOS는 원래 SCP의 86-도스를 기반으로 했다. DR-DOS는 디지털 리서치의 Concurrent DOS를 기반으로 했으며, 이는 CP/M-86의 후속 버전이었다.) 따라서 FAT 파일 시스템은 대부분의 유형과 연령대의 컴퓨터 및 장치 간의 범용 교환 형식으로 적합하다.
FAT 파일 시스템은 Standalone Disk BASIC의 (호환되지 않는) 8비트 FAT 전신과 단명한 MDOS/MIDAS 프로젝트로 그 뿌리를 거슬러 올라간다.
수년에 걸쳐 파일 시스템은 FAT12에서 FAT16 및 FAT32로 확장되었다. 하위 디렉토리, 코드 페이지 지원, 확장 속성 및 긴 파일 이름을 포함한 다양한 기능이 파일 시스템에 추가되었다. 디지털 리서치와 같은 타사에서는 파일 및 디렉토리 암호와 읽기/쓰기/실행/삭제 접근 권한과 같은 권한을 지원하기 위해 삭제 추적 및 볼륨/디렉토리/파일 기반 다중 사용자 보안 체계에 대한 선택적 지원을 통합했다. 이러한 확장 중 대부분은 윈도우에서 지원되지 않는다.
FAT12 및 FAT16 파일 시스템은 파일 시스템의 루트 디렉토리 항목 수에 제한이 있었고, FAT 형식 디스크 또는 파티션의 최대 크기에 제한이 있었다.
FAT32는 FAT12 및 FAT16의 제한 사항을 해결했지만, 4GB에 가까운 파일 크기 제한은 여전히 존재하며, NTFS에 비해 여전히 제한적이다.
FAT12, FAT16 및 FAT32는 또한 파일 이름에 8자, 확장자(예: .exe)에 3자 제한이 있다. 이를 일반적으로 8.3 파일 이름 제한이라고 한다. 윈도우 95 및 윈도우 NT 3.5에 도입된 FAT12, FAT16 및 FAT32의 선택적 확장인 VFAT는 긴 파일 이름(LFN)을 하위 호환 방식으로 FAT 파일 시스템에 저장할 수 있도록 했다.
NTFS
윈도우 NT 운영 체제와 함께 1993년에 도입된 NTFS는 ACL 기반의 권한 제어를 허용했다. NTFS가 지원하는 다른 기능으로는 하드 링크, 여러 파일 스트림, 속성 인덱싱, 할당량 추적, 스파스 파일, 암호화, 압축 및 재분석 지점(다른 파일 시스템, 심볼릭 링크, 접합점, 원격 저장 링크의 마운트 지점 역할을 하는 디렉토리)이 있다.
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는 macOS 버전 10.6.5(Snow Leopard)부터 지원된다.[32] exFAT 지원을 구현하려면 라이선스가 필요하므로 다른 운영 체제에서는 지원이 드물다. exFAT는 macOS와 Windows 모두에서 완전히 지원되며 4GB보다 큰 파일을 저장할 수 있는 유일한 파일 시스템이다.[35][36]
OpenVMS
이 부분의 본문은 Files-11입니다.MVS
VSAM이 도입되기 전에 OS/360 시스템은 하이브리드 파일 시스템을 구현했다. 이 시스템은 이동식 디스크 팩을 쉽게 지원하도록 설계되었기 때문에 단일 디스크(IBM 용어로는 볼륨)의 모든 파일에 대한 정보는 해당 디스크에 볼륨 목록(VTOC)이라는 플랫 시스템 파일에 저장된다. VTOC는 파일의 모든 메타데이터를 저장한다. 나중에 시스템 카탈로그가 도입되면서 계층적 디렉토리 구조가 적용되었으며, 이는 선택적으로 상주 및 이동식 볼륨의 파일(데이터 세트)을 카탈로그화할 수 있다. 카탈로그는 데이터 세트를 특정 볼륨과 연결하는 정보만 포함한다. 사용자가 오프라인 볼륨의 데이터 세트에 대한 접근을 요청하고 적절한 권한을 가진 경우 시스템은 필요한 볼륨을 마운트하려고 시도한다. 카탈로그화된 데이터 세트와 카탈로그화되지 않은 데이터 세트는 필요한 볼륨 ID가 OPEN 요청에 제공되면 카탈로그를 우회하여 VTOC의 정보를 사용하여 계속 접근할 수 있다. 나중에는 VTOC가 접근 속도를 높이기 위해 인덱싱되었다.
대화형 모니터 시스템
이 부분의 본문은 CMS 파일 시스템입니다.VM/370의 IBM 대화형 모니터 시스템(Conversational Monitor System, CMS) 구성 요소는 각 가상 디스크(미니디스크)에 대해 별도의 플랫 파일 시스템을 사용한다. 파일 데이터와 제어 정보는 흩어져 있고 혼합되어 있다. 앵커는 항상 디스크의 네 번째 블록에 위치하는 Master File Directory(MFD)라고 불리는 레코드이다. 원래 CMS는 고정 길이 800바이트 블록을 사용했지만, 나중 버전에서는 최대 4K의 더 큰 크기 블록을 사용했다. 데이터 레코드에 접근하려면 두 단계의 간접 참조가 필요하며, 파일의 디렉토리 항목(파일 상태 테이블(FST) 항목이라고 함)은 개별 레코드 주소 목록이 포함된 블록을 가리킨다.
AS/400 파일 시스템
AS/400 및 그 후속 시스템의 데이터는 단일 레벨 저장소의 시스템 가상 주소 공간에 매핑된 시스템 객체로 구성된다. 다른 파일 시스템에서 발견되는 디렉토리 및 파일을 포함하여 많은 유형의 객체가 정의된다. 파일 객체는 다른 유형의 객체와 함께 AS/400의 통합 관계형 데이터베이스 지원의 기반을 형성한다.
기타 파일 시스템
- Prospero 파일 시스템은 가상 시스템 모델을 기반으로 하는 파일 시스템이다.[37] 이 시스템은 남부 캘리포니아 대학교의 정보 과학 연구소의 B. Clifford Neuman이 만들었다.
- RSRE FLEX 파일 시스템 - ALGOL 68로 작성됨
- 미시간 터미널 시스템(MTS)의 파일 시스템은 다음과 같은 이유로 흥미롭다. (i) 파일의 각 레코드와 메타데이터로 연결된 레코드 길이와 줄 번호를 제공하는 "라인 파일"을 제공하며, 파일 전체를 읽고 다시 쓸 필요 없이 파일의 어느 곳에든 동일하거나 다른 길이의 레코드를 추가, 교체, 업데이트 및 삭제할 수 있다. (ii) 프로그램 키를 사용하여 파일을 사용자 및 그룹 외에 명령 및 프로그램과 공유하거나 허용할 수 있다. (iii) 파일의 데이터와 메타데이터를 모두 보호하는 포괄적인 파일 잠금 메커니즘이 있다.[38][39]
- TempleOS는 테리 A. 데이비스가 만든 파일 시스템인 RedSea를 사용한다.[40]
Remove ads
제약 사항
요약
관점
설계 제약 사항
파일 시스템은 저장 가능한 데이터 용량을 제한한다. 일반적으로 파일 시스템이 설계될 당시의 일반적인 저장 장치 크기와 예측 가능한 미래에 의해 결정된다.
저장 장치 크기가 거의 기하급수적인 속도로 증가했기(무어의 법칙 참조) 때문에, 새로운 저장 장치는 도입 후 불과 몇 년 만에 기존 파일 시스템 한계를 종종 초과한다. 이는 계속 증가하는 용량을 가진 새로운 파일 시스템을 필요로 한다.
용량이 증가함에 따라 기능에 대한 필요성과 복잡성도 증가한다. 파일 시스템의 복잡성은 일반적으로 사용 가능한 저장 용량에 비례하여 달라진다. 용량 문제를 제쳐두고, 1980년대 초 50KB에서 512KB의 저장 공간을 가진 가정용 컴퓨터의 파일 시스템은 수백 기가바이트의 용량을 가진 현대 저장 시스템에는 합리적인 선택이 아니다. 마찬가지로 현대 파일 시스템은 이러한 초기 시스템에는 합리적인 선택이 아닐 것이다. 현대 파일 시스템 구조의 복잡성이 초기 저장 시스템의 제한된 용량을 빠르게 소비할 것이기 때문이다.
파일 시스템 유형 변환
파일이 현재 존재하는 파일 시스템과 다른 파일 시스템에 있는 것이 유리하거나 필요할 수 있다. 이유로는 현재 파일 시스템의 한계를 넘어서는 공간 요구 사항 증가의 필요성이 포함된다. 경로 깊이가 파일 시스템의 제약 사항을 넘어서 증가해야 할 수도 있다. 성능 또는 신뢰성 문제가 있을 수 있다. 기존 파일 시스템을 지원하지 않는 다른 운영 체제에 접근을 제공하는 것이 또 다른 이유이다.
현재 위치에서 변환
일부 경우 변환은 현재 위치에서 수행될 수 있지만, 파일 시스템을 마이그레이션하는 것이 더 보수적이며, 데이터 복사본을 생성하는 것이 포함되고 권장된다.[41] 윈도우에서는 convert.exe 유틸리티를 통해 FAT 및 FAT32 파일 시스템을 NTFS로 변환할 수 있지만, 반대로는 안 된다.[41] 리눅스에서는 ext2를 ext3로 변환할 수 있고(다시 변환 가능), ext3를 ext4로 변환할 수 있으며(다시 변환 불가능),[42] ext3와 ext4 모두 Btrfs로 변환할 수 있고, 실행 취소 정보가 삭제될 때까지 다시 변환할 수 있다.[43] 이러한 변환은 파일 데이터 자체에 동일한 형식을 사용하고, 메타데이터를 빈 공간으로 재배치하며, 일부 경우에는 스파스 파일 지원을 사용하기 때문에 가능하다.[43]
다른 파일 시스템으로 마이그레이션
마이그레이션은 추가 공간이 필요하다는 단점이 있지만 더 빠를 수 있다. 가장 좋은 경우는 최종 파일 시스템을 포함할 미디어에 사용되지 않는 공간이 있는 경우이다.
예를 들어, FAT32 파일 시스템을 ext2 파일 시스템으로 마이그레이션하려면 새 ext2 파일 시스템을 생성한다. 그런 다음 FAT32 파일 시스템의 데이터를 ext2 파일 시스템으로 복사하고 이전 파일 시스템을 삭제한다.
새 파일 시스템을 생성할 때까지 원래 파일 시스템을 유지할 충분한 공간이 없을 경우 대안은 작업 영역(예: 이동식 미디어)을 사용하는 것이다. 이 방법은 시간이 더 오래 걸리지만 백업을 생성한다는 이점이 있다.
긴 파일 경로 및 긴 파일 이름
계층적 파일 시스템에서 파일은 파일을 포함하는 분기형 디렉토리 목록인 경로를 통해 접근된다. 파일 시스템마다 경로 깊이에 대한 제한이 다르다. 파일 시스템은 또한 개별 파일 이름의 길이에 대한 제한도 있다.
긴 이름을 가진 파일이나 깊이가 상당한 경로에 있는 파일을 한 파일 시스템에서 다른 파일 시스템으로 복사하면 바람직하지 않은 결과가 발생할 수 있다. 이는 복사 작업을 수행하는 유틸리티가 불일치를 어떻게 처리하는지에 따라 달라진다.
Remove ads
같이 보기
각주
외부 링크
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads