Over time, this kind of "I'll code around the problem" approach
encourages code bloat and lots of incompatible special-purpose APIs,
which isn't a good thing.
아직도 이런 부분이 많지? ;)
"I'll code around the problem" 정신상태로 작업하는 이들이여...
모두 정신 차리시라... lol
Common threads: 고급 파일시스템 개발자 가이드
저널링(Journalling)과 ReiserFS
[한글] http://www-128.ibm.com/developerworks/kr/linux/library/l-fs.html
[영어원문] http://www.ibm.com/developerworks/library/l-fs.html
저널링(Journalling)과 ReiserFS
Daniel Robbins
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의 세팅 과정을 설명하겠다. 또한 퍼포먼스 튜닝, 애플리케이션 상호작용, 최고의 커널등에 대해 자세히 살펴보도록 하겠다.
참고자료
* discussion forum on this article by clicking Discuss at the top or bottom of the article. --> 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는 Gentoo Technologies, Inc.의 회장/CEO이고, Gentoo Project의 핵심 설계자이며, Caldera OpenLinux Unleashed, SuSE Linux Unleashed, Samba Unleashed의 저자이다.
