11편에서는 디스크의 물리적 구조(실린더·트랙·섹터)와 접근시간을 다뤘다. 파일 시스템(file system)은 그 물리적 저장 공간 위에 “파일”이라는 논리적 단위를 얹어, 사용자와 프로세스가 디스크의 물리 주소를 몰라도 이름만으로 데이터를 읽고 쓸 수 있게 해 주는 운영체제의 구성 요소다. 4단계 시험에서는 세 가지 파일 할당 방식의 장단점 비교와, 각 방식에서 특정 블록에 접근하는 데 필요한 디스크 접근 횟수를 계산하는 문항이 핵심이다.

파일과 디렉터리: 왜 필요한가

쉽게 말하면: 디스크는 그냥 번호 매겨진 저장 칸의 나열일 뿐인데, 파일 시스템이 그 칸들을 묶어 “이름 있는 서류철”처럼 보이게 해 준다.

디스크 컨트롤러 입장에서 디스크는 순서대로 번호가 매겨진 블록(block)의 집합일 뿐이다. 여기에 의미를 부여하는 것이 파일 시스템의 역할이다.

• 파일(file): 관련된 정보를 논리적으로 하나로 묶은 이름 있는 데이터 집합. 운영체제는 파일마다 이름, 크기, 생성·수정 시각, 접근 권한 등의 메타데이터(metadata, 데이터에 관한 데이터)를 함께 관리한다.
• 디렉터리(directory): 파일 이름과 그 파일의 실제 위치(메타데이터가 저장된 곳)를 연결해 주는 표. 흔히 “폴더”라고 부르는 것이 디렉터리이며, 디렉터리 자체도 하나의 특수한 파일로 구현되는 경우가 많다.

디렉터리는 보통 트리 구조로 구성되어, 디렉터리 안에 또 다른 디렉터리(하위 디렉터리, subdirectory)를 둘 수 있다. 이 계층 구조 덕분에 사용자는 /home/user/report.txt처럼(코드 스팬 안의 경로 표기) 경로를 따라가며 파일을 조직적으로 관리할 수 있다.

파일 할당 방식: 연속·연결·인덱스

쉽게 말하면: 파일 하나를 디스크의 여러 블록에 나눠 저장할 때, 그 블록들을 어떤 방식으로 연결해 기억해 둘지를 정하는 규칙이다.

파일 하나는 대개 디스크 블록 여러 개에 걸쳐 저장된다. 이 블록들을 어떻게 찾아가게 할지에 따라 세 가지 방식이 있다.

연속 할당(contiguous allocation)

파일의 모든 블록을 디스크에서 물리적으로 연속된 위치에 배치한다. 디렉터리에는 시작 블록 번호와 길이(블록 수)만 저장하면 된다.

시작 블록이 $b$이고 원하는 것이 파일 내 $i$번째 블록(0부터 시작)이라면, 실제 디스크 블록 번호는 다음 계산 한 번으로 바로 나온다.

연결 할당(linked allocation)

각 블록이 다음 블록의 번호를 포인터(pointer)로 담고 있어, 파일의 블록들이 디스크 여기저기 흩어져 있어도 사슬처럼 이어 찾아갈 수 있다. 디렉터리에는 첫 블록과 마지막 블록 번호만 있으면 된다.

예를 들어 파일의 10번째 블록(인덱스 9, 0부터 셈)을 읽으려면 첫 블록부터 시작해 포인터를 9번 따라가야 하므로, 디스크 접근이 총 $9+1=10$번 필요하다 — 이는 연속 할당의 1번과 크게 대비된다.

인덱스 할당(indexed allocation)

파일마다 별도의 인덱스 블록(index block) 을 하나 두어, 그 안에 파일을 구성하는 모든 블록의 번호를 순서대로 기록한다. 실제 데이터 블록에는 포인터가 없다.

인덱스 블록 하나로 부족할 만큼 파일이 커지는 문제는 연결 인덱스(linked index, 인덱스 블록끼리 사슬로 연결), 다단계 인덱스(multilevel index, 인덱스의 인덱스를 두는 방식), 다중 인덱스와 직접·간접 블록을 함께 쓰는 방식(다음 절의 inode) 으로 해결한다.

FAT와 inode: 실제 파일 시스템의 구현

쉽게 말하면: FAT는 연결 할당을 표로 모아 한 번에 관리하는 방식이고, inode는 인덱스 할당을 파일마다 압축해서 담는 방식이다.

FAT(File Allocation Table)

FAT는 연결 할당의 아이디어를 발전시킨 구조다. 각 블록에 흩어져 있던 포인터를 디스크 한 곳에 모은 표(FAT 테이블)로 관리한다. FAT 테이블의 $i$번째 항목은 $i$번 블록 다음에 이어지는 블록의 번호를 담고 있으며, 파일의 마지막 블록에는 파일 끝(EOF, End Of File)을 뜻하는 특수 값이 들어간다.

이 예시에서 report.txt는 1번 블록에서 시작해, FAT 테이블을 보면 1번 다음은 4번, 4번 다음은 2번이고 2번이 EOF이므로 파일은 1 → 4 → 2번 블록 순서로 구성되어 있다는 것을 알 수 있다. FAT 테이블 전체를 메모리에 캐시해 두면 포인터를 디스크에서 매번 읽지 않아도 되어, 연결 할당의 느린 임의 접근 문제를 상당히 완화할 수 있다. 다만 FAT 테이블 자체가 손상되면 디스크 전체의 파일 구조를 잃을 위험이 있다.

inode(index node)

유닉스·리눅스 계열 파일 시스템의 핵심 구조인 inode는 인덱스 할당을 발전시킨 방식이다. 파일마다 하나의 inode가 있으며, 그 안에는 파일의 메타데이터(권한, 소유자, 크기, 시각 등)와 함께 데이터 블록을 가리키는 포인터들이 들어 있다.

• 직접 블록(direct block) 포인터: 파일의 앞쪽 데이터 블록을 바로 가리킨다. 작은 파일은 이 포인터만으로 전체를 표현할 수 있다.
• 단일 간접 블록(single indirect block): 직접 포인터로 부족하면, 포인터 하나가 “포인터들을 모아 놓은 블록”을 가리키게 해 훨씬 많은 데이터 블록을 표현한다.
• 이중·삼중 간접 블록(double/triple indirect block): 간접 블록이 다시 간접 블록을 가리키는 방식으로, 파일이 매우 커져도 inode 하나의 고정된 크기 안에서 확장할 수 있게 한다.

이 구조는 작은 파일에서는 직접 블록만으로 접근이 빨라 효율적이고, 큰 파일에서는 간접 블록의 단계 수만큼만 디스크 접근이 늘어나 인덱스 할당의 장점(빠른 임의 접근)을 유지하면서도 인덱스 블록 하나의 크기 제한 문제를 해결한다. 시험에서는 “직접 블록 12개, 블록 크기 4KB, 포인터 하나가 4바이트일 때 표현 가능한 최대 파일 크기” 같은 계산이 나올 수 있다.

블록 크기가 4KB이고 포인터 하나가 4바이트라면, 간접 블록 하나에는 $4096 \div 4 = 1024$개의 포인터가 들어간다. 직접 블록이 12개라면, 직접 블록만으로 표현 가능한 크기는 다음과 같이 계산한다.

여기에 단일 간접 블록을 더하면 추가로 $1024 \times 4\text{KB} = 4\text{MB}$만큼 더 표현할 수 있어, 파일 크기 상한이 급격히 늘어난다. 이처럼 간접 단계가 하나씩 늘 때마다 표현 가능한 크기가 포인터 개수(1024)배씩 곱해지는 구조라는 점을 기억해 두면 계산이 빨라진다.

디스크 공간 관리

쉽게 말하면: 파일이 쓰는 블록을 관리하는 것만큼, 아직 안 쓰는 빈 블록이 어디인지 아는 것도 중요하다.

새 파일을 만들거나 기존 파일을 확장하려면 빈 블록을 찾아야 한다. 대표적인 관리 기법은 다음과 같다.

• 비트맵(bit vector/bitmap): 블록마다 1비트를 두어 사용 중이면 1, 비어 있으면 0으로 표시한다. 연속된 빈 공간을 찾기 쉽고 구현이 간단해 널리 쓰인다.
• 가용 공간 리스트(free list): 연결 할당처럼 빈 블록들을 포인터로 사슬처럼 연결해 관리한다. 비트맵보다 검색은 느릴 수 있지만 전체 블록 수만큼의 비트맵 공간이 필요 없다.
• 그룹화(grouping): 빈 블록 번호를 그룹으로 묶어 첫 번째 빈 블록에 나머지 빈 블록들의 번호를 잔뜩 저장해 두는 방식으로, 가용 공간 리스트를 조금 더 빠르게 탐색할 수 있게 개선한 방법이다.

비트맵으로 블록 8개짜리 디스크의 상태를 1 1 0 1 0 0 1 0(1은 사용 중, 0은 비어 있음)처럼 나타냈다면, 비어 있는 블록은 2, 4, 5, 7번(0부터 세었을 때)이며 이 중 4, 5번이 연속으로 비어 있으므로 두 블록짜리 연속 공간이 필요한 요청은 이 자리에 배정할 수 있다.

파일 시스템 신뢰성과 저널링

쉽게 말하면: 파일을 쓰는 도중 정전이 나도 파일 시스템 전체가 망가지지 않도록, 작업 내용을 미리 일기장에 적어 두는 것이다.

파일 시스템은 메타데이터(디렉터리, inode, 비트맵 등)를 여러 곳에 나눠 갱신해야 하는 경우가 많다. 이 갱신 도중 시스템이 갑자기 멈추면 메타데이터가 서로 앞뒤가 안 맞는 상태(불일치, inconsistency)로 남을 수 있다 — 예를 들어 비트맵에는 블록이 사용 중이라고 표시되었는데 어떤 파일의 inode에도 그 블록이 연결되어 있지 않은 상태다.

저널링(journaling) 파일 시스템은 실제로 메타데이터를 갱신하기 전에, “무엇을 어떻게 바꿀 것인지”를 저널(journal, 로그 형태의 별도 영역)에 먼저 순서대로 기록해 둔다. 갱신 도중 시스템이 멈추더라도, 다시 부팅할 때 저널을 읽어 “끝까지 기록된 작업”은 재실행하고 “중간에 끊긴 작업”은 취소해 항상 일관된 상태로 복구할 수 있다. 이 방식 덕분에 과거처럼 부팅할 때마다 디스크 전체를 검사하는 방식(예: fsck)보다 훨씬 빠르게 복구할 수 있다.

자주 틀리는 점

• 연속 할당의 장점을 인덱스 할당에도 그대로 적용한다. 임의 접근이 빠르다는 점은 세 방식 중 연속 할당과 인덱스 할당의 공통 장점이지만, 외부 단편화가 없다는 점은 연결 할당과 인덱스 할당의 공통 장점이다. 각 방식의 장단점을 표 전체로 함께 기억해야 헷갈리지 않는다.
• FAT와 inode를 그냥 같은 것으로 뭉뚱그린다. FAT는 포인터를 디스크 한 곳의 표에 모아 관리하고, inode는 파일마다 직접·간접 블록 포인터를 따로 갖는 구조다. 큰 파일을 다루는 방식(간접 블록 단계)이 FAT에는 없다는 차이가 시험 포인트다.
• 저널링을 백업(backup)과 혼동한다. 저널링은 갑작스러운 중단으로부터 메타데이터의 일관성을 지키는 기법이지, 데이터를 다른 매체에 복제해 두는 백업과는 목적이 다르다.

핵심 정리

• 파일은 데이터의 논리적 단위, 디렉터리는 파일 이름과 위치를 연결하는 표이며 보통 트리 구조로 조직된다.
• 파일 할당 방식은 연속(빠른 접근, 단편화 있음), 연결(단편화 없음, 임의 접근 느림), 인덱스(단편화 없음, 임의 접근 빠름, 인덱스 블록 필요)로 나뉜다.
• FAT는 연결 할당의 포인터를 별도 표로 모은 방식이고, inode는 직접·간접 블록으로 인덱스 할당을 파일 크기에 맞게 확장한 방식이다.
• 디스크 빈 공간은 비트맵, 가용 공간 리스트, 그룹화 등으로 관리한다.
• 저널링은 메타데이터 갱신 내용을 미리 로그에 기록해 두어, 중단 후에도 빠르고 일관되게 복구할 수 있게 한다.

마무리 복습

참고 자료

• 국가평생교육진흥원 독학학위제: https://bdes.nile.or.kr 
• 관련 심화 내용: /독학사/2단계/운영체제/16_file-system-fundamentals, /독학사/2단계/운영체제/17_file-allocation-and-directory-structure