파일 시스템

1. 관련 용어

1) File

- 컴퓨터에서 의미가 있는 정보를 담은 논리적인 단위

- 비휘발성 보조기억장치(하드디스크)에 저장

- 운영체제는 다양한 저장 장치를 file 이라는 동일한 논리적 단위로 볼 수 있게 해줌

- 실행 파일과 데이터 파일로 존재

* 실행 파일 : 운영체제가 메모리로 가져와 CPU를 이용하여 작업하는 파일 (ex 윈도우 exe 파일. 유닉스는 따로 확장자 없음)

* 데이터 파일 : 실행파일이 작업하는데 필요한 데이터를 모아놓은 파일

2) File attribute (= metadata)

- 파일 자체의 내용이 아니라 파일을 관리하기 위한 각종 정보들

- 파일 이름, 유형, 저장된 위치, 접근 권한, 소유자 등

3) Directory

- 파일의 메타데이터 중 일부를 보관하고 있는 일종의 특별한파일

- 자신의 디렉토리에 속한 파일 이름 및 메타데이터 정보를 담음

2. File System

1) 정의

- 컴퓨터에서 파일이나 자료를 쉽게 발견 할 수 있도록, 유지, 관리하는 방법.

- 파일 및 메타데이터, 디렉토리 정보 등을 관리

- 디스크가 하나의 집이라면 파일 시스템은 여기에는 화장실을 두고, 여기에는 침실을 두는 것 같이 그 집을 관리하는 방법을 말합니다.

2) 특징

- 사용자 영역이 아닌 커널 영역에서 동작

- 파일을 빠르게 읽기, 쓰기, 삭제 등 기본적인 기능을 원활히 수행하기 위한 목적

- 계층적 디렉터리 구조를 가짐

- 디스크 파티션 별로 하나씩 둠

3) 파일 시스템 개발 목적

- 파일 관리 용이

- HDD의 막대한 용량을 효율적으로 이용

- HDD와 메인 메모리 속도차 줄이기

: HDD에 저장된 데이터들은 HDD에서 실행되는 것이 아니라 메인 메모리에 Load 되어 사용된다. 이 때 파일 시스템이 HDD에 저장된 데이터들의 목차가 되어 데이터를 실행하려고 클릭 했을 때 메인 메모리에 빠르게 load 될 수 있도록 한다.

4) 파일 시스템의 역할

- 불의의 사태를 대비하여 파일의 예비(Backup)와 복구(Recovery) 등의 기능을 제공한다.

- 사용자가 파일을 편리하게 사용할 수 있도록 파일의 논리적 상태(디렉터리)를 보여주어야 한다.

- 파일을 안전하게 사용할 수 있도록 하고, 파일이 보호되어야 한다.

- 파일의 정보가 손실되지 않도록 데이터 무결성을 유지해야 한다.

5) 주요 파일 시스템

Windows : FAT(FAT12/16/32,exFAT), NTFS

Linux : ext(ext2/3/4)

Mac OS : APFS, HFS, HFS+

Google : GFS

*GFS : Google File System으로 구글에서 사용하는 분산 파일 시스템

- 한 운영체제에서 여러 개의 파일 시스템을 지원하고, 동시에 사용도 가능

6) 파일 시스템 구조

- UNIX 파일 시스템에서 디스크는 512, 1024, 2048 바이트 등의 크기를 가지는 블록들로 구성된다.

- Boot Block, Super Block, I-Node Block, Data Block 4개의 영역을 가진다.

부트 블록

- 부팅시 필요한 코드를 저장하고 있는 블록

슈퍼 블록

- 전체 파일 시스템에 대한 정보를 저장하고 있는 블록

- 파일 시스템의 총 블록 개수, 사용 가능한 I-node, 사용 가능한 디스크 블록 개수, 블록 크기 등

- File 시스템마다 각각의 슈퍼블록을 가지고 있음

I-node 블록

- 각 파일이나 디렉터리에 대한 모든 정보를 저장하고 있는 블록

- 파일 소유자의 사용자 번호(UID) 및 그룹 번호(GID), 파일크기, 파일 타입, 생성 시기, 최종 변경시기, 최근 사용 시기, 파일의 보호권한, 파일 링크수, 데이터가 저장된 블록의 시작 주소 등

I-Node

- 파일에 대한 정보(메타 데이터)를 가지는 고정 크기를 가진 구조체(1개의 inode는 64byte로 이루어짐)

- i-node, i-node table, i-number, addressing으로 구성

* i-node : 하나의 파일/디렉토리의 모든 정보를 가진 테이블(구조체)

* i-node table : 전체 i-node를 가지고 있는 테이블 (주기억장치에 저장됨)

* i-number : i-node가 i-node table에 등록되는 entry number

* addressing : 블록 위치 관리(12개의 직접 데이터 블록, 1개의 간접 데이터 블록)

=> 어떤 한 파일이나 디렉토리를 만들게 되면 1개의 inode가 만들어진다. 그 inode가 inode Table에 등록이되고, 등록되는 entry-number를 그 inode에 대한 inumber라고 한다.

- Direct Block & Indirect Block : 기존 Direct Block만 존재했을 땐, 4KB 크기 데이터 12개만 처리 가능했음. 하지만 더 큰 크기의 데이터를 내포해야 할 필요가 발생했고, Single Indirect는 한 깊이 들어가서 Direct block을 연결한 것. 여기엔 4KB/4byte = 1024개 즉 4MB 만큼의 data를 포함할 수 있게 된다. 동일한 원리로 Double indirect는 두 깊이 들어가고 Triple indirect는 3깊이 더 깊게 연결되어 더 큰 용량의 데이터를 포함시킬 수 있다.

데이터 블록

- 디렉터리별로 디렉터리 엔트리와 실제파일에 대한 데이터가 저장된 블록

--- 대사 : 여태까지 파일 시스템 구조에 대해 알아봤고, 이제 프로세스가 파일의 메타정보와 데이터에 어떻게 접근하는지 unix 파일 시스템 중심으로 알아보도록하겠습니다.

3. FD를 통한 파일 메타 데이터 할당과 접근

- 프로세스는 FD(file descriptor)를 통해 파일에 접근

파일 디스크립터(File Descriptor)

- 시스템으로부터 할당 받은 파일을 대표하는 0이 아닌 정수 값

- 프로세스에서 열린 파일의 목록을 관리하는 테이블의 인덱스

- 프로세스가 실행 중에 파일을 Open하면 커널은 해당 프로세스의 파일 디스크립터 숫자 중 사용하지 않는 가장 작은 값을 할당해준다. 그 다음 프로세스가 열려있는 파일에 시스템 콜을 이용해서 접근할 때, 파일 디스크립터(FD)값을 이용해서 파일을 지칭할 수 있다.

File Descriptor Table

- 프로세스가 현재 사용중인 파일을 관리하기 위한 테이블이며, 프로세스마다 하나씩 가지고 있다.

- File Table을 가리키는 포인터를 담고있는 배열이고, 이 배열의 index가 fd이다.

(Open) File Table

- 주기억장치에 존재

- 프로세스에 의해 open된 파일의 읽기/쓰기 동작을 지원하기 위한 테이블. 파일이 열릴 때마다 하나씩 할당된다.

- 만약 하나의 프로세스가 A라는 파일을 3번 open한다면, A의 File Table Entry가 3개 생성된다.

- 테이블 Entry 안에는 open_flag, file_offset, ref_cnt, VFS table을 가리키는 포인터가 들어있다.

- FD 테이블의 각 항목은 FD 플래그와 파일 테이블로의 포인터를 가지고 있다. 이 포인터를 이용하여 FD 를 통해 시스템의 파일을 참조 할 수 있다. 프로세스는 이런 FD 테이블과 파일 테이블의 정보를 직접 고칠 수 없으며, 반드시 커널을 통해서 수정을 해야 한다.

VFS i-node Table (Virtual File System i-node Table)

- 프로세스들이 사용하고 있는 파일의 i-node를 담고 있는 테이블이다. File Table과는 달리, 만약 하나의 프로세스가 A라는 파일을 3번 open해도 i-node Table Entry는 하나밖에 할당되지 않는다.

- i-node 안에는 i-node 번호, 파일 종류와 권한, 크기, 데이터 블록을 가리키는 포인터 등의 파일 정보가 들어있다.

i-node Table Entry에는 i-node, ref_cnt가 들어있다.

* FD 할당 및 접근 과정

만약 프로세스가 fileA라는 파일을 쓰기권한으로 open한다고 하자. fd = open("fileA", O_WRONLY);

1. 커널은 File System에서 fileA를 찾아, 해당 파일의 i-node를 가져와 VFS i-node table의 빈 공간(Entry)에 할당.

만약 fileA의 i-node가 이미 할당되어있는 경우, ref_cnt(reference counter)만 하나 증가시킨다.

2. i-node 정보에 담겨있는 접근 권한을 찾아, 쓰기 권한(O_WRONLY)을 허용하는지 확인한다.

3. 권한이 있다면 file table의 Entry에 open_flag, file_offset, ref_cnt, VFS i-node table entry 포인터 등의 정보를 할당한다.

4. File descriptor table을 index 0부터 탐색해서, 빈 공간에 file table entry를 가리키는 포인터를 저장한다.

5. 저장한 곳의 index를 반환한다.

6. FD 통해서 접근

7. FD 사용이 끝나면 ref_cnt-- => ref_cnt == 0 이면 file table entry 삭제

8. file table entry 삭제 -> VFS inode 엔트리에 참조 카운트 값 감소 => 참조 카운트 값이 0이면(해당 파일 정보에 접근 중인 프로세스 수 == 0이면) VFS inode table entry 삭제

파일 제어 블록(FCB:File Control Block) / 유닉스에선 inode

- 파일을 관리하기 위한 metadata를 보관하는 파일제어 블록

- 보조기억장치에 존재하다가 파일이 오픈되면 주기억장치로 이동- 파일시스템이 관리하며 사용자가 직접 참조 불가
- 파일마다 독립적으로 가지며 시스템마다 다른 내용을 가짐

파일 디스크립터의 정보

파일 이름 및 파일 크기
보조기억장치에서의 파일 위치
파일 구조 : 순차 파일, 색인 순차 파일, 색인 파일 등
보조기억장치의 유형 : 자기 디스크, 자기 테이프 등
액세스 제어 정보
파일 유형 : 텍스트 파일, 목적 프로그램 파일(2진 파일, 기계어 파일, 실행 파일)
생성 날짜와 시간, 제거 날짜와 시간
최종 수정 날짜 및 시간
액세스한 횟수 : 파일 사용 횟수

10.2 접근 방법

파일에 접근하여 데이터를 읽는 방법

10.2.1 순차 접근

가장 간단한 방법으로 파일의 정보가 레코드 순서대로 차례차례 처리된다.

현재 위치를 가리키는 포인터에서 읽기/쓰기 시스템 콜이 발생한 경우 포인터를 앞으로 보내면서 읽거나/쓴다. 뒤로 돌아가기 위해서는 지정한 offset 만큼 되감기를 하여야 한다.
테이프 모델에 기반을 두고 있다.

10.2.2 직접 접근

직접 접근 또는 상대 접근 특별한 순서 없이 빠르게 레코드를 읽고 쓸 수 있다. 디스크 모델에 기반을 두며 이는 무작위 파일 블록에 대한 임의 접근(Random Access)를 허용하기 때문이다. 직접 접근의 경우 읽기나 쓰기의 순서에 제약을 가하지 않는다.
대규모 정보를 즉각적으로 접근하는 데 유용하여 데이터베이스에 이용된다.

현재 위치를 가리키는 변수 cp만 유지된다면 직접 접근 파일을 가지고 순차 파일 기능을 쉽게 구현할 수 있다.

10.2.3 기타 접근 방법

직접 접근 파일에 기반을 두고 색인을 구축한다. 크기가 큰 파일을 입출력 탐색할 수 있게 도와준다.

10.3 디렉터리와 디스크 구조

통상 수천 수만 수십억 개의 파일을 하드디스크, 광학 디스크,반도체 디스크를 포함한 임의 접근장치에 저장하는 방법
매우 많으므로 체계적으로 구성을 갖추어야 한다. 그래서 디렉터리의 사용을 수반한다.

볼륨 : 파일 시스템을 포함하고 있는 임의의 개체, 각 볼륨을 논리적인 가상 디스크로 취급될 수 있다. 하나 이상의 운영체제를 저장하고 부팅, 실행시킬 수 있다. 섹터들의 집합으로 연속공간이 아니어도 볼륨으로 볼 수 있다.
디바이스 디렉터리(디렉터리) : 그 볼륨에 있는 모든 파일에 대한 이름, 위치, 크기, 타입과 같은 정보를 기록한다.
파티션 : 연속된 저장 공간을 하나 이상의 연속되고 독립적인 영역으로 나누어서 사용할 수 있도록 정의한 규약

10.3.1 저장장치의 구조

범용 컴퓨터 시스템은 다수의 저장장치를 가지고 그 장치들은 파일 시스템을 저장할 수 있는 볼륨으로 분할된다.
파일 시스템이 없을 수도 있으며, 다양한 종류의 파일 시스템을 가질 수도 있다.

10.3.2 디렉터리 개관

디렉터리는 파일 이름을 해당 디렉터리 항목으로 변환해주는 심벌 테이블로 볼 수 있다. 따라서 다양한 방법으로 구성될 수 있다.

파일 찾기 : 특정 파일에 해당하는 항목을 찾기 위해 탐색이 가능해야 한다. 특정 패턴과 일치하는 이름을 갖는 모든 파일을 찾을 수 있어야 한다.
파일 생성 : 새로운 파일들을 생성하여 디렉터리에 추가한다.
파일 삭제 : 디렉터리에서 파일 제거
디렉터리 나열 : 존재하는 파일들을 나열하고 내용을 보여준다.
파일의 재명명 : 이름 바꾸기
파일 시스템의 순회(Traverse) : 파일 시스템의 모든 디렉터리를 순회하면서 모든 파일들을 액세스할 필요가 있다. 전체 파일 시스템을 주기적으로 백업할 때.

10.3.3 1단계 디렉터리

가장 간단한 구조의 디렉터리
파일이 많아지거나 다수의 사용자가 사용할 경우 심각한 제약이 따른다.
각 파일들은 서로 유일한 이름을 가진다. 서로 다른 사용자라 하더라도 같은 이름을 사용할 수 없다.

10.3.4 2단계 디렉터리

사용자들에게 개별적인 디렉터리를 만들어 준다.

UFD(User File Directory) : 자신만의 사용자 파일 디렉터리, 비슷한 구조를 가지고 있지만 오직 한 사용자만의 파일을 저장한다
MFD(Master File Directory) : 사용자의 이름이나 계정 번호로 색인되어 있고, 각 엔트리는 사용 자의 UFD를 가리킨다.

특정한 파일을 참조할 시 사용자의 UFD 에서만 탐색하므로 파일 이름이 충돌하는 문제가 사라진다.
다른 사용자의 파일에 접근해야 하는 경우는 단점이 된다.

10.3.5 트리 구조 디렉터리

2단계 구조 디렉터리를 확장하여 다단계 트리 구조로 만들 수 있다. 사용자들이 자신의 서브디렉토리를 만들어서 파일을 구성할 수 있게 한다. 트리 구조는 하나의 루트 디렉터리를 가지며 시스템의 모든 파일은 고유 경로를 가진다.
디렉터리의 각 항목은 한 비트를 사용하여 일반 파일인지 (0) 디렉터리 파일인지(1)를 구분한다.

통상적으로 각 프로세스는 현재 디렉터리를 가지고 있다.
디렉터리의 경로명을 지정할 때에는 절대경로명과 상대경로명 두 가지가 있다.

10.3.6 비순환 그래프

사이클이 없는 그래프는 디렉터리들이 서브디렉터리와 파일들을 공유할 수 있도록 허용한다.
트리 구조의 디렉터리를 자연스럽게 일반화한 방식이다.
절대경로명/상대경로명을 이용하여 링크 라고 불리는 새로운 디렉터리 항목을 만들 수 있다.
단순한 트리 구조보다는 융통성이 있는 대신에 더 복잡하다.
파일을 삭제할 때 대상이 없는 포인터(dandling pointer) 를 남긴다.
참조되는 파일에 참조 계수를 두어 계산한다. 참조 계수가 0이 되면 현재 파일을 참조하는 링크가 존재하지 않으므로 파일을 삭제할 수 있다.

10.3.7 일반 그래프 디렉터리

디렉터리에서 순환이 허용되는 겨우 무한 루프에 빠질수도 있다. 따라서 순환이 발생하지 않도록 하위 디렉터리가 아닌 파일에 대한 링크만 허용하거나 가비지 컬렉션을 이용하여 전체 파일 시스템을 순회하고, 접근 가능한 모든 것을 표시한다.
디렉토리를 순회할 때 링크가 있으면 우회하여 순환을 피할 수도 있다.

10.4 파일 시스템 마운팅

- 파일이 사용되기 전에 열리는 것 처럼 프로세스들이 파일 시스템을 사용하기 전에는 먼저 마운트해야 함
- 디바이스 이름과 마운트 포인트 위치를 전달하여 마운트

마운트 된 이후에는 마운트 된 파일 시스템만 접근하게 한다.

두 개의 파일 시스템이 마운트 되기 전 삼각형은 서브디렉토리를 의미한다.
b 파일 시스템이 a의 /users에 마운트된 경우. 기존 a 시스템에 있뎐 /users/fred/help는 마운트가 해제되기 전까지 접근할 수 없다.

10.5 파일 공유

10.5.1 다수의 사용자

디렉터리 구조가 사용자 간의 파일 공유를 허용한다면, 시스템은 파일 공유를 중재해야 한다. 대부분의 시스템은 파일/디렉터리의 소유자,그룹 이라는 개념을 사용하는 형태로 발전해왔다.
UNIX 시스템의 소유자는 파일에 대한 모든 작업을 실행할 수 있지만 그룹 멤버는 일부 작업만을 실행할 수 있다.

10.5.2 원격 파일 시스템

네트워크를 이용하여 원거리 컴퓨터 간의 통신을 하면서 파일 시스템을 공유하는 방법.

10.5.2.1 클라이언트 서버 모델

서버 : 파일을 제공하는 컴퓨터
클라이언트 : 파일을 요청하는 컴퓨터
클라이언트의 신원 확인 : ip나 네트워크 이름 등의 식별자는 도용(spoofing)이나 모방(imitation)될 수도 있기에 인증 과정이 필요하다.
원격 파일시스템이 마운트되면 로컬 파일 시스템에 적용하는 semantic(정책)과 유사한 의미를 적용하거나 다른 의미를 사용할 수도 있다.

10.5.2.2 분산 정보 시스템

10.5.2.3 고장 모드

고장 모드를 따로 두고 파일 시스템에 오류가 발생시 대처

10.5.3 일관성의 의미 Consistency Semantics

파일 시스템의 관리 정책의 일관성에 대하여

10.5.3.1 UNIX의 semantics

열린 파일에 대한 사용자의 쓰기는 동일 파일을 연 다른 사용자들에게 즉시 보인다.
공유 모드 : 사용자들이 파일 내의 현재 위치 포인터를 공유한다. 여럿이서 파일 위치 포인터를 같이 쓴다

10.5.3.2 세션 semantics

앤드류 파일 시스템
열린 파일에 대한 쓰기는 동시에 같은 파일을 연 다른이에게 보이지 않는다.
파일이 닫히면 파일에 대한 변경들이 나중에 시작되는 세션에서만 보인다.
사용자들은 지연 없이 그들의 파일 이미지에 대해 병행적으로 읽기와 쓰기 모두를 실행할 수 있다.

10.5.3.3 불변 공유 파일의 semantics

파일이 공유된다고 선언되면, 더이상 변경 불가능하게 만든다

10.6 보호

10.6.1 접근의 타입

접근을 허용하지 않거나/자유롭게 접근하거나 이 두가지의 접근법으로는 다양한 방법의 파일 접근/공유 절차를 커버할 수 없다. 그래서 우리는 통제된 접근 을 구현해야 한다.
사용자가 어떤 접근 타입을 가지고 오는지에 따라 파일 연산을 통제시킬 수 있다.

읽기
쓰기
실행
추가
삭제
리스팅

10.6.2 접근 제어

파일과 디렉터리에 접근 제어 리스트를 둔다(ACL Access Control List)
특정 사용자가 어떤 파일에 접근할 경우 리스트를 보고 허용 여부를 결정한다.

소유자 : 파일의 생성자
그룹 : 파일을 공유하며 소유자와 유사한 접근이 필요한 사용자들의 집합
모든 사람 : 시스템에 있는 모든 사용자들

유닉스의 경우 3 파일에 3비트 rwx 필드를 두어 접근 권한을 관리한다.
윈도우의 경우는 gui를 통해서 접근이 가능하다.

-----------------------------------------------------------------------------------

(5) 점검 및 복구

´ ext2파일시스템을 사용하면서 비정상적인 종료시에는 재부팅과정을 거치면서 파일시스템을 체크하도록 되어 있다.

체크하면서 아무런 문제가 없으면 OK 사인이 떨어지지만 문제가 발생하는 경우에는 root패스워드를 입력하라는

화면이 나타나면서 부팅을 멈추게 된다 .

´ ext3파일시스템은 자동으로 복구가 되도록 되어있지만 ext2파일시스템은 상황에 따라 관리자가 파일시스템인

복구시에 사용하는 e2fsck명령으로 복구해야 한다.

´ 파일시스템손상과 복구

1) 파일시스템의 복구가 쉬운 경우: 이 경우에 /etc/fstab파일에 check가 설정되어 있으면 자동으로 복구시킨다.

ㄱ. 참조되지 않은 inode

ㄴ. 납득할 수 없이 큰 링크의 갯수

ㄷ. 블록맵에 기록되지 않거나 사용되지 않는 데이터블록

ㄹ. 파일에서 사용하고 있지만 비어있다고 기록된 데이터블록

ㅁ. 슈퍼블록에서 부정확한 요약정보

2) 파일시스템의 복구가 어려운 경우 : e2fsck같은 명령어를 이용하여 수동복구해야 한다.

ㄱ. 하나이상의 파일이 요구되는 블록

ㄴ. 파일시스템의 범위밖에서 요구하는 블록

ㄷ. 너무 작은 링크의 개수

ㄹ. 셀수없는 블록

ㅁ. 할당되지 않는 inode를 가리키는 디렉토리

ㅂ. 다양한 포맷 에러

출처: https://euless.tistory.com/22 [Bite the Bullet]

참고) 파일 시스템의 종류

2.1. FAT

FAT(File Allocation Table) 파일 시스템은 빌 게이츠와 마크 맥도널드가 1976년부터 1977년에 이르는 기간 동안 개발
FAT라는 이름은 어느 영역에 파일이 속해 있는지, 공간에 여유가 있는지, 또 어디에 각 파일이 디스크에 저장되어 있는지에 대한 정보를 중심으로 하는 테이블을 이용하는 것에서 비롯한다.
상대적으로 간단한 파일 시스템. 성능은 상대적으로 다른 파일 시스템보다 좋지 않다. 너무나도 단순한 자료 구조 사용을 사용하고, 조그마한 파일이 많으면 공간 활용률이 적어지기 때문이다.

2.1.1. FAT12

MS-DOS 초기부터 주로 쓰임
플로피 디스크에서 사용

2.1.2. FAT16

32메가바이트 이상의 하드 디스크를 지원하기 위해 MS-DOS 3.0과 함께 나왔으며 윈도우 95까지 주로 이용되었다.
최대 2기가바이트 파티션을 지원한다.

2.1.3. FAT32

FAT32(File Allocation Table 32) 오래되고 많이 사용되는 파일 시스템
지원하는 드라이브 최대 용량 : 32GB
파일 하나당 저장할 수 있는 최대 크기 : 4GB
안정성이 좋다.
다양한 OS, 기기에 대한 호환성이 좋다.

2.1.4. exFAT

exFAT(Extended File Allocation Table)는 NTFS의 호환성 문제를 극복하기 위하여 개발된 방식. FAT64라고도 한다.
지원하는 드라이브 최대 용량 : 사실상 제한 없음
파일 하나당 저장할 수 있는 최대 크기 : 사실상 제한 없음
안정성이 떨어짐. USB 안전제거 방식이 아니라 그냥 뽑는 경우 파일 소실 가능성 존재.

2.2. NTFS

NTFS(New Technology File System)는 FAT32의 약점을 보완하기 위해 개발된 파일 시스템
지원하는 드라이브 최대 용량 : 256TB
파일 하나당 저장할 수 있는 최대 크기 : 16TB
윈도우에서는 최적화되어 있으나 Apple의 MAC OS, Google의 Android, Linux와 같은 기기에서 사용에 제한이 있다.

2.3. ext

ext(extended file system, 확장 파일 시스템)는 리눅스용 파일 시스템 가운데 하나로, 오늘날 많은 리눅스 배포판에서 주 파일 시스템으로 쓰이고 있다.

2.3.1. ext2

ext(extended file system, 확장 파일 시스템)를 대체하기 위해 고안

2.4. HFS

계층적 파일 시스템(Hierarchical File System, HFS)은 애플이 맥 OS를 구동하는 컴퓨터 시스템에 사용할 목적으로 개발한 파일 시스템

2.5. APFS

APFS 혹은 애플 파일 시스템(Apple file system, APFS)은 애플에서 macOS, iOS, watchOS, tvOS등에서 범용으로 사용하고자 만드는 파일시스템

http://melonicedlatte.com/computerarchitecture/2020/03/02/204500.html

https://sangminlog.tistory.com/entry/file-system?category=887652

https://jess2.tistory.com/84

https://euless.tistory.com/22

https://twofootdog.tistory.com/51

https://dev-ahn.tistory.com/96

https://m.blog.naver.com/songblue61/221391888403

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=jvioonpe&logNo=220377775960

https://dongwook8467.tistory.com/131

https://velog.io/@yonii/OS-%ED%8C%8C%EC%9D%BC%EA%B4%80%EB%A6%AC

https://velog.io/@underlier12/OS-32-Inode-%EB%B0%A9%EC%8B%9D-VFS

https://bywords.tistory.com/entry/Operating-Systems-File-Systems

https://copycode.tistory.com/129

https://comyoung.tistory.com/109

'전공 > 운영체제' 카테고리의 다른 글

[OS과제] SYS (0)	2022.04.26
[운영체제,OS] 전공 필기시험 정리 (0)	2022.04.01
메모리 1 - 구조 / 종류 / 관리 / 정책 / 단편화 (0)	2022.02.23
[2장] 운영체제 개요 (0)	2020.06.29