라이저 파일 시스템(Reiser File System)의
소개와 준비하기

필자 : 양유성 (yooseong@kldp.org)

 

     

    요즘 리눅스 커널이 2.4로 들어오면서 저널링 파일 시스템(Journalingfile)에 대한, 특히 라이저 파일 시스템에 관한 관심이 많아지고 실제로 여러 배포본들이 이러한 저널링 파일 시스템을 채택하고 있다.

    여기에서는 간단하게 저널링 파일 시스템에 대한 개요와 간단한 이론적 지식 및 지금 주로 사용되는 저널링 파일 시스템에 대한 비교와 지금 리눅스에서 가장 많이 채택하고 있는 라이저 파일 시스템을 쓰기 위한 기초작업을 알아보도록 하겠다. 그리고 다음 달에는 직접 기존에 사용하고 있는 ext2 파일시스템을 라이저 파일시스템으로 바꾸는 것을 다루어보겠다.

    기본적으로 여기서는 파일시스템이 무엇인가를 대략적으로 안다고 가정한다.

    리눅스가 계속 진화(?)함에 따라서 수많은 사용자와 여러가지 상황을 다 만족시켜야 했는데 최근에는 상업적인 유닉스와 커다란 서버의 특징을 갖는 기능들을 포함하게 되었다. 그 수많은 특징들 중의 하나가 아주 커다란 하드디스크 파티션을 지원하고 수많은 파일들을 가지고 쉽게 확장할 수 있으며 정전등의 불의의 사태에도 빨리 복구되며 입출력에도 좋고 작고 큰 파일들에 모두 적용 가능한 파일시스템을 지원하는 것이다.
    우선은 저널링 파일시스템을 몇 가지 소개하고 간략하게 비교를 해보자.

    그럼 간단하게 파일시스템을 알아보고 넘어가자.

    리눅스 시스템 관리자 문서에 보면 파일시스템이란 운영체제가 파티션이나 디스크에 파일들이 연속되게 하기 위해 사용하는 자료구조다. 즉, 파일들이 디스크 상에서 구성되는 방식이다.

    파일시스템이라는 말은 파일을 저장하는데 사용되는 파티션이나 디스크를 가리킬 때나, 파일 시스템의형식을 지칭할 때 사용되기도 한다. 그래서 파일을 저장하는 2개의파티션을 가지고 있다는 의미에서 어떤 사람이 “난 2개의 파일 시스템을 가지고 있다.”고 말할지도 모르고, 파일 시스템의 형식을 의미해서 “확장파일 시스템”을 그 사람이 사용하고 있을 것이다. 디스크와 파티션이 포함하고 있는 파일 시스템의 차이는 중요하다. 약간의 프로그램들(파일 시스템을 만드는 프로그램을 포함해서)은 디스크나 파티션의 원시 섹터를 직접 조정한다.

    만약 디스크나 파티션에 파일시스템이 존재한다면 그 파일시스템은 파괴되거나 심하게 망가질 것이다. 대부분의 프로그램들은 파일시스템 위에서 작동하며 파일시스템이 없는, 혹은 다른 형식의 파일시스템이 있는 파티션에서는 작동하지 않을 것이다.

    이러한 파일시스템에 대한 내용을 바탕으로 저널링 파일시스템에 대해 알아보도록 하자.

 

1. 저널링 파일시스템이란?

    파일의 입출력 속도를 높이기 위해 미리 정해진 주 메모리에 있는 버퍼를 익히 들어 알고 있을 것이다.

    이러한 종류의 버퍼는 대개 파일시스템에서 디스크 캐쉬로 사용되고 전체적인 성능 향상을 위한 데이타베이스로 이용되고 있다. 하지만 이러한 버퍼가 있는 경우에도 이러한 버퍼가 디스크에 내용을 쓰기 전에 갑작스런 정전등으로 인하여 시스템에 손상이 오는 경우에 문제가 심각해질 수 있다. 결국 이는 재 부팅 후에 시스템이 비정상적으로 작동하게 되는 경우가 생기게 되는 것이다.

    그러면 이러한 경우를 생각해보자. 캐시에는 지워진 파일이 하드디스크에 남이 있는 경우 데이타 베이스와 파일시스템은 정상적인 방식으로 시스템을 복구하게 될 것이다.

    데이타 베이스가 수년간 빠르게 복구되어 오고 있지만 UFS(Unix File System; SCO, System V등의 유닉스의 파일 시스템)와 같은 부류의 경우 파일 시스템의 크기가 커짐에 따라 불의의 사고를 당한 경우에 파일 시스템의 복구 시간이 증가하게 된다.

    이러한 시간이 오래 걸리는 작업은 엄청난 크기의 용량을 가진 서버에 있어서는 성능의 저하를 가져오게 된다. 이러한 이유로 데이타 베이스 복구 기술을 빠르게 할 필요성이 느껴졌고, 이로 인해 저널링 파일시스템이 생겨나게 된 것이다.

 

2. 저널링 파일 시스템은 어떻게 작동하나?

    그러면 이와 같은 저널링 파일시스템은 어떻게 작동하는지 살펴보자.

    대부분의 중요한 데이타 베이스 엔진들은 트랜잭션이라는 것을 이용한다. 트랜잭션은 몇 가지 특징을 만족시키는 기능들의 집합이라고 할 수 있다.

    트랜잭션의 ACID는 Atomicity, Consistency, Isolation, Durability를 의미하는데 여기서 가장 중요한 특징 중의 하나는 Atomicity이다. 이 특징은 한번의 트랜잭션에 속한 여러 작용들이 에러없이 종료되거나 변화없이 이상한 작업이 취소되는 것을 의미한다.

    이러한 특징은 Isolation과 함께 마치 부분적으로 작동할 수 없는 아주 기본적인 작동인 것처럼 보이게 하고 일관성을 유지 못하는 경우에 일관성을 유지하려는 문제와 관련하여 계속해서 데이타베이스 위에 존재하게 해주는 역할을 하게 된다.

    데이타 베이스는 이러한 기능을 이용하여 트랜잭션이 있는 동안 모든 작용을 로그 파일에 기록하게 된다. 이러한 작용이 기록될 뿐만 아니라 실행되기 전 작용인자의 내용이 모두 기록된다. 모든 트랜잭션이 일어난 후에 버퍼가 디스크에 쓰게 하는 작업을 수행하게 한다. 따라서 시스템이 비정상적으로 셧다운 된다 하더라도 로그를 추적하여 결국은 데이타베이스를 복구하게 된다.

    저널링 파일시스템은 이러한 동일한 기술을 이용하여 파일시스템의 작용들을 로그파일로 남겨두고 빠른 시간안에 복구가 가능하게 만들어준다.

    데이타 베이스와 파일시스템 저널링 사이의 차이라면 데이타 베이스는 사용자와 제어할 데이타의 기록을 남기고 파일 시스템은 단지 메타데이타만을 저장한다. 메타데이타라는 것은 파일시스템 내의 제어구조인데 i-node와 free block allocation maps, i-node map 등을 의미한다.

     

    (1)  저널링 파일시스템의 장점

    기존의 UFS와 ext2 파일시스템은 크게 두 가지의 문제를 갖고 있다.

    첫번째로는 새로운 저장공간을 다루는데 문제를 갖고 있는데 기존의 파일시스템은 특정 파일과 디렉토리, 사이즈에 맞게 설계되었는데 파일시스템의 구조가 고정된 파일 사이즈의 정보와 고정된 논리 블록 숫자를 저장할 비트수를 가지고 있다. 이러한 이유로 결국 파일 크기와 파티션 사이즈, 디렉토리 크기가 제한을 받게 된다.
    두번째의 큰 문제는 기존의 파일시스템이 새로운 저장공간의 관리가 부적절하다는 것인데 기존의 파일시스템의 구조가 새로운 객체의 크기를 때로는 다룰 수는 있지만 때로는 성능의 이유로 이러한 객체를 다루기에 부적합하게 된다.

      (1)-1  파일크기 처리와 자유 블럭 구조
      이러한 제한 사항들을 저널링 파일시스템은 해결했는데 파일 사이즈의 제한이 상당히 커졌다는 점이다.
       

       

      최대파일 시스템 크기

      블록 크기

      최대파일크기

      XFS

      18,000 페타바이트

      512바이트-64KB

      9,000 페타바이스

      JFS

      512 바이트블럭/
      4 페타바이트

      512, 1024,
      2048, 4096

      512Tb/
      512 바이트블럭

      4KB/
      32 페타바이트

      4 페타바이트/
      4KB 블럭

      ReiserFS

      4GB 블럭, 16Tb

      64KB까지이며 현재는 4KB로 고정

      4GB, 2^10
      2^10 페타바이트

      Ext3FS

      4Tb

      1KB-4KB

      2B


      XFS는 SGI의 IRIX에서 사용하는 대용량 파일 시스템이고 JFS는 IBM의대용량 저장매체를 위한 저널링 파일시스템이고 ReiserFS는 수세 리눅스가 개발한 저널링 파일시스템, Ext3는 Ext2 파일시스템의 다음 버젼이다.

      기존의 파일시스템의 구조는 파일시스템의 크기가 커지는 경우 남아도는 블럭을 트래킹하는 비트맵이라는 것을 이용하는데 이 비트맵 또한 크기가 커지게 된다. 여기에 기존의 파일 시스템이 사용하는 알고리즘을 이용하는 경우 남아도는 블럭을 위치시킬 시간이 오래 걸리기 때문에 성능이 저하가 된다. 이러한 문제를 해결하기 위해서 저널링 파일시스템은 B+Tree 방법을 사용하는데 이 방법은 동시에 몇 개의 자유블럭(free block)을 위치시키는데 사용한다. 결국 이렇게 되면 각 블럭에 대한 비트가 굳이 필요없게 되고 이러한 자유블럭이 파일시스템의 크기에 의존하지 않게 된다. 또한 자유블럭을 유지만 하면 성능면에 있어서도 아주 좋게 된다.

      (1)-2  커다란 디렉토리 다루기

      파일시스템은 디렉토리라는 것을 사용하는데 파일시스템의 관점에서 볼 때, 이는 디렉토리 엔트리의 모음이라고 할 수 있다. 이러한 디렉토리 엔트리들은 i-node 숫자와 파일이름의 조합으로 되어 있다.

      기존의 파일시스템은 디렉토리 엔트리를 디렉토리 내에서 하나의 리스트로 정렬을 시켰는데 엄청나게 많은 파일과 다른 디렉토리가 저장된 경우에는 이러한 방법은 그렇게 성능이 좋지 않게 된다. 저널링 파일시스템의 경우 디렉토리 엔트리를 하나의 디렉토리에 넣어버리고 모든 디렉토리 엔트리를 이름으로 구별하게 해버린다. B+Tree 구조(Balanced Tree로서 디스크에 저장된 기록을 빠르게 검색하게 도와주게 메인노드에서 아래 노드의 인덱싱을 이용하여 데이타 베이스에서 빠른 자료 접근이 필요할 때 많이 이용된다. 자세한 내용은 참고문헌을 참조하면 된다)는 어떠한 디렉토리 요청이 있는 경우파일의 i-node를 쉽게 위치시키게 되고 그만큼 빠르게 된다. B+Tree의 인덱싱 기능으로 인해 자료를 검색하고 접근하는데 기존의 비트맵보다는 상당한 시간 감축이 이루어진다.

      (1)-3  커다란 파일 다루기

      또한 커다란 파일을 다루는 경우에 있어서도 기존의 UFS나 ext2는 작은 파일을 주로 다루는 것만 생각하여 설계되었다. i-node는 UFS와 ext2가 파일에 관계된 정보를 관리하기 위해 사용한 구조이다.

      즉 파일에 대한 퍼미션과 파일 형태, 링크의 개수, 파일에 의해 사용되는 파일시스템의 블럭을 관리할 지시자와 같은 정보를 포함하고 있다. i-node는 간접적인 포인터와 2중 3중의 포인터를 포함하고 있는데 간접적인 포인터는 논리블럭을 지시하는 다른 포인터가 어디에 있는지 알려주는 것이고 2중-간접포인터는 이러한 간접포인터를 포함하는 블럭을 가리키는 포인터이고 3중의 경우는 이러한 2중 포인터들을 포함하는 블럭을 가리키는 포인터이다. 이러한 경우에 이러한 간접 포인터들을 이용하면 수많은 디스크 접근이 필요하게 된다. 결국 파일 사이즈가 커지게 되면 이러한 접근시간이 아주 많이 걸리게 된다.

      새로운 저널링 파일 시스템은 디스크 공간을 효율적으로 사용하여 커다란 파일을 지시하는 것을 좀더 효율적으로 다루게 된다. 간접적인 포인터의 사용을 최소화하기 위해서 저널링 파일시스템은 더욱더 큰 논리 블럭을 이용하는데 이는 블럭당 더 많은 정보를 넣을 수 있게 된다. 하지만 더욱더 큰 논리 블럭의 경우는 내부 프레그멘테이션(블럭크기가 특정 파일을 나누지 못하는 경우에 파일시스템은 새로운 블럭을 할당하게 되는데 이 블럭이 다 차지 않게 되는 경우 공간을 낭비하게 된다. 이를 내부 프레그멘테이션이라고 한다)을 증가시킨다.

      결국은 기존의 파일 시스템과 다른 부분은 B+Tree를 이용한 인덱싱이 이러한 효과를 가져온다고 보면 된다. 블럭 포인터를 이용하는 대신 이러한 extents(연속적인 논리블럭의 모음으로 데이타를 확인하는 시간을 대폭 줄여준다. 참고문헌 참조)을 이용하면 커다란 블럭을 이용하는 것과 같은 효과를 가져오게 된다.

      이는 결국 커다란 파일의 주소를 정하고 찾는 문제를 해결 해준다. 결국 새로운 i-nodes는 extents를 지시하는 직접적인 포인터를 유지하고 파일은 이 경우 더 많은 extents가 필요하게 된다. 작은 파일을 효율적으로 다루기 위해서는 그냥 i-node 내에서 파일의 데이터를 저장한다. 결과적으로 파일의 i-node가 들어오자마자, 파일의 데이타가 들어오는 것과 같다. 이는 심볼릭 링크에 매우 유용한 기술이다.

      이러한 잇점들을 가진 저널링 파일시스템은 대용량 서버에 이용되었는데 리눅스에 이용되면서 그 기능들이 더욱더 리눅스에 힘을 실어주게 된다.

       

    (2)  ReiserFS의 특징

    우리는 여기서 우리가 주로 사용할 ReiserFS에 대한 몇 가지 특징을 좀더 살펴보도록 하자.

    ReiserFS의 파일시스템의 핵심부분은 B*Tree (B+Tree의 발전된 버젼)에 기초하고 있다. 다른 점은 모든 파일시스템의 객체가 하나의 B*Tree 안에 존재하게 된다는 점이다. 각 디렉토리마다 다른 디렉토리를 사용하는 것이 아니고 각 디렉토리는 하나의 주 파일시스템의 하부 트리가 되는 것이다. 이것은 결국 ReiserFS가 복잡한 좀더 복잡한 인덱싱 기술이 필요하다는 것을 의미하게 된다. 또한 ReiserFS는 여기에 나온 다른 파일시스템과는 다르게 지원은 할 것이라고는 되어있지만 아직은 extents는 지원하지 않고 있다. ReiserFS는 i-node, 디렉토리, 파일 데이타를 각각stat_data 항목(item), 디렉토리 항목, 직/간접 항목으로 지칭하는데 간접항목은 형식이 없는(unformatted) 노드를 가리키는 포인터로 구성되어있다. 형식없는 노드는 파일 데이타를 저장하는 데 이용되는 논리 블럭이고 직접 항목은 파일 데이타 자체로 구성되어 있다. 이러한 항목들은 사이즈가 변하고 트리의 리프노드(leaf node)안에 저장된다.

    여기서 다시 한번 강조하지만 간접 항목은 트리내에 저장되지 않는다. 또한 ReiserFS의 여러 항목들은 주 파일시스템인 B*Tree안에서 동적으로 생성되고 배열된다. 이러한 방식을 사용하면 전체적으로 디스크 공간을 6% 정도 절약할 수 있다.

 

3. ReiserFS 준비하기

    아직 위에서 예로 언급한 여러가지 저널링 파일시스템이 모두 리눅스에 이용되는 것은 아닌데 현재로서 리눅스에서 가장 많이 이용되고 있는 것 중에 대표적인 것이 ReiserFS이다.

    국내 배포본중의 하나인 미지OS가 1.5버젼부터 ReiserFS를 이용하기 시작하였다. 물론 그때 미지는 lilo가 ReiserFS를 지원하지 않기도 했고 grub이 좀더 ReiserFS를 쓰기에 좋았기 때문에 grub를 부트로더로 사용하였다. 현재는 lilo의 버젼이 21.6이 넘어가면서 ReiserFS를 지원하여 lilo를 사용하는 리눅스 사용자들도 ReiserFS를 편하게 사용하고 있다.

    커널 2.4부터 정식으로 들어갔는데 정상적으로 ReiserFS를 사용하고 싶은 사용자는 2.4.2이상의 커널에서 사용하는 것이 좋을 것이다. 2.4.1-pre4 이전의 커널의 경우는 http://www.reiserfs.org에서 커널패치를 받아서 하면 된다. 2.4.1-pre8 이전의 커널의 경우는 그냥 2.2 대 커널의 reiserfs나 2.4.0-test10 reiserfs를 권한다. 레드햇 7.0을 사용하는 경우는 gcc 2.96으로 컴파일하면 에러가 생기므로 하지 않는 것이 좋다.

    기본적으로 지금 커널의 최신 버젼이 2.4.3 이므로 2.4.2 이상의 커널을 사용한다고 가정하고 본다. 그 이전의 커널은 위의 설명대로 받아서 사용하면 된다. 하지만 되도록 안정적인 reiserfs를 사용하려면2.4.2 이상의 커널을 사용하는 것이 좋을 것이다. 물론 http://www.reiserfs.org의 Download에 가서 받으면 된다.

    (1)  커널 컴파일 옵션

    필자의 Figure 1에서 보이는 것처럼 Reiserfs support 부분을

                                        Figure 1. Reiserfs 커널 설정 옵션

    <*>Reiserfs support

    바꾸면 되는데 그 밖에도 그 아래 Have reiserfs extra internal checking 은 하나하나 확인 해주는 옵션인데 굳이 그것까지 넣을 필요는 없다. 이 정도만해도 Reiserfs 파일 시스템을 사용하는 것에는 전혀 문제가 없다.
    물론 이 옵션을 넣고 .config로 커널 설정을 저장하고 나서 커널 컴파일을 하면 된다. 굳이 여기서 커널 컴파일하는 방법은 하지 않겠다. 필자의 경우는 데비안을 사용하는데 데비안식 커널 컴파일 방법은http://debianusers.org의 팁에서 커널이란 단어로 검색하면 가락쇠님이 쓰신 데비안식 커널 컴파일 방법을 참고 하면 된다.

    이런식으로 커널 컴파일을 하고 나면 Reiserfs를 사용할 준비가 된 것이다.

    (2)  Reiserfs를 만들기 위한 도구 준비하기

    우선 mkreiserfs, reiserfsck, resizer와 같은 Reiserfs를 만들기 위한 도구를 사용하기 위해서 도구를 http://www.reiserfs.org의 Download에서 받아온다. 현재 최신 버젼은 reiserfsprogs-3.x.0j.tar.gz이므로 이것을 우선 받아둔다. 그리고 아무 곳이나 압축을 푼다.

    #tar xvzf reiserfsprogs-3.x.0j.tar.gz
    #cd reiserfsprogs-3.x.0j/utils/
    #make ; make install

    이 과정을 거치게 되면 위의 mkreiserfs, reiserfsck, resize를 사용할 수 있게 된다. 실제로 다시 파일 시스템을 만드는데 사용하는 것은 mkreiserfs이고 reiserfsck 는 ext2 파일시스템의 fsck와 같은 기능을 하는 것이고resize는 Reiserfs로 쓰는 파일시스템의 크기를 조정하는데 사용된다.

    위의 방법은 일반적인 방법이다. 하지만 데비안의 경우는 reiserfsprogs이라는 패키지가 존재하여 그냥 dselect로 다음 Figure2에서처럼 선택해서 설치만 하면 된다.

                                       Figure 2. reiserfsprog 데비안 패키지 설치하기

    그러면 이번 호 기사는 저널링 파일시스템에 대한 이론적인 내용과 기존의 파일시스템을 바꾸기 위한 기본 작업을 했다. 다음 기사에는 실제로 ext2파일시스템으로 되어 있는 것을 reiserfs로 바꾸어 보도록 하겠다.

    (3)  ReiserFS를 지원하는 데비안 비공식 이미지

    필자의 경우는 주로 사용하는 배포본이 데비안인데 데비안 공식 사이트를 살펴본 결과 처음에 설치할 때 ReiserFS를 포테이토(2001년 4월 17일현재 2.2r3가 나온 상태이다)에 넣어서 사용할 수 있는 비공식 이미지가 있다. 이 이미지를 사용하여 처음으로 데비안을 설치한다면 굳이 노력해가며 ext2을 reiserfs로 바꾸는 작업을 안해도 될 것이다.

    비공식 이미지 사이트는 다음과같다. http://chao.ucsd.edu/debian/boot-floppies/ 이 사이트를 들어가면 우선 경고 문구가 눈에 들어오는데 모험심이 많은 분들은 한번 도전해보아도 문제는 안될 것이다. 여기서 rescue.bin, root.bin, driver-1.bin,base2 _2.tgz를 받아서 사용하면 될 것이다. 또한 포테이토를 사용하시면서 커널 2.4를 사용하고자 하는 경우 잘 안되서 고생한 경우가 많은 듯한데 소스리스트에 다음을 추가하여
     

    deb http://people.debian.org/~bunk/debian potato main
    deb-src http://people.debian.org/~bunk/debian potato main
    #apt-get upate; apt-get -u dist-upgrade

 

    를 하여 시스템을 업그레이드하고 난 후에는 문제 없이 사용할 수 있을 것이다.

    참고 자료:

    1. http://kldp.org
    2. “Introduction to ALGORITHMS”,
        T. H. CORMEN, C. E. LEISERSON,
        R. L. RIVEST, MIT Press, 1990.
    3. http://www.linuxgazette.com/issue55/florido.html
    4. http://www.reiserfs.org
    5. http://www.debian.org/News




▲ top

home으로...