RSS구독하기:SUBSCRIBE TO RSS FEED
즐겨찾기추가:ADD FAVORITE
글쓰기:POST
관리자:ADMINISTRATOR
Linux  2006/09/08 14:07
출처 블로그 > 離別後愛
원본 http://blog.naver.com/marine150/140002249563

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가 들어오자마자, 파일의 데이타가 들어오는 것과 같다. 이는 심볼릭 링크에 매우 유용한 기술이다.

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

2006/09/08 14:07 2006/09/08 14:07
이 글에는 트랙백을 보낼 수 없습니다
웅쓰:웅자의 상상플러스
웅자의 상상플러스
전체 (379)
게임 (5)
영화 (2)
기타 (23)
맛집 (5)
영어 (2)
대수학 (3)
형태소 (5)
Hacking (9)
Linux (112)
HTML (48)
Application_developing (48)
Web_developing (102)
Window (11)
«   2024/05   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
  1. 2016/01 (1)
  2. 2015/12 (3)
  3. 2015/10 (3)
  4. 2015/03 (2)
  5. 2015/01 (4)