저널링 파일 시스템

저널링 파일 시스템(영어: Journaling file system)은 주 파일 시스템에 변경사항을 반영(commit)하기 전에, 저널(주로 파일 시스템의 지정된 영역 안의 원형 로그)안에 생성되는 변경사항을 추적하는 파일 시스템이다. 시스템 충돌이나 전원 문제가 발생하면, 이러한 파일 시스템은 더 빠르게 online 상태로 돌아오며 손상될 가능성이 낮다.

원리

파일과 디렉토리 변경 사항을 반영하기 위한 파일 시스템의 업데이트에는 보통 많은 쓰기 연산이 필요하다. 따라서 쓰기 동작 중에 (전원 공급이 끊기거나 시스템 크래시 등의 이유로) 인터럽트가 발생하여 특정 데이터가 유효하지 않은 상태가 될 수 있다.

예를 들어, 유닉스 파일 시스템에서 파일을 지우면 아래의 세 단계를 거치게 된다:

1. 해당 파일의 디렉토리 엔트리를 삭제한다.
2. 파일이 사용하던 아이노드를 free inode pool로 돌려놓는다.
3. 파일이 사용하던 디스크 블록을 free disk block pool로 돌려놓는다.

파일을 삭제하던 중 1과 2 사이에서 시스템 오류가 발생한다고 가정해보자. 해당 파일의 아이노드는 디렉토리 엔트리가 존재하지 않는 orphaned inode가 된다. 스토리지 누수가 발생하는 것이다. 만약 2와 3 사이에 시스템이 크래시된다면 해당 파일이 사용하던 디스크 블록을 다시 사용할 수 없기에 스토리지 용량이 줄어드는 셈이 된다. 단계의 순서를 바꾸어도 이 문제를 해결할 수는 없다. 3과 1의 순서를 바꾸어도 그 사이에 크래시가 발생하면 파일이 사용하던 디스크 블록을 사용할 수는 있게 되지만, 일부만 삭제된 파일이 다른 파일의 데이터까지 포함하게 된다. 또한, 2와 1의 순서를 바꾸었을 때 중간에 크래시가 발생하면 파일이 접근 불가능한 상태가 된다.

이러한 오류를 검출하고 수정하기 위해서는 해당 데이터 구조의 완전한 워크(walk)가 필요하다. 오류 검출과 수정은 보통 파일시스템이 다음에 읽기-쓰기 접근을 위해 마운트되기 이전에 수행된다. 만약 파일시스템이 크고 상대적으로 I/O 대역폭이 작고, 이 작업이 나머지 시스템이 online으로 돌아오는 것을 블로킹한다면, 이는 긴 시간이 걸리고, 결과적으로 고장시간이 길어진다.

이를 막기 위해, 저널 파일 시스템은, 변경사항을 기록하는 특별한 구역(저널, journal)을 할당한다. 충돌 이후에, 단순히 파일시스템에서 저널을 읽고, 파일시스템의 오류가 복구될 때까지 저널의 변경사항을 리플레이(replay)하는 것으로 복구가 이루어진다. 따라서 변경사항은 원자적이다. 즉,

• 성공(원래부터 성공이거나 복구를 거쳐 replay가 완전히 수행됨)이거나
• 전혀 replay되지 않아야 한다.(충돌이 발생하기 전에 기록되어야 할 내용이 저널에 완전히 쓰이지 않아서 진행하지 않음)