저널링 파일 시스템
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
저널링 파일 시스템은 파일 시스템 업데이트 중 예기치 않은 중단으로 인한 데이터 손실을 방지하기 위해 고안된 기술이다. 이 시스템은 변경 사항을 저널에 기록하고, 시스템 충돌 후 저널을 재생하여 파일 시스템을 복구한다. 저널링은 파일 시스템의 메타데이터를 보호하며, 변경 사항은 원자적으로 처리되어 성공적으로 완료되거나, 전혀 적용되지 않도록 보장한다. 초기 유닉스 파일 시스템의 문제점을 해결하기 위해 개발되었으며, 다양한 운영체제에서 사용되고 있다.
더 읽어볼만한 페이지
| 저널링 파일 시스템 |
|---|
2. 원리
파일 시스템 업데이트 시 많은 쓰기 연산이 필요하며, 이 과정에서 전원 공급 중단이나 시스템 크래시 등으로 인해 인터럽트가 발생하면 데이터 불일치 문제가 발생할 수 있다.[12]
예를 들어, 유닉스 파일 시스템에서 파일을 삭제할 때는 다음 세 단계를 거친다.[7]
# 파일의 디렉토리 엔트리 삭제
# 파일이 사용하던 아이노드를 사용 가능한 아이노드 풀(free inode pool)로 반환
# 파일이 사용하던 디스크 블록을 사용 가능한 디스크 블록 풀(free disk block pool)로 반환
1단계와 2단계 사이에서 시스템 오류가 발생하면 디렉토리 엔트리가 없는 아이노드(orphaned inode)가 생성되어 저장 공간 누수가 발생한다. 2단계와 3단계 사이에 크래시가 발생하면 디스크 블록을 재사용할 수 없어 저장 용량이 줄어든다. 이러한 문제는 단계 순서를 변경해도 해결되지 않는다.
이러한 오류를 검출하고 수정하려면 fsck와 같은 도구를 사용하여 데이터 구조를 검사해야 한다.[2] 이 작업은 파일 시스템이 마운트되기 전에 수행되어야 하며, 파일 시스템이 크고 I/O 대역폭이 적으면 시간이 오래 걸려 시스템 가동 중지 시간이 길어질 수 있다.
저널링 파일 시스템은 이러한 문제를 해결하기 위해 변경 사항을 '저널'이라는 특수 영역에 기록한다. 충돌 이후에는 저널을 읽고 변경 사항을 리플레이(replay)하여 복구한다. 이 변경 사항은 원자적으로 처리된다.
저널링은 UNIX의 아이노드나 윈도우의 슈퍼블록, FNODE와 같은 파일 시스템 메타데이터를 트랜잭션 단위로 관리·보존하는 기능을 제공한다.
2. 1. 기존 파일 시스템의 문제점
기존 파일 시스템에서는 파일 내용(실 데이터)과 파일 위치, 이름, 갱신 시간, 접근 권한 등(메타데이터)을 갱신할 때 여러 번 쓰기 작업이 필요하다. 이 과정에서 전원 공급 중단이나 시스템 크래시 등으로 쓰기 작업이 중단되면 데이터 구조가 불안정해져 데이터가 손실되거나 접근 불가능해질 수 있다.[1]예를 들어, 유닉스 파일 시스템에서 파일 삭제는 다음 세 단계를 거친다:[7]
# 파일의 디렉토리 엔트리 삭제.
# 파일이 사용하던 아이노드를 사용 가능한 아이노드 풀(free inode pool)로 반환.
# 파일이 사용하던 디스크 블록을 사용 가능한 디스크 블록 풀(free disk block pool)로 반환.
1단계와 2단계 사이에서 시스템 오류 발생 시, 디렉토리 엔트리는 없지만 아이노드는 사용 중인 상태가 되어 저장 공간 누수가 발생한다. 2단계와 3단계 사이 오류 발생 시, 파일이 사용하던 디스크 블록을 재사용할 수 없어 저장 용량이 줄어든다. 이러한 문제는 단계 순서를 변경해도 해결되지 않는다.[12]
이러한 오류를 복구하려면 fsck (파일 시스템 검사기) 같은 도구로 전체 데이터 구조를 검사해야 한다.[2] 이 작업은 파일 시스템이 크고 I/O 대역폭이 상대적으로 적을 경우 많은 시간이 걸려 시스템 복구를 지연시킬 수 있다.
2. 2. 저널링을 통한 해결
저널링 파일 시스템은 파일 시스템의 메타데이터 변경 사항을 "저널"이라는 특수한 영역에 먼저 기록하는 방식으로 작동한다. 이러한 변경 사항 기록은 원자적으로 처리되는데, 이는 변경 사항이 완전히 성공하거나(원래 성공했거나 복구를 통해 완전히 재현됨) 아예 반영되지 않음을 의미한다.[1]예를 들어, 유닉스 파일 시스템에서 파일을 삭제하는 과정은 다음과 같다.[7]
# 파일의 디렉토리 엔트리 제거
# 파일이 사용하던 아이노드를 사용 가능한 아이노드 풀에 반환
# 파일이 사용하던 디스크 블록을 사용 가능한 디스크 블록 풀에 반환
만약 1단계와 2단계 사이에서 시스템 크래시가 발생하면, 해당 파일의 아이노드는 디렉토리 엔트리가 없는 고아 아이노드가 되어 저장 공간 누수가 발생한다. 2단계와 3단계 사이에 크래시가 발생하면, 파일이 사용하던 디스크 블록을 재사용할 수 없어 저장 용량이 줄어든다. 이러한 문제는 단계의 순서를 바꾸어도 해결되지 않는다.[1]
이러한 불일치를 검출하고 수정하려면 fsck와 같은 도구를 사용하여 데이터 구조 전체를 검사해야 한다.[2] 이 작업은 파일 시스템이 다시 마운트되기 전에 수행되어야 하며, 파일 시스템이 크고 I/O 대역폭이 낮으면 시간이 오래 걸려 시스템 가동 중지 시간이 길어질 수 있다.
저널링 파일 시스템에서는 충돌 발생 시, 저널을 읽고 기록된 변경 사항을 재현(replay)하여 파일 시스템을 일관된 상태로 복구한다. 이 방식은 전체 파일 시스템을 검사하는 것보다 훨씬 빠르다. 저널링은 메타데이터의 갱신을 "저널"에 순차적으로 기록하고, 쓰기 요구에 따라 해당 메타데이터를 반영하는 방식으로 파일 갱신 중 쓰기 중단에 대처한다.[1]
메타데이터와 실제 데이터 간의 불일치가 발생하더라도, 불일치 발생 전의 메타데이터로 강제로 되돌려 실제 데이터를 포함한 파일 자체의 손실을 방지할 수 있다. 이 방법은 하드 디스크 전체를 스캔하는 것보다 처리 시간을 단축시킨다.
일반적으로 저널은 메타데이터까지만 보호하며, 파일 내용은 보호하지 않는다. 즉, 시스템 충돌로 인한 파일 시스템 손상은 막을 수 있지만, 저장하려던 내용이 저장되지 않는 상황은 발생할 수 있다. 그러나 리눅스의 ext3나 넷앱의 WAFL과 같은 일부 저널링 파일 시스템은 실제 데이터도 보호한다.
2. 3. 기술 방식
'''물리 저널'''은 메인 파일 시스템에 나중에 기록될 모든 블록의 사전 복사본을 기록한다. 메인 파일 시스템에 기록하는 중에 충돌이 발생하면, 다음에 파일 시스템을 마운트할 때 쓰기를 간단히 다시 재생하여 완료할 수 있다. 저널에 쓰기를 기록하는 중에 충돌이 발생하면, 부분 쓰기에 누락되거나 일치하지 않는 체크섬이 있게 되며, 다음에 마운트할 때 무시할 수 있다.[8]물리 저널은 변경된 모든 블록을 저장소에 ''두 번'' 커밋해야 하므로 상당한 성능 저하를 초래하지만, 절대적인 오류 방지가 필요할 때는 허용될 수 있다.[8]
'''논리 저널'''은 저널에 파일 메타데이터에 대한 변경 사항만 저장하며, 내결함성을 포기하고 대신 쓰기 성능을 대폭 향상시킨다.[9] 논리 저널이 있는 파일 시스템은 충돌 후에도 빠르게 복구되지만, 저널링되지 않은 파일 데이터와 저널링된 메타데이터가 서로 동기화되지 않아 데이터 손상이 발생할 수 있다.
예를 들어, 파일에 추가하는 작업은 다음 세 가지 별도의 쓰기를 포함할 수 있다.
# 파일의 크기가 증가했음을 파일 메타데이터에 기록하기 위해 파일의 inode.
# 추가될 데이터에 대한 공간 할당을 표시하기 위해 빈 공간 맵.
# 실제로 추가된 데이터를 쓰기 위해 새로 할당된 공간.
메타데이터 전용 저널에서는 3단계가 기록되지 않는다. 3단계가 수행되지 않았지만 복구 중에 1단계와 2단계가 재생되면 파일에 쓰레기 데이터가 추가된다.
일반적으로 저널에 의해 보호되는 것은 메타데이터까지이며, 파일의 내용까지는 보호되지 않는다. 즉, 저널링 파일 시스템을 도입함으로써, 시스템 충돌에 따른 파일 시스템의 파괴라는 사태는 피할 수 있지만, 저장했을 내용이 저장되어 있지 않았다는 사태가 일어날 가능성은 충분히 생각할 수 있다. 다만, 리눅스의 ext3나 넷앱(NetApp)의 WAFL 등, 몇몇 저널링 파일 시스템에서는 실 데이터의 보호도 수행하고 있다.
다른 해결 방법으로, 어떤 타이밍에 연속적인 쓰기가 중단되어도 모순이 일어나지 않도록, 디스크에의 쓰기 순서를 제어하는 해결 방법이 있다. FreeBSD에서는 그쪽이 채용되었다(soft updates).
3. 역사
1990년 IBM은 AIX 3.1에 JFS를 도입하면서 저널링을 구현한 최초의 유닉스 상용 파일 시스템 중 하나가 되었다.[4] 1993년 마이크로소프트는 윈도우 NT에 NTFS 파일 시스템을, 1998년 애플은 HFS Plus 파일 시스템을, 2001년 리눅스는 ext3 파일 시스템에 구현하였다.[6]
오픈 시스템에서 최초의 저널링 파일 시스템은 범용 기기 및 고가용 결함 허용 컴퓨터용 OS를 만들던 IBM의 JFS(AIX V3.1용 1990년) 및 Tolerant Software(VERITAS)의 VxFS(UNIX System V용 1989년)이다. 이는 범용 기기에서 중요한 업무 데이터를 처리할 때 파일의 메타데이터 보존 방법에서 고안된 것으로, 범용 기기의 파일 관리 도구의 설계 사상을 PC에 도입하기 위해 고려되었다.
;JFS
: 당초 OS/2에서 개발이 진행되었으며, 1990년에 IBM의 상용 UNIX인 AIX V3.1에서 실제 출시되었다.
;VxFS
: 거의 동시기에 UNIX의 범용 기기 대체 수요에 맞춰 1987년에 Tolerant Software(VERITAS사의 전신)가 AT&T UNIX System Laboratories의 협력을 얻어, 자사의 고가용성 운영 체제에서 UNIX System V용으로 가치 있는 코드를 추출하여, 트랜잭션 기반의 볼륨 매니저와 함께 UNIX용 저널링 파일 시스템을 업계 최초로 개발했다. 이후 1989년에 상용 패키지 VxFS로 제공되었다.
이후 UNIX와 유사한 OS의 발전에 따라, 많은 저널링 파일 시스템이 고안되어 구현되었다.
4. 대한민국의 저널링 파일 시스템 현황
대한민국에서는 리눅스, 윈도우 등 다양한 운영체제 환경에서 저널링 파일 시스템을 사용하고 있다.
4. 1. 리눅스 환경
대한민국에서 가장 널리 사용되는 서버 운영체제인 리눅스에서는 ext3, ext4, XFS, JFS, ReiserFS 등 다양한 저널링 파일 시스템을 지원한다.4. 2. 윈도우 환경
NTFS는 마이크로소프트 윈도우 운영체제에서 사용하는 파일 시스템으로 저널링을 지원한다.4. 3. 기타 운영체제
5. 대안
저널링 파일 시스템은 데이터 무결성을 보장하는 방법 중 하나이지만, 다른 대안들도 존재한다.
- 소프트 업데이트: 일부 UFS 구현에서 사용되는 방식으로, 쓰기 작업을 정렬하여 파일 시스템의 일관성을 유지한다. 충돌 발생 시에는 저장 공간 누수만 발생하며, 이는 다음 마운트 시 백그라운드에서 가비지 컬렉션을 통해 복구된다.[11]
- 로그 구조 파일 시스템: 저널 자체가 파일 시스템이므로 두 번 쓰기 페널티가 발생하지 않는다. 전체 저장 장치를 파일 시스템으로 사용하며, 일반 파일 시스템처럼 탐색 가능하다.
- 카피 온 라이트 (Copy-on-write): ZFS, Btrfs와 같은 파일 시스템에서 사용되는 방식으로, 데이터를 새 블록에 기록하고 메타데이터를 업데이트하는 방식으로 작동한다. 이를 통해 저널링과 동일한 수준의 데이터 무결성을 보장하면서도 두 번 쓰기 오버헤드를 피할 수 있다.[1]
5. 1. 소프트 업데이트 (Soft updates)
일부 UFS 구현은 저널링 대신 소프트 업데이트를 구현한다. 이는 디스크 상의 파일 시스템이 절대 일관성이 없도록 쓰기 작업을 정렬하거나, 충돌 발생 시 생성될 수 있는 유일한 불일치가 저장 공간 누수가 되도록 쓰기 작업을 정렬하는 방식이다. 이러한 누수로부터 복구하기 위해, 다음 마운트 시 파일 시스템을 전체적으로 순회하며 사용 가능 공간 맵을 조정한다. 이 가비지 컬렉션은 일반적으로 백그라운드에서 수행된다.[11]5. 2. 로그 구조 파일 시스템 (Log-structured file systems)
로그 구조 파일 시스템에서는 두 번 쓰기 페널티가 적용되지 않는데, 이는 저널 자체가 파일 시스템이기 때문이다. 즉, 전체 저장 장치를 차지하며 일반적인 파일 시스템처럼 탐색할 수 있도록 구조화되어 있다.5. 3. 카피 온 라이트 (Copy-on-write) 파일 시스템
카피 온 라이트 파일 시스템(예: ZFS, Btrfs)은 파일 데이터를 제자리에서 변경하지 않고, 새롭게 할당된 블록에 데이터를 기록한다. 그리고 새 데이터를 가리키는 업데이트된 메타데이터를 기록한 다음, 이를 가리키는 메타데이터를 다시 기록한다. 이 과정은 슈퍼블록 또는 파일 시스템 계층 구조의 루트까지 이어진다. 결과적으로 두 번 쓰기 오버헤드 없이 저널과 동일한 정확성 보존 속성을 갖는다.[1]6. 저널링 파일 시스템 제품
| 운영체제 | 파일 시스템 |
|---|---|
| AIX | JFS, VxFS |
| HP-UX | VxFS |
| 솔라리스 | UFS 로깅, ZFS(ZFS, Zettabyte File System, 제타바이트 파일 시스템) (솔라리스 10부터 사용 가능), VxFS |
| IRIX | XFS |
| 리눅스 | ext3, ext4, JFS, ReiserFS, XFS, VxFS, ZFS, NTFS |
| FreeBSD | GEOM gjournal, ZFS, 저널링 소프트 업데이트(FreeBSD 9) |
| NetBSD | WAPBL |
| 윈도우 | NTFS |
| macOS | HFS+ - 저널링은 Mac OS X 10.2.2부터 추가되었다. |
다음은 VxFS만 유료이며, 그 외에는 무료 또는 표준 탑재이다.
참조
[1]
간행물
Anatomy of Linux journaling file systems
http://www.ibm.com/d[...]
IBM DeveloperWorks
2008-06-04
[2]
간행물
Crash Consistency: FSCK and Journaling
http://pages.cs.wisc[...]
Arpaci-Dusseau Books
2014-01-21
[3]
웹사이트
tune2fs(8) – Linux man page
http://linux.die.net[...]
2015-02-20
[4]
간행물
Evolution of storage facilities in AIX Version 3 for RISC System/6000 processors
https://pdf.zlibcdn.[...]
1990-01
[5]
컨퍼런스
The Design and Implementation of a Log-Structure File System
https://people.eecs.[...]
ACM 13th Annual Symposium on Operating Systems Principles.
1991-02
[6]
웹사이트
"'2.4.15-final' - MARC"
http://marc.info/?l=[...]
2018-03-24
[7]
서적
File Systems
Prentice Hall
2008
[8]
간행물
Ext3, journaling filesystem
[9]
간행물
Analysis and Evolution of Journaling File Systems
https://www.usenix.o[...]
USENIX Association
2007-07-27
[10]
간행물
Barriers and journaling filesystems
https://lwn.net/Arti[...]
2008-05-21
[11]
간행물
Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems
http://www.usenix.or[...]
USENIX Association
2007-07-27
[12]
웹인용
Anatomy of Linux journaling file systems
http://www.ibm.com/d[...]
IBM DeveloperWorks
2008-06-04
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com