저널링(Journalling)과 ReiserFS

역시나 이전에 xfs에 관한글을 올렸었는데 작성된지는 좀 됐지만
저널링파일시스템에 대한 이해를 돕는 문서를 올립니다.

출처 : http://www-903.ibm.com/developerworks/kr/linux/library/l-fs.html

와우리눅스에 올라온 xfs관련글
작성자 : 정진호
http://www.wowlinux.com/information/techupview.html?id=70&view=1

ps.구글에서 저널링으로 검색하니 ibm의 링크가 나오더군요 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

저널링(Journalling)과 ReiserFS
Daniel Robbins (drobbins at gentoo.org)
President/CEO, Gentoo Technologies, Inc.
2001년 6월

Linux2.4에 ReiserFS, XFS, GFS와 같은 새로운 파일시스템 기능이 추가되면서
기대를 모으고 있다. 이러한 파일시스템들은 분명 훌륭한 것들이다. 하지만 실
제로 그것의 기능과, 어떤 부분에서 효율적으로 사용되는지, 또한 Linux 제품
환경에서 안전하게 사용할 수 있는 방법에 대해서는 정확히 모른다. Daniel
Robbins는 Linux 2.4에 새롭게 향상된 파일시스템을 설치하는 방법을 설명한
다. 또한 유용한 구현 방법, 성능 관련 정보 및 중요한 기술적인 사항들을 설
명하여, 새로운 파일 시스템의 경험이 가능한 즐거운 일이 될 수 있도록 할 것
이다. 특히 저널링(Journalling)과 ReiserFS의 장점을 설명한다.
개요
이 글에서는 ReiserFS, XFS, JFS, GFS, ext3와 같은 Linux의 다양하고 새로운
파일시스템을 소개할 것이다. 파일시스템을 사용하는 데에 실질적으로 필요한
지식을 전달하고 싶다. 가능한 한 중요한 실수를 피하는 방법에 대해서도 설명
하겠다. 이를 위해 파일시스템의 안정성, 퍼포먼스 문제, 부정적인(negative)
애플리케이션 상호작용, 최상의 커널/패치 조합 (combination) 등을 주의 깊
게 살펴볼 것이다. 이 글이 차세대 파일시스템에 대한 지침서의 역할을 해 줄
것이라고 기대한다.

우선 이 글을 어떻게 구성할 지에 대해 설명하겠다. 나는 Linux 개발 커뮤니티
에 있어서 매우 중요한 두 가지 주제인 저널링과 ReiserFS을 설명하려 한다.
저널링이 중요한 이유는 꽤 오랫동안 예견해오던 기술이고 결국 지금 우리 눈
앞에 펼쳐져 있기 때문이다. 저널링 기술은 ReiserFS, XFS, JFS, ext3, GFS에
서 사용된다. 저널링의 정확한 기능과 Linux에 저널링이 필요한 이유를 아는
것은 중요하다. 이 글을 통해 내가 기대하는 것은 저널링을 완벽히 이해하는
차원을 넘어 다른 사람들에게도 이러한 기술을 설명할 때 훌륭한 지침서의 역
할을 하는 것이다. 더 나아가서 전 세계의 부서와 조직에서 새로운 저널링 파
일시스템으로 변경할 때 실제 적용 사례로 작용할 수 있기를 기대한다.

이 글의 후반부에는 ReiserFS에 대해 살펴볼 것이다. 이쯤 되면 여러분은 새로
운 파일시스템 기술로 인해 기존의 것이 좀 더 빠르게 향상되었음을 의미하는
것이 아니라는 것을 알게 될 것이다. 다시 말해서 이전에는 가능하지 않았던
방식으로 어떤 일을 할 수 있게 되었다는 것을 의미한다. 새로운 파일시스템
의 기능은 코드 작성 방법이나 향후의 Linux 소프트웨어 개발 프로젝트의 방식
에도 영향을 미칠 것이다.

저널링 이해하기:meta-data
여러분도 잘 알다시피 파일시스템은 데이터를 저장하고 검색하고 처리하기 위
해서 존재한다. 이를 위해서 파일시스템은 모든 데이터가 조직화 되고 액세스
가 가능한 상태로 되어있는 내부 데이터 구조를 가지고 있어야 한다. 그 내부
데이터 구조 (문자 그대로 "데이터에 대한 데이터") 를 meta-data라고 한다.
meta-data 의 구조는 파일시스템에 특정한 구분과 퍼포먼스 특징을 부여한
다. .

일반적으로 우리는 파일시스템의 meta-data에 직접적으로 관여하지 않는다. 대
신 특정 Linux 파일시스템 드라이버가 그러한 일을 대신한다. Linux 파일시스
템 드라이버는 meta-data의 미로를 처리하기 위해 특별히 만들어졌다. 하지만
파일시스템 드라이버가 적절하게 작업을 수행하기위해서는 한가지 중요한 조건
이 있다. 파일시스템 드라이버는 합리적이고 일관성이 있으며 손상되지 않은
상태의 meta-data를 찾을 수 있어야 한다. 그렇지 않으면 파일시스템 드라이버
는 meta-data를 인식하거나 처리 할 수 없고 따라서 우리들도 파일에 액세스
할 수 없다.

저널링 이해하기:fsck
이제 fsck에 대해 알아보자. Linux가 부팅 될 때, fsck도 시작하게 되며 시스
템의 /etc/fstab 파일에 있는 모든 로컬 파일시스템을 검사한다. fsck는 마운
트 될 파일시스템의 meta-data가 사용할 수 있는 상태인지를 확인하는 역할을
한다. 대부분의 경우 사용할 수 있는 상태일 것이다. Linux가 종료되면 이것
은 조심스럽게 모든 캐시 데이터를 디스크에 저장하고 파일시스템이 정확하게
언마운트(unmount) 되었음을 확인한다. 그래서 시스템이 다시 시작될 때 사용
할 준비가 되는 것이다. 일반적으로 fsck는 마운트 될 파일시스템을 검사하고
그것이 정확히 언마운트 되었다는 것을 확인하고 모든 meta-data가 정상이라
는 판단을 내린다.

하지만, 갑작스러운 정전 또는 시스템 다운과 같은 변수가 생기기 마련이다.
이런 "불행한" 상황이 발생하면 Linux는 파일시스템을 완벽하게 언마운트 할
수 없다. 시스템이 재 부팅되고 fsck가 검사를 시작하면 파일시스템이 완전히
언마운트 되지 않았음이 밝혀지고 아마도 Linux 파일시스템 드라이버는 파일시
스템을 볼 수 없다는 결론이 나온다. 아마도 meta-data가 어떠한 경로에서 뒤
죽박죽 되었을 가능성이 크다.

이러한 문제를 풀기위해 fsck는 meta-data를 세밀하게 검사하고 정상성 점검
(sanity check)을 수행한다. 그래서 그 경로에서 발견된 에러를 수정한다. 일
단 fsck가 완료되면 파일시스템은 사용할 준비를 갖추게 된다. 비록 최근에 변
경된 데이터 일부를 잃었을지라도 meta-data는 다시 정상적인 상태가 되었기
때문에 파일시스템은 마운트되어 사용할 수 있게 된다.

fsck의 문제점
이러한 fsck의 방식은 파일시스템의 일관성(consistency)을 확인하는데 있어
서 괜찮은 방법인 것 같다. 하지만 최적의 솔루션은 아니다. 문제는, 파일시스
템의 일관성을 확인하기 위해서 fsck가 파일시스템의 전체 meta-data를 검사해
야 한다는 데에 있다. 모든 meta-data에 대해 완벽한 일관성 체크를 한다는 것
은 그 자체로 시간 낭비이며 완료하는데 최소한 수분이 걸린다. 게다가 좀 더
큰 파일시스템일 경우 소요 시간은 더욱 길어진다. 이것은 매우 큰 문제이다.
왜냐하면 fsck가 작동하는 동안 Linux 시스템이 사실상 오프라인 상태이고 방
대한 분량의 파일시스템 이라면 fsck 작동은 30분 이상 걸리기 때문이다. 따라
서 표준 fsck 작동은 시스템 가동시간(uptime)이 매우 중시되는 미션 크리티컬
한 데이터 센터 환경에 엄청난 결과를 초래할 수 있다. 좀 더 나은 솔루션이
있다.

저널(journal)
저널링 파일 시스템은 저널이라고 하는 새로운 데이터 구조를 추가함으로써 이
러한 fsck 문제를 해결한다. 이 저널은 on-disk 구조이다. 파일시스템 드라이
버가 meta-data에 어떠한 변경을 가하기 이전에 어떤 일을 할 것인지에 대한
내용을 저널에 기록한다. 그 다음 meta-data를 수정하게 된다. 그렇게 함으로
써 저널링 파일시스템은 최근의 meta-data 수정사항의 로그를 유지하며, 이는
특히 올바르게 언마운트 되지 않은 파일시스템의 일관성을 검사해야 할 경우
에 유용하다.

저널링 파일시스템은 데이터(stuff)와 meta-data(stuff에 대한 데이터)를 저장
하는 것은 물론 meta-meta-data(stuff에 대한 데이터에 대한 데이터)를 호출
할 수 있는 저널도 갖추었다고 생각하면 된다.

저널링의 기능
그렇다면 fsck는 저널링 파일시스템을 어떻게 처리할까? 실제로, 아무것도 하
지 않는다. fsck는 간단히 파일시스템을 무시하고 이것이 마운트 되도록 한
다. 파일시스템을 일관성 있는 상태로 빠르게 복원할 수 있었던 마법은 Linux
파일시스템 드라이버에서 찾을 수 있다. 파일시스템이 마운트되면 Linux 파일
시스템 드라이버는 파일시스템이 정상인지의 여부를 점검한다. 그렇지 않을 경
우 meta-data는 고정되어야 하며 meta-data를 검사하는 대신 저널을 살핀다.
저널은 최근의 모든 meta-data 변경 로그를 순차적으로 포함하고 있기 때문에
최근에 변경된 meta-data 부분만 검사하면 된다. 그래서 몇 초안에 파일시스템
을 일관성 있는 상태로 되돌릴 수 있다. fsck와 같은 기존의 접근방식과는 다
르게 저널 리플레잉 프로세스(journal replaying process)는 대용량의 파일시
스템인 경우에도 시간이 많이 걸리지 않는다. 이 저널 덕분에 수백 기가의 파
일시스템 meta-data는 거의 동시에 일관성 있는 상태로 돌아올 수 있다.

ReiserFS
이제 ReiserFS에 대해 알아보도록 하자. 우리가 앞으로 연구해야 할 저널링 파
일시스템 중에서 가장 먼저 연구해야 할 대상이다. ReiserFS 3.6.x (Linux 2.4
에 포함되어 있음)는 Namesys의 Hans Reiser와 그가 이끄는 팀이 개발하였다.
그들은, 최상의 파일시스템이란 애플리케이션이 좀 더 직접적이고, 효율적이
며 강력하게 상호 작용할 수 있는 단일 공유 환경(single shared
environment) 또는 namespace의 구현을 도와주는 것이라는 철학으로 뭉쳤다.
이를 위해서 파일시스템은 퍼포먼스와 기능에 대한 사용자의 요구를 충족시켜
야 한다. 그러한 방식으로 사용자들은 파일시스템 상에서 실행하는 특별한 목
적의 레이어를 구현하는 대신 지속적으로 직접 파일시스템을 사용할 수 있다.

작은 파일(small file) 퍼포먼스
파일시스템을 좀 더 효율적으로 만들려면 어떻게 해야 할까? Namesys는 파일시
스템의 한 부분에 초점을 맞추기로 했다. 즉 작은 파일(small file) 퍼포먼스
이다. 일반적으로 ext2와 ufs와 같은 파일시스템은 이 분야에 있어서는 장점
이 없다. 따라서 개발자들이 필요로 하는 퍼포먼스를 얻기 위해 데이터베이스
를 사용하거나 또는 특정한 방식의 해킹을 통해 해결할 수 밖에 없었다. 오랜
세월동안 이와 같이 "문제에 대한 코드를 작성한다 (I'll code around the
problem)" 식의 접근방식은 코드만 많아지게 하고 호환되지 않는 특별한 목적
의 API만을 만들 뿐이다.

ext2가 그러한 종류의 프로그래밍을 어떻게 유발하는지에 대한 예제도 있다.
ext2는 많은 20k 바이트대의 파일을 저장하는데 유용하다. 하지만 2,000개의
50-byte 파일을 저장하는 데에는 이상적인 기술이 아니다. ext2가 아주 작은
파일을 다루어야 할 때 퍼포먼스는 급격히 떨어지게 되고 ext2가 하나 또는 4
개의 k chunk (파일시스템이 만들어질 때 설정할 수 있음)에 공간을 할당하기
때문에 저장 효율성 또한 떨어진다.

파일시스템에 작은 파일을 많이 저장해서는 안된다는 것이 일반 상식이다. 대
신 파일시스템 위에서 실행되는 일종의 데이터 베이스에 저장해야 한다고 알고
있다. 하지만 Hans Reiser는 파일시스템의 상단에 레이어를 빌드해야 할 때마
다 파일시스템은 여러분의 필요를 충족시키는 것은 아니라고 말한다. 파일시스
템이 여러분의 필요를 충족시켰다면 그때는 첫 단계에서 특별한 목적의 솔루션
을 사용하지 않아도 된다. 따라서 여러분은 개발시간을 줄이고 코드가 늘어나
는 것을 방지할 수 있게 된다.

이론은 이렇다. 하지만 실제로 ReiserFS의 작은 파일 퍼포먼스는 어떠한가? 놀
랍도록 좋다. 사실 ReiserFS는 1 k 사이즈보다 작은 파일을 핸들링 할 때
est2 보다 8배에서 15배 정도 더 빠르다. 더욱이 이러한 퍼포먼스 향상은 다
른 파일 유형때문에 퍼포먼스를 희생하지 않아도 된다. 일반적으로 ReiserFS
는 여러모로 ext2보다 훨씬 뛰어나지만 그 중에서도 특히 작은 파일을 핸들링
할 때 빛을 발한다.

ReiserFS 기술
그렇다면 ReiserFS의 작은 파일 퍼포먼스가 어떠한지 살펴보자. ReiserFS는 모
든 파일시스템 데이터를 조직화하기 위해서 특별히 최적화된 b* balanced
tree (파일시스템 당 한개) 를 사용한다. 이것은 그 자체로 훌륭한 퍼포먼스
를 제공하고 파일시스템 레이아웃에 대한 제한을 없앤다. 이제 100,000 개의
다른 디렉토리를 한 디렉토리 안에 포함 할 수 있다. b* tree 를 사용할 때의
또 다른 장점은 ReiserFS는 파일시스템을 구현할 때 고정된 inode 세트를 만드
는 대신에 필요할 때마다 inode를 할당할 수 있다는 것이다. 이는 다양한 저장
에 대한 요구에 파일시스템이 유연하게 반응할 수 있고 동시에 몇 가지 추가적
인 공간 효율성도 가능해진다.

ReiserFS는 작은 파일 퍼포먼스를 향상시킬 수 있는 주요 기능도 가지고 있
다. ext2와는 다르게 ReiserFS는 고정된 1k 또는 4k 블럭으로 저장 공간을 할
당하지 않는다. 대신 필요할 때마다 정확한 사이즈를 할당할 수 있다. 그리고
ReiserFS는 파일시스템 블록 보다 작은 파일과 파일의 끝 부분을 위한 이름인
tail 주변에 집중된 특별한 몇몇 최적화를 포함한다. 퍼포먼스를 늘리기 위해
서 ReiserFS 파일시스템은 디스크 어딘가에 있는 데이터를 저장하고 그것을 지
목하기 보다 없는 b*tree leaf node 내부에 파일을 저장할 수 있다.

이것은 두 가지 일을 한다. 첫째, 이것은 작은 파일 퍼포먼스를 획기적으로 향
상시킨다. 파일 데이터와 stat_data(inode) 정보가 각자의 오른쪽 옆에 저장되
기 때문에 그들은 일반적으로 한 번의 디스크 입출력 작업으로 판독될 수 있
다. 둘째, ReiserFS는 tail들을 함께 패킹 할 수 있다. 게다가 많은 공간도 절
약된다. 사실 tail 패킹이 가능한(디폴트) ReiserFS 파일시스템은 같은 ext2
파일시스템보다 6%정도 더 데이터를 저장 할 수 있다. 얼마나 놀라운 일인가?

하지만 tail 패킹은 미미한 퍼포먼스 히트를 유발한다. 왜냐하면 파일이 변경
될 때 ReiserFS로 하여금 데이터를 다시 패킹 하도록 하기 때문이다. 이러한
이유로 인해서 ReiserFS tail 패킹은 꺼지고 관리자가 속도와 공간 효율을 택
할지 저장 용량을 희생하고 속도를 선택할 지 결정할 수 있도록 한다.

ReiserFS는 훌륭한 파일시스템이다. 다음에는 Linux 2.4에 ReiserFS의 세팅 과
정을 설명하겠다. 또한 퍼포먼스 튜닝, 애플리케이션 상호작용, 최고의 커널등
에 대해 자세히 살펴보도록 하겠다.

참고자료

Namesys Web page : ReiserFS에 대한 자세한 정보

ReiserFS mailing list : ReiserFS 정보 제공. ReiserFS mailing list
archive 참조

Linux Gazette Journalling Filesystems : UFS, ext2, ReiserFS의 meta-data
차이점 심층 연구

Jedi's ReiserFS/Qmail tuning page : qmail 사용자를 위한 정보제공.
ReiserSMTP(qmail 컴포넌트 컬렉션)

Linux Weekly News: 최신 커널 개발 소식

JFS Overview : developerWorks, Steve Best

JFS fundamentals tutorial : developerWorks.

Linux 참고자료 : developerWorks.

Open source 참고자료 : developerWorks.

필자소개
Daniel Robbins(drobbins at gentoo.org)는 Gentoo
Technologies, Inc.의 회장/CEO이고,
Gentoo Project의 핵심 설계자이며, Caldera OpenLinux Unleashed,
SuSE Linux Unleashed, Samba Unleashed의 저자이다.

관련 링크: http://www-903.ibm.com/developerworks/kr/linux/library/l-fs.html