🌸🌸🌸블로그 글은 복습 겸 gitbook의 순서에 따라 번역 및 관련 내용에 JK피셜을 달아 정리할 예정이다. 말그대로 JK피셜인 칸큼 100%맞는 말은 아닐 수 있다는 거 참고해주길 바란다.

📖 Gitbook 내용 📖

이번주차도 gitbook을 찬찬히 읽으면서 os를 이해해보자.

Introduction

이전의 두 과제에서는 파일 시스템이 내부적으로 어떻게 구현되어 있는지에 대해 신경쓰지 않고 광범위하게 사용했었습니다. 이번 마지막 과제에서는, 당신은 파일 시스템의 구현을 발전시키게 될 겁니다. filesys 디렉토리에서 주로 작업하게 될 겁니다.

프로젝트2 또는 프로젝트3를 바탕으로 프로젝트4를 진행하면 됩니다. 각각의 경우, 프로젝트2에서 구현했던 모든 기능이 filesys를 진행하면서 똑같이 작동해야 합니다. 만약, 프로젝트 3을 바탕으로 진행했다면 프로젝트3에서 구현한 기능 역시 작동해야 합니다. 또한 VM 기능을 활성화시키기 위해서는  filesys/Make.vars 을 수정해야 합니다. VM 기능이 비활성화시켰다면 10% 감점할 예정입니다. 페이지 캐시를 구현하기 위해선 VM기능이 필요합니다.

Indexed and Extensible Files

기본 파일 시스템은 파일들을 단일 면적에 할당하기 때문에 외부 단편화에 취약합니다. 즉, n개 블록이 비어 있는데도 불구하고 (외부 단편화가 되어 서로 떨어져 있다면) n개 길이의 블록이 할당될 수 없다는 말입니다.
이 말은 실제 구현에서 직접, 간접, 이중 간접 블록들을 사용하는 인덱스 구조를 사용해야 할지도 모른다는 것을 의미합니다. 이전 학기에서는, 당신이 ‘멀티레벨 인덱싱을 사용하는 Berkeley 유닉스 FFS’라고 배웠던 방식 비슷한 것을 대부분의 학생들이 채택했습니다. 그러나 당신의 삶을 보다 쉽게 만들어주기 위해서, 저희는 더 쉬운 방법으로 구현하게끔 했습니다. 바로 FAT이죠. 당신은 반드시 주어진 스켈레톤 코드로 FAT을 구현해야 합니다. 당신의 코드는 멀티레벨 인덱싱 (강의에서 FFS로 배웠던)을 포함해서는 안됩니다. 그러면 file growth 파트에서 0점을 받을 겁니다.
알아두세요:
당신은 파일 시스템 파티션이 8MB보다 크지 않을 것이라고 가정해도 좋습니다.
당신의 구현은 메타데이터를 제외한 파티션 크기만큼의 큰 파일들을 지원해야 합니다.
(FILESIZE) ≤ (PARTITION SIZE) - (METADATA)
각 inode는 하나의 디스크 섹터에 저장됩니다. 그 섹터가 담을 수 있는 만큼으로 블록 포인터의 수가 제한됩니다.

Indexing large files with FAT (File Allocation Table)

경고 : 이 문서는 여러분이 강의를 통해 일반적인 파일 시스템과 FAT의 기본 이론을 이해했다는 가정하에 작성되었습니다. 해당 내용에 대한 이해가 없다면, 강의 노트로 돌아가서 파일 시스템과 FAT가 무엇인지 이해하십시오.

당신이 이전 프로젝트들에서 사용했던 기본 파일시스템에서는, 파일이 여러 디스크 섹터에 걸친 연속된 단일 덩어리에 저장되었습니다.
연속된 덩어리를 클러스터 라고 부릅시다. 왜냐하면 클러스터(덩어리)는 하나 이상의 연속된 디스크 섹터를 담을 수 있기 때문입니다. 이러한 관점에서, 기본 파일 시스템에서 클러스터의 사이즈는 곧 클러스터에 저장된 파일의 크기를 의미했습니다.

외부 단편화를 경감시키기 위해, 우리는 클러스터의 사이즈를 줄일 수 있습니다 (가상 메모리에서의 페이지 사이즈를 떠올려보세요). 단순화를 위해, 우리의 스켈레톤 코드에 있는 클러스터 내의 섹터 개수를 1로 수정했습니다. 이런 작은 클러스터를 쓰면, 전체 파일을 담기에는 클러스터의 크기가 충분치 않을 수 있습니다. 이 경우, 우리는 한 파일을 위한 여러 개의 클러스터를 필요로 하며, 그렇기 때문에 inode에 있는 파일을 위한 클러스터를 인덱싱하기 위한 자료구조가 필요합니다.
가장 쉬운 방법은 링크드 리스트 (체인이라고도 불리는)를 사용하는 것입니다. inode는 파일의 첫번째 블록의 섹터 넘버를 포함할 수 있고, 첫 번째 블록은 두 번째 블록의 섹터 넘버를 포함할 수 있습니다. 왜냐하면 만약 우리에게 필요한 블록이 마지막 블록 뿐일지라도, 파일의 모든 블록을 읽어야 하기 때문입니다.
이것을 극복하기 위해, FAT (File Allocation Table, 파일 할당 테이블)을 사용하는데, 이렇게 하면 각 블록들이 자신의 구조 안에 연결정보를 담는 대신에 고정 크기의 FAT에 블록들의 연결정보를 저장하게 됩니다. FAT이 실제 데이터가 아닌 연결정보 값만 담고 있기 때문에, DRAM에 캐시될 수 있을 만큼 충분히 작은 크기를 가지게 됩니다. 이렇게 해서, 우리는 테이블에서 상응하는 엔트리만 읽으면 되게 되었습니다.

당신은 inode 인덱싱을 filesys/fat.c에 제공되는 스켈레톤 코드와 함께 구현하게 될 것입니다. 이번 섹션에서는 fat.c에 이미 구현된 함수들과 당신이 앞으로 구현해야 하는 내용들에 대해 간략하게 설명해 보겠습니다.

우선, fat.c에 있는 6개의 함수들 (i.e. fat_init(), fat_open(), fat_close(), fat_create(), and fat_boot_create())은 부팅 시에 디스크를 초기화하고 포맷하기 때문에, 이들을 수정할 필요는 없습니다. 하지만 당신은 fat_fs_init() 함수를 작성하고, 이들이 하는 일이 어떤 도움이 될지를 간략하게 이해해야 할 겁니다.

FAT 파일 시스템을 초기화합니다. 당신은 fat_fs의 fat_length와 data_start 필드를 초기화해야 합니다. fat_length는 파일시스템에 몇 개의 클러스터가 있는지에 대한 정보를 저장하고, data_start는 어떤 섹터에서 파일 저장을 시작할 수 있는지에 대한 정보를 저장합니다. 당신은 어쩌면 fat_fs->bs 에 저장된 값을 이용하고 싶어질 수도 있습니다. 또한, 이 함수에서 다른 유용한 데이터를 초기화하고 싶어질수도 있습니다.

cluster_t fat_fs_init (void);

clst 인자(클러스터 인덱싱 넘버)로 특정된 클러스터 뒤에 다른 클러스터를 추가함으로써 체인을 연장합니다.
만약 clst가 0이라면, 새로운 체인을 만듭니다.
새롭게 할당된 클러스터의 넘버를 리턴합니다.

cluster_t fat_create_chain (cluster_t clst);

clst로부터 시작하여, 체인으로부터 클러스터를 제거합니다. pclst는 체인에서의 clst 직전 클러스터여야 합니다. 이 말은, 이 함수가 실행되고 나면 pclst가 업데이트된 체인의 마지막 원소가 될 거라는 말입니다. 만일 clst가 체인의 첫 번째 원소라면, pclst의 값은 0이어야 할 겁니다.

void fat_remove_chain (cluster_t clst, cluster_t pclst);

클러스터 넘버 clst 가 가리키는 FAT 엔트리를 val로 업데이트합니다. FAT에 있는 각 엔트리는 체인에서의 다음 클러스터를 가리키고 있기 때문에 (만약 존재한다면 그렇다는 거고, 다음 클러스터가 존재하지 않으면 EOChain (End Of Chain)입니다), 이 함수는 연결관계를 업데이트하기 위해 사용될 수 있습니다.

void fat_put (cluster_t clst, cluster_t val);

clst가 가리키는 클러스터 넘버를 리턴합니다.

cluster_t fat_get (cluster_t clst);

클러스터 넘버 clst를 상응하는 섹터 넘버로 변환하고, 그 섹터 넘버를 리턴합니다.

disk_sector_t cluster_to_sector (cluster_t clst);

당신은 이 함수들을 filesys.c와 inode.c에서 기본 파일 시스템의 기능을 증대시키기 위해 이용하고 싶을지도 모릅니다.

File Growth

크기를 증가시킬 수 있는 파일을 구현하세요. 기본 파일 시스템에서는 파일의 생성 시에 파일 크기가 특정되었습니다. 하지만 대부분의 현대 파일 시스템에서는 파일은 크기 0으로 생성되고, 파일의 끝에서 쓰기가 이루어질 때마다 확장됩니다.

파일 크기 제한을 미리 정해두지 말아야 합니다. 물론 메타데이터를 제외한 파일 시스템의 크기를 넘어서지 않는 선에 한해서입니다. 지금은 16개 파일로 제한되어 있는 루트 디렉토리 파일도, 이제는 더 증가될 수 있어야 합니다.

유저 프로그램들은 현재 파일의 끝(EOF)을 넘어서는 탐색(seek)을 할 수 있습니다. 탐색 자체로는 파일이 증가되지 않습니다. EOF를 넘어선 위치에 write하면 그 위치까지 파일을 증가시키며, 이전 EOF에서부터 write의 시작위치 사이의 빈 공간은 0으로 채워져야 합니다.
EOF를 넘어선 위치에서 read 하는 것은 어떤 바이트도 리턴하지 않습니다.

EOF를 한참 넘어서서 write 하는 것은 수많은 블록들을 완전히 0으로 만들어 버릴 겁니다. 어떤 파일 시스템들은 이런 묵시적인 0으로 이루어진 블록들을 실제로 할당하고 write 합니다. 하지만 다른 어떤 파일 시스템들은 명시적으로 write되기 전까지는 그 블록들을 할당하지 않습니다. 후자의 파일 시스템들은 “sparse files (밀도가 희박한 파일)”을 지원한다고 불립니다. 당신은 이러한 파일 시스템의 할당 전략 두가지 중 어떤 쪽이든 채택해도 됩니다.

Subdirectories

각 프로세스는 “현재 디렉터리”를 별도로 유지합니다. (프로세스가)시작할 때, 프로세스의 “현재 디렉터리” 초기값은 root 디렉터리로 설정하세요. 한 프로세스가 fork 시스템 콜로 다른 프로세스를 시작하게 하면, 그렇게 만들어진 자식 프로세스는 부모 프로세스의 “현재 디렉터리”를 상속 받습니다.
fork 이후에, 두 프로세스의 “현재 디렉터리”들은 서로 독립적이므로, 각 프로세스가 자신의 “현재 디렉터리”를 변경하는것은 다른 프로세스에게 영향을 미치지 않습니다. (이것이 바로 Unix에서의 cd 명령어가 외부 프로그램이 아닌 셸에 내장되어있는 이유입니다.)

기존의 시스템 콜을 수정해서, 호출자가 전달한 file name이 절대 또는 상대 경로인 이름을 사용할 수 있도록 하세요. 디렉터리를 구분하는 문자는 슬래시(’/’) 입니다. 또한 여러분은 Unix에서와 동일한 의미의 특별한 파일 이름들인 ‘.’ 과 ‘..’ 도 지원해야 합니다.

open 시스템 콜이 디렉터리도 열 수 있도록 수정하세요. 기존 시스템 콜 중 디렉터리에 대한 파일 식별자(fd)를 알아야 할 필요가 있는것은 close 뿐입니다.

remove 시스템 콜이 일반 파일 외에 비어있는 디렉터리(root 제외)도 삭제할 수 있게 수정하세요.
디렉터리는 하위 파일 또는 하위 디렉터리(’.’ 및 ‘..’ 제외)를 포함하지 않는 경우에만 삭제할 수 있습니다. 프로세스가 열어둔 디렉터리나, 프로세스의 현재 작업 디렉터리를 삭제하는것을 허용할 것인지 여부는 여러분이 결정할 수 있습니다. 만약 허용하게된다면, 삭제된 디렉터리 안에서 파일(’.’ 및 ‘..’ 포함)을 열거나 새로운 파일을 만드는 시도는 허용되지 않아야 합니다. 다음과 같은 새로운 시스템 콜들을 구현하세요:

프로세스의 현재 작업 디렉터리를 상대 또는 절대 경로인 dir 로 바꿉니다. 성공했다면 true를, 그렇지 않으면 false를 반환합니다

bool chdir (const char *dir);

절대 또는 상대 경로인 디렉터리 dir를 만듭니다. 성공했다면 true를, 그렇지 않으면 false를 반환합니다. 만약 dir 이 이미 존재하거나, 마지막 디렉터리 이외의 디렉터리 이름이 존재하지 않는 경우 실패합니다. 이 말은, mkdir(”a/b/c”) 는 /a/b 가 이미 존재하면서 /a/b/c 가 존재하지 않는 경우에만 성공한다는 뜻 입니다.

bool mkdir (const char *dir);

디렉터리를 나타내는 파일 식별자 fd 에서 directory entry를 읽습니다. 성공한다면, null로 끝나는 파일 이름을, READDIR_MAX_LEN + 1 bytes의 공간이 있는 name 에 저장하고 true를 반환합니다. 만일 디렉터리에 남은 항목이 없다면 false를 반환합니다.
readdir 에서 . 과 .. 을 반환하면 안됩니다. 만일 디렉터리가 열려있는 동안 변경된다면, 일부 entry들을 전혀 읽지 않거나 여러번 읽는 것이 허용됩니다. 그렇지 않다면(열려 있는 동안 변경되지 않았다면), 각 directory entry는 순서에 관계없이 한번만 읽어야 합니다.
READDIR_MAX_LEN 는 lib/user/syscall.h 에 정의되어 있습니다. 만약 파일 시스템이 기본 파일 이름보다 더 긴 파일 이름을 지원한다면, 여러분은 READDIR_MAX_LEN 의 값을 기본값인 14에서 더 늘려야 합니다.

bool readdir (int fd, char *name);

fd 가 디렉터리를 나타내면 true를, 일반 파일을 나타내면 false를 반환합니다.

bool isdir (int fd);

일반 파일 또는 디렉터리에 대한 fd 와 연관된 inode의 inode number를 반환합니다.
inode number는 파일 또는 디렉터리를 영구적으로 식별하며, 이는 파일이 존재하는 동안 고유합니다. Pintos에서, inode의 섹터 번호가 inode number로 사용되기에 적합합니다.

int inumber (int fd);

Soft Link

핀토스에서 soft link 매커니즘을 구현하세요. Soft link(일명 Symbolic link)는 다른 파일이나 디렉터리를 참조하는 유사 파일 객체입니다. 이 파일은 지정된 파일의 절대 또는 상대 경로의 방식의 경로 정보를 포함합니다. 다음과 같은 상황을 가정해보겠습니다:

/
├── a
│   ├── link1 -> /file
│   │
│   └── link2 -> ../file
└── file

/a 에 위치하는 link1 이라는 이름의 soft-link는 /file 을 (절대 경로로)가리키고 있고, /a 에 위치하는 link2 는 ../file 을 (상대 경로로)가리키고 있습니다. link1 이나 link2를 읽는다는 것은 /file 을 읽는것과 같습니다.

문자열 target을 포함하는 linkpath 라는 이름의 symbolic link를 만드세요. 성공 한다면 0이 반환되고, 실패 한다면 -1이 반환됩니다.

int symlink (const char *target, const char *linkpath);

---

💯 이론 공부 💯

정글 선배의 자료와 카이스트 강의자료를 공부해서 정리한 내용이다.

File system component

저장 장치는 HDD, SSD, CD-ROM, USB 등등, 그리고 마그네틱, 광학, 반도체 등 종류가 여러가지이다. 이렇게 다양한 저장 장치들에 정보를 저장하기 위해서는 정보를 읽고 쓸 수 있는 방법이 정리되어 있어야 한다. 이를 파일 시스템이라고 한다.

특히 파일과 디렉토리라는 두 개의 개념으로 저장 장치를 추상화할 수 있다. 즉, 저장 장치에 접근하기 위해 파일과 디렉토리라는 개념을 이용한다.

file

UNIX에서의 파일의 정의는 파일은 바이트의 선형 배열이다.다른 시스템에서는 파일이 레코드 집합, 데이터베이스 레코드 또는 키-값 쌍으로 정의될 수도 있다.

UNIX 운영 체제의 파일 시스템에서 파일은 매우 간단하게 '바이트 배열'이라고 정의 된다. 각 파일은 하위 이름으로 inode 번호를 가진다. 따라서 내부적으로 각 파일은 번호를 가지고 있다. 하지만 사용자는 파일을 숫자로 보지못하고 "hello.c"와 같은 문자열로 본다.

directory

디렉터리도 파일이며 특수한 파일이다. 디렉터리는 파일 이름과 inode 번호의 쌍으로 구성된 목록이며, 디렉터리의 개념을 사용하여 파일들을 계층 구조로 조직화할 수 있다.

file interface

인터페이스란 파일을 조작하는 함수의 집합을 말한다. 파일을 생성하는 함수를 만드는 것으로 시작한다. 파일을 생성하는 방법은 O_CREAT 플래그를 사용하여 open 시스템 콜을 호출하는 것이다. "foo"라는 이름의 파일을 생성하고 O_CREAT 플래그를 사용하며 쓰기 전용(write only)으로 생성하며 초기 크기는 0으로 설정한다. 그리고 open 시스템 콜은 파일 디스크립터를 반환한다.

각 프로세스는 파일 디스크립터 테이블이라는 정수 배열을 가지고 있다. 파일 디스크립터는 이 테이블에서의 인덱스다. 위에 교수님이 그려준 그림을 참고하면 각 엔드리의 0, 1, 2, 3, 4가 file descriptor이다. 이 테이블의 각 entry는 실제로 어떤 데이터나 객체를 가리킨다.
파일 객체에는 offset이라는 변수가 포함되어 있다. 또한 파일 객체에는 inode를 가리키는 포인터도 포함되어 있다.
파일 객체는 파일의 위치를 나타내는 offset과 관련된 가장 중요한 데이터 구조이다. offset은 파일 내에서 읽기 및 쓰기 시스템 호출이 적용되는 위치다. 이는 pintOS에서 struct file에 해당한다. 각 운영 체제는 파일 디스크립터 테이블에서의 최대 파일 디스크립터 수를 정의한다. 이는 커널의 전역 변수이며 변경될 수 있지만, 최근의 Linux에서는 파일 디스크립터 테이블의 크기가 256입니다.

strace

strace는 리눅스에서 실행 중인 프로세스의 시스템 콜(trace system call)을 추적하고 기록하는 유틸리티이다. strace를 사용하면 프로그램이 어떤 시스템 콜을 호출하는지, 해당 시스템 콜의 인자와 반환 값을 확인할 수 있다. 이를 통해 프로그램의 동작을 분석하고 디버깅하는 데 도움이 된다. strace는 프로세스의 실행 흐름과 관련된 시스템 콜 정보를 출력하므로, 디버깅이나 성능 분석 등 다양한 용도로 활용된다.

hard link vs soft link

시스템 콜 link()에서 볼 수 있듯이, 동일한 파일을 접근할 수 있는 새로운 경로명을 만들어주는 작업이다.

파일 시스템에서 하나의 파일은 하나의 아이노드로 대표된다. 기본적으로 파일은 아이노드와의 연결이라고 할 수 있다.

hard link

새로운 항목을 디렉터리에 생성하고 원래 파일과 같은 아이노드 번호를 가리키게 한다. 즉, 새 파일을 생성하고 기존의 아이노드와 연결시키는 것이다.

하드 드라이브의 어떤 특정한 구역(아이노드)을 가리킨다. 따라서 여러 파일들이 한 디스크 구역을 하드 링크한다고 했을 때, 그중 한 파일의 데이터를 바꾸면 다른 파일들의 데이터도 따라 바뀌게 된다. 기존 파일이 복사되는 것이 아니다.

하드 링크가 되면 해당 아이노드의 reference count를 1 올려준다.

하드 링크된 파일을 삭제한다는 말은 아이노드와 연결된 파일과의 연결을 끊어버린다는 것이다.

애초에 아이노드는 하나의 파일 시스템 내에서만 유일하게 존재하기 때문에, 하드 링크도 마찬가치로 같은 파일 시스템 내에서만 유효하다. 즉 서로 다른 디스크 파티션에 있는 파일에게는 하드 링크를 걸 수가 없다. 게다가 디렉토리에 대해서는 하드 링크를 걸 수가 없다. 디렉토리 구조가 사이클을 이루는 것을 막기 위해서다.

soft link(symbolic link)

마치 바로가기와 같다 하드 링크의 경우에는 하나의 파일에 접근할 수 있는 연결을 하나 더 만드는 것일 뿐이다. 이에 반해 심볼릭 링크는 새로운 유형의 파일을 새로 만들고, 심볼릭 링크 자신이 자체적인 아이노드를 가진다.

새 파일을 만들고 연결하는 파일의 경로명을 저장한다. 즉, 아이노드를 가리키는 것이 아니라 원본 파일의 이름을 가리킨다.

따라서 심볼릭 링크는 원본 파일의 아이노드의 reference count에 영향을 주지 않는다. 다시 말해, 심볼릭 링크가 삭제된다고 해도 원본 파일에는 변화가 없다.

소프트 링크는 파일뿐만 아니라 디렉터리도 링킹 가능하다. 또한 자신의 파일 시스템 바깥의 파일 혹은 디렉터리도 링크할 수 있다.

하드 링크로 만든 파일의 경우 원래 원본 파일이 지워져도 어차피 아이노드 자체를 가리키기 때문에 데이터에 접근하는 데에 변함이 없다. 하지만 소프트 링크의 경우 원본 파일을 지우면 소프트 링크가 가리키는 파일이 없어지는 것이므로 데이터에 접근할 수도 없게 된다. 이렇게 존재하지 않는 파일을 가리키는 소프트 링크를 orphaned, 아니면 dangling link라고 부른다.

VFS(Virtual File System)

가상 파일 시스템(Virtual File System, VFS)은 운영 체제에서 다양한 파일 시스템을 통합하여 추상화된 인터페이스를 제공하는 계층이다. VFS는 응용 프로그램이 파일 및 디렉터리를 조작하는 데 사용하는 표준 시스템 콜 인터페이스를 제공한다.

• 다양한 파일 시스템 지원: VFS는 여러 파일 시스템을 지원하므로 다양한 종류의 파일 시스템에 대해 일관된 인터페이스를 제공할 수 있다. 즉, 이를 통해 응용 프로그램은 파일 시스템 종류에 구애받지 않고 동일한 방식으로 파일을 다룰 수 있다.
• 확장성: 새로운 파일 시스템을 추가하기 위해 기존 VFS 인터페이스를 구현하는 것만으로 간단하게 지원할 수 있다.
• 파일 시스템 간의 상호 운용성: VFS는 다양한 파일 시스템 간의 상호 운용성을 제공한다. 즉, 서로 다른 파일 시스템에 속한 파일들을 동일한 인터페이스를 통해 통합하여 다룰 수 있다.

VFS는 다양한 운영 체제에서 사용되며, 각 운영 체제에 맞게 구현되어 있다. 예를 들어, 리눅스에서는 VFS를 통해 ext4, NTFS, FAT 등의 파일 시스템을 지원하며, 각 파일 시스템은 VFS의 표준 인터페이스를 구현하여 일관된 방식으로 파일 조작을 수행합니다.

FAT(File Allocation Table) File System

FAT 기반 파일 시스템들은 파일 시스템 내부의 모든 클러스터 하나하나에 대한 항목을 FAT 테이블에서 관리한다. 이를 통해 각각의 클러스터에 저장되어 있는 정보가 무엇인지 알 수 있다.

FAT 테이블은 하나의 단일 리스트(배열)로 관리되며, 이 테이블을 통해 어떤 클러스터가 어떤 파일에서 사용되는지, 혹은 어떤 디렉토리가 존재하는지 등을 알 수 있다.

파일의 메타데이터가 저장되는 방식

• FAT 디렉토리 테이블의 각 엔트리
  • 파일 이름
  • 시작 클러스터 번호
  • 길이
• FAT 테이블
  • 클러스터의 할당 여부
  • 해당 클러스터 사용 파일

장점

1. 새로운 파일을 만들기가 쉽다. 부모 디렉토리 테이블과 FAT의 Busy 필드 내용만 수정하면 된다.
2. 파일의 크기를 키우는 것도 쉽다. FAT의 Next 필드만 수정해주면 된다.
3. 공간 활용성도 높아진다. 파일을 섹터 단위로 쪼개어 활용할 수 있어서 외부 단편화를 예방할 수 있다.
4. 막 그렇게 빠르진 않더라도 Random Access가 가능하다.

단점

1. 모든 디스크 블록들이 각각 하나의 FAT 항목을 가지고 있으므로, 만약 굉장히 용량이 큰 디스크의 경우에는 FAT의 크기도 굉장히 커질 수 있다.
2. 이를 막기 위해서 블록 하나의 크기를 키울 수 있지만, 그렇게 되면 내부 단편화가 심해질 수 있다.

FFS (Fast File System)

초기 버전의 UNIX 운영 체제에서 사용되던 파일 시스템이다. 주로 4.2BSD와 4.3BSD 운영 체제에서 사용되었으며, 이후 다른 파일 시스템으로 대체되었다. FFS는 디스크의 블록 구조, 파일 할당 방식 및 메타데이터 구성 등을 효율적으로 설계하여 빠른 파일 시스템 성능을 제공하는 것이 목표였다.

FFS는 기본적으로 아이노드 기반 파일 시스템으로, 파일과 디렉터리의 메타데이터와 데이터 블록을 아이노드에 저장한다. 아이노드는 파일의 속성 (크기, 소유자, 권한 등)을 저장하고, 데이터 블록의 위치를 가리킨다. FFS는 여러 개의 아이노드를 갖는 파일 시스템을 지원하며, 아이노드를 인덱스로 사용하여 파일에 대한 접근을 가능하게한다.

EXT (Extended File System)

리눅스 운영 체제에서 사용되는 파일 시스템이다. 초기 버전인 EXT와 이후 개선된 버전인 EXT2, EXT3, EXT4가 있습니다. EXT2부터는 저널링(journaling) 기능이 도입되어 파일 시스템의 안정성과 복구 기능이 향상되었다.

EXT 파일 시스템은 블록 그룹(block group)이라는 단위로 디스크를 관리한다. 각 블록 그룹은 여러 개의 블록 그룹 디스크립터, 아이노드 테이블, 데이터 블록 그룹으로 구성된다. 아이노드 테이블은 파일과 디렉터리의 메타데이터를 저장하고, 데이터 블록 그룹은 실제 파일의 데이터를 저장한다.

EXT 파일 시스템은 저널링을 통해 파일 시스템의 일관성과 복구 기능을 제공한다. 저널링은 파일 시스템의 변경 사항을 로그 형식으로 기록하여 시스템이 갑작스럽게 종료되는 등의 상황에서도 데이터의 손실을 최소화할 수 있도록 한다. 이를 통해 파일 시스템의 신뢰성과 안정성이 향상되었다.

EXT 파일 시스템은 기본적으로 디스크 사용량, 파일 시스템 크기, 파일 및 디렉터리의 제한 등 다양한 기능과 옵션을 지원한다. 개선된 버전인 EXT4는 EXT3의 기능을 확장하고 성능을 개선하였다.

LFS(Log-structured File System)

LFS(Log-structured File System)는 디스크의 효율적인 사용을 위해 설계된 파일 시스템입니다. LFS는 기존의 파일 시스템과는 다른 방식으로 데이터를 저장하고 관리한다.

LFS의 주요 아이디어는 로그 구조화다. LFS는 모든 파일 시스템 작업을 로그로 기록하고 순차적으로 디스크에 저장한다. 이 로그는 시스템의 모든 파일 시스템 작업(예: 파일 생성, 수정, 삭제)을 기록하는 순차적인 연속된 데이터 블록이다.

장점

• 순차적인 디스크 액세스: LFS는 데이터를 순차적으로 기록하고 순차적으로 읽어오므로 디스크 액세스 패턴이 순차적입니다. 이는 디스크 성능을 향상시키는 장점을 가집니다.
• 가비지 컬렉션에 의한 외부 단편화 감소: 가비지 컬렉션을 통해 더 이상 사용되지 않는 데이터를 정리하므로 외부 단편화를 줄일 수 있습니다.
• 빠른 파일 시스템 작업: LFS는 로그로 모든 작업을 기록하기 때문에 파일 시스템 작업이 빠르게 수행될 수 있습니다.

단점

• 읽기 성능: LFS는 순차적인 디스크 액세스 패턴을 가지므로 랜덤 읽기 액세스에서는 성능이 저하될 수 있습니다.
• 가비지 컬렉션 오버헤드: 가비지 컬렉션 작업은 시스템 자원을 소모하므로 일부 오버헤드가 발생할 수 있습니다.
• 메타데이터 관리: LFS에서 메타데이터 관리는 중요한 측면입니다. 효율적인 메타데이터 관리를 위해 추가적인 노력이 필요합니다.