우리가 write() 시스템 콜을 호출하여 파일에 문자 하나를 기록했다고 가정해 봅시다. 이 문자는 결국 디스크의 어디에 저장될까요? 커널은 "이 파일의 N번째 바이트가 디스크의 M번째 블록에 위치한다"는 사실을 어떻게 기억하고 관리할까요?

지금까지 파일시스템을 다룰 때는 주로 VFS, 아이노드, 덴트리, 페이지 캐시 등 "운영체제가 파일을 바라보는 논리적 관점"에 집중했습니다. 이번 장에서는 시각을 넓혀 디스크의 물리적 구조를 살펴봅니다. 오랜 기간 리눅스의 표준으로 활약했던 Ext2와, 그 구조적 기반 위에 저널링을 도입한 Ext3가 이번 강의의 핵심 주제입니다.

이번 강의는 크게 네 가지 주제로 나뉩니다. 첫째, Ext2의 구조적 효율성과 견고성. 둘째, 슈퍼블록, 그룹 디스크립터, 비트맵, 아이노드 테이블의 디스크 물리적 배치. 셋째, 마운트 이후 메모리 상에서의 캐싱 메커니즘. 마지막으로 디스크 공간의 할당 및 해제 알고리즘과 Ext3 저널링을 통한 복구 최적화 원리입니다.

초기 리눅스는 MINIX 파일시스템을 기반으로 출발했으며, 이후 Ext(Extended Filesystem)가 등장했지만 성능 면에서 다소 아쉬움이 있었습니다. 1994년에 도입된 Ext2는 혁신적인 설계와 뛰어난 성능, 견고성을 바탕으로 Ext3와 더불어 오랫동안 리눅스를 대표하는 파일시스템으로 활약했습니다.

파일시스템은 갑작스러운 전원 차단이나 커널 패닉 등 예기치 않은 시스템 장애에 항상 대비해야 합니다. 장애 발생 순간, 데이터가 갱신되다 만 '중간 상태(Inconsistent state)'가 파일시스템 전체에 얼마나 치명적인 영향을 미치는지가 시스템 견고성의 핵심 척도입니다.

Ext2는 메타데이터를 갱신할 때 작업의 순서를 매우 엄격하게 통제합니다. 예를 들어 새로운 하드 링크를 생성할 때, 반드시 디스크 아이노드의 링크 카운터를 먼저 증가시킨 후 디렉터리에 새로운 엔트리를 추가합니다. 만약 순서를 반대로 했을 때 시스템이 다운된다면, 디렉터리가 가리키는 아이노드가 유효하지 않아 심각한 데이터 손상으로 이어질 수 있기 때문입니다.

또한 Ext2는 파일의 수정을 원천 차단하는 불변 파일(Immutable file) 속성과, 데이터의 추가 기록만 허용하는 추가 전용 파일(Append-only file) 속성을 지원합니다. 추가 전용 파일은 기존 기록을 보존해야 하는 시스템 로그 파일 등을 관리할 때 매우 유용합니다.

디스크 파티션의 첫 번째 블록은 파일시스템이 직접 관리하지 않습니다. 이 공간은 시스템 부팅을 위한 '파티션 부트 섹터(Partition Boot Sector)'로 예약되어 있으며, Ext2의 본격적인 관리는 그다음 블록부터 시작되어 여러 개의 블록 그룹으로 나뉩니다.

모든 블록 그룹은 기본적으로 동일한 내부 구조를 갖습니다. 각 그룹 내에는 슈퍼블록과 그룹 디스크립터의 복사본, 데이터 블록 비트맵, 아이노드 비트맵, 아이노드 테이블, 그리고 실제 파일 데이터가 저장되는 데이터 블록들이 순서대로 자리 잡습니다.

파일시스템의 전반적인 상태를 기록하는 장부 중 가장 중요한 것은 단연 슈퍼블록(Superblock)입니다. 슈퍼블록은 해당 파일시스템의 '디지털 신분증'이자 통제 센터 역할을 합니다.

두 번째 핵심 장부는 그룹 디스크립터(Group Descriptor)입니다. 모든 블록 그룹은 각자의 디스크립터를 보유하며, 여기에는 해당 그룹 내 데이터 블록 비트맵의 위치, 아이노드 비트맵의 위치, 아이노드 테이블의 시작점, 그리고 현재 남아있는 유휴 블록 및 아이노드의 개수 등이 상세히 기록되어 있습니다.

마지막 장부는 블록의 할당 상태를 직관적으로 나타내는 비트맵(Bitmap)입니다. 비트 값이 0이면 사용 가능(Free), 1이면 사용 중(Used)을 의미합니다.

각 블록 그룹 내에 존재하는 아이노드 테이블은 디스크 아이노드 구조체들이 촘촘히 도열해 있는 연속된 블록 덩어리입니다. Ext2에서 디스크 아이노드 1개의 크기는 기본적으로 128바이트로 고정되어 있습니다. 즉, 4KB 블록 하나에는 정확히 32개의 아이노드가 빈틈없이 저장됩니다.

Ext2 시스템의 뛰어난 설계 중 하나는, 아이노드 번호를 물리적 디스크 주소로 변환할 때 별도의 룩업 테이블(Mapping table)이 필요하지 않다는 점입니다. 커널은 단순한 산술 연산만으로 특정 아이노드가 어느 블록 그룹의 아이노드 테이블 중 몇 번째 오프셋에 위치하는지 즉각적으로 도출해 냅니다.

고작 128바이트에 불과한 아이노드의 공간은 시간이 지남에 따라 점차 부족해졌습니다. 파일시스템에 더 복잡한 보안 컨텍스트나 메타데이터를 저장해야 할 요구가 늘어났기 때문입니다. 이를 해결하기 위해 Ext2는 확장 속성(Extended Attribute)이라는 개념을 도입했습니다. 넘치는 데이터를 아이노드 내부에 억지로 욱여넣는 대신 별도의 디스크 블록에 속성들을 저장하고, 아이노드의 i_file_acl 필드가 해당 블록을 가리키도록 구조를 확장한 것입니다.

이 확장 속성 인프라는 리눅스의 접근 제어 목록(ACL, Access Control List) 기능을 구현하는 데 필수적인 기반이 됩니다. 전통적인 유닉스 권한(rwx) 체계가 소유자, 소유 그룹, 기타 사용자라는 세 가지 범주로만 접근을 통제했다면, ACL은 "특정 사용자 A에게는 읽기 권한만 부여하고, 그룹 B의 접근은 전면 차단한다"와 같은 정밀한 타겟팅 보안을 가능하게 합니다.

일반적으로 파일은 곧 데이터의 집합으로 여겨지지만, 커널 내부에서 다루는 파일(디렉터리, 특수 장치 파일, 파이프, 소켓 등)의 성격은 매우 다양합니다. 시스템 리소스 관점에서 중요한 명제는 "모든 파일 타입이 디스크의 데이터 블록을 소비하지는 않는다"는 사실입니다.

파일시스템의 메타데이터를 참조할 때마다 기계적으로 구동되는 물리 디스크를 읽어야 한다면 시스템은 극도로 느려질 것입니다. 병목 현상을 타파하기 위해, 시스템은 마운트 시점부터 방대한 양의 디스크 메타데이터를 고속 메모리(RAM) 영역으로 끌어올립니다.

커널 메모리 구조에서 슈퍼블록은 ext2_sb_info 구조체로 표현됩니다. VFS(가상 파일시스템) 계층이 관리하는 일반적인 super_block 객체 내부에는 개별 파일시스템의 고유 정보를 가리키는 s_fs_info 포인터가 존재하는데, Ext2 환경에서는 이 포인터가 바로 ext2_sb_info와 직접 연결됩니다. 이 거대한 구조체는 디스크 상의 슈퍼블록 필드들은 물론, 이를 담고 있는 메모리 버퍼 헤드(s_sbh)와 수백 개의 그룹 디스크립터 배열 정보까지 모두 통괄합니다.

파일시스템 마운트를 관장하는 ext2_fill_super() 함수는 호출 즉시 ext2_sb_info 객체를 메모리에 생성하고, 디스크로부터 실제 슈퍼블록 데이터와 그룹 디스크립터들을 읽어 들여 버퍼에 적재합니다. 이 복잡한 초기화 과정이 완벽히 마무리되어야만 비로소 VFS가 루트 디렉터리를 기점으로 경로 탐색(Pathname lookup)을 정상 수행할 수 있습니다.

프로세스가 파일에 접근하여 VFS가 특정 디스크 아이노드를 메모리로 호출하면, 커널은 이 정보를 바탕으로 ext2_inode_info라는 통합 객체를 동적으로 생성합니다. 이 거대한 캡슐 안에는 표준적인 vfs_inode 객체뿐만 아니라, 오직 Ext2 구동에만 필요한 심화 메타데이터들이 한데 어우러져 있습니다.

초기 파티션을 포맷하는 mke2fs 유틸리티의 동작 과정도 흥미롭습니다. 이 프로그램은 파티션 공간을 분석하여 블록 크기와 아이노드 비율을 최적화한 뒤, 텅 빈 디스크 위에 슈퍼블록과 디스크립터의 뼈대를 세웁니다. 모든 비트맵을 0으로 초기화하고 깨끗한 아이노드 테이블을 구축한 뒤, 최종적으로 최상위 루트(/) 디렉터리와 시스템 복구용 lost+found 디렉터리를 생성하며 작업을 마무리합니다.

가상 파일시스템(VFS)은 커널 내부에서 "아이노드를 읽어라", "파일에 데이터를 써라", "디렉터리에서 특정 이름의 파일을 찾아라" 같은 추상적이고 보편적인 지시를 내립니다. 디스크 레이아웃이 각기 다른 수많은 파일시스템은 이러한 인터페이스를 수용하기 위해 저마다 특화된 세부 함수표(Method Table)를 VFS에 등록해야 합니다.

아이노드 오퍼레이션의 경우 타겟 파일의 속성에 따라 연결되는 함수가 극명하게 갈립니다. 디렉터리 타입의 아이노드에는 create, lookup, mkdir, rename 등 트리 계층의 네임스페이스를 관리하는 함수들이 매핑됩니다. 반면 정규 파일에는 truncate, 파일 권한 갱신, 확장 속성 관련 함수들이 매핑되어 데이터 자체를 제어합니다.

성능이 뛰어난 파일시스템 설계자들은 항상 두 가지 난제와 싸웁니다. 첫째는 사용 시간이 길어질수록 파일이 쪼개지는 파편화(Fragmentation) 현상을 억제하는 것이고, 둘째는 파일의 특정 논리적 오프셋을 던져주었을 때 그 위치에 대응하는 실제 물리 디스크 블록을 최대한 빠르게 찾아내는 것입니다.

새로운 아이노드를 발급하는 핵심 함수인 ext2_new_inode()는 아무 빈자리나 무작정 선택하지 않습니다. 새로 생성될 파일이 디렉터리인지 정규 파일인지 그 성격에 따라 고도의 휴리스틱 전략을 구사합니다.

일반적인 애플리케이션 프로그램은 파일을 끊김 없이 연결된 1차원 바이트 배열로 취급합니다. 즉 "파일의 처음부터 5,000번째 오프셋에 있는 문자열"과 같은 방식으로 접근합니다. 하지만 실제 물리 디스크 상에서 그 데이터 블록들이 항상 연속적으로 나열되어 있는 것은 아닙니다. 그렇다면 커널은 애플리케이션의 이 논리적인 오프셋 요구를 어떻게 실제 디스크 블록 좌표로 정밀하게 치환해 낼까요?

파일 홀(File hole)이란, 애플리케이션이 파일의 특정 위치로 포인터를 강제로 건너뛰어(Seek) 뒷부분에만 데이터를 기록했을 때, 앞부분에 생겨난 거대한 '공백 지대'를 의미합니다. 터미널의 cat 명령어로 읽어보면 이 공백 영역이 전부 널 문자(Null character)의 바다처럼 보이지만, 운영체제는 이 허상의 공백 구간에 귀중한 디스크 물리 블록을 낭비하여 할당하지 않습니다.

파일 내용이 추가되어 새로운 물리 데이터 블록을 발급받아야 할 때, ext2_new_block() 커널 함수는 치명적인 디스크 단편화 현상을 억제하기 위해 대단히 치밀한 위치 선정 로직을 거칩니다.

사용자가 파일을 삭제하거나 길이를 강제로 0으로 잘라내면(Truncate), 시스템은 기존에 점유하던 방대한 데이터 블록 자원을 즉각적으로 환수해야 합니다. 해제 루틴인 ext2_truncate() 함수는 아이노드의 i_block 배열을 꼼꼼히 역추적하며 다이렉트 블록은 물론이고 거미줄처럼 엮인 다중 인다이렉트 포인터 트리 구조를 일망타진합니다. 여기서 명심할 점은 말단에 매달린 실제 데이터 덩어리뿐만 아니라, 주소 좌표만을 보관하고 있던 인다이렉트 중계 블록들조차 용도를 다했다면 한 치의 오차 없이 함께 파기해야 한다는 것입니다.

공간 해제의 최종 물리적 타격은 ext2_free_blocks() 함수가 집행합니다. 할당되어 있던 해당 블록 번호의 비트맵 영역을 0으로 깨끗이 소거(Clear)하고, 지역 그룹 디스크립터 내부의 가용 블록 카운터(bg_free_blocks_count) 수치를 높이며, 글로벌 슈퍼블록의 누적 유휴 블록 수치까지 함께 연동 상승시킵니다. 시스템 메커니즘 관점에서 무언가를 생성한다는 것은 '비트맵의 불을 켜고(1) 잔고 카운터를 깎는 행위'이고, 파괴한다는 것은 '비트맵의 불을 끄고(0) 카운터 잔고를 복원하는 행위'에 불과합니다.

고전적인 파일시스템이 가진 가장 치명적인 아킬레스건은 어플리케이션이 요구한 수정 사항들이 곧바로 단단한 물리 디스크 원판에 긁혀 기록되지 않는다는 데 있습니다. 최적화를 명목으로 수많은 변경 블록들이 휘발성 램(RAM) 영역에 아슬아슬하게 머물다 한꺼번에 쏟아져 내려가는데(Flush), 이 절체절명의 타이밍에 전원 공급이 끊기면 대참사가 벌어집니다. 어떤 메타데이터 파편은 운 좋게 디스크에 안착했지만, 연결고리가 되는 나머지 파편들은 여전히 메모리 공중에서 증발해버려 전체 파일시스템이 앞뒤가 맞지 않는 '불일치 상태(Inconsistent state)'에 빠져버리는 것입니다.

Ext3 시스템 설계자들은 모든 서버 관리자의 요구사항이 획일적이지 않다는 점을 이해했습니다. 그래서 무엇을 어디까지 장부(Journal)에 꼼꼼히 기록할 것인지 그 수위를 관리자가 직접 선택할 수 있는 세 가지 파생 모드를 제공합니다. 이 선택에 따라 디스크 I/O 성능과 최악의 사고 시나리오에서의 데이터 보존 한계선이 극명하게 갈립니다.

고도화된 모듈화 철학을 따르는 리눅스 커널에서, Ext3 파일시스템 모듈 하나가 무거운 저널 장부의 관리 스택 전체를 혼자 짊어지지는 않습니다. 대신 이 무거운 짐을 범용 커널 레이어인 JBD (Journaling Block Device) 서브시스템으로 우아하게 떠넘깁니다. Ext3의 눈에 보이지 않는 저널 데이터베이스는 일반 파일시스템 루트 최상단에 은밀하게 몸을 숨긴 .journal이라는 이름의 특수 파일 형태로 디스크 공간을 점유하고 있습니다.

사용자 영역(User-space) 애플리케이션에서 Ext3 디스크 위에 둥지를 튼 평범한 텍스트 파일에 write() 시스템 콜 탄환을 발사했다고 칩시다. 이 한 줌의 데이터 쪼가리가 도대체 어떤 험난한 미로를 뚫고 JBD 엔진의 검문소를 통과하여 최종 물리 디스크 원판에 아로새겨지는 것일까요?