Skip to content

파일 시스템 EXT3

ext3는 아시는 대로 범용 저널링 파일 시스템입니다.

일반적인 속도, 일반적 안정성, 간편한 장애 처리 방법, 일반적인 트렌젝션, 일반적인 자료구조를 가지고 있습니다.

그럼 우리가 왜 ext3 파일시스템을 사용하는가에 대해 얘기해 보겠습니다.

먼저 ext3 파일시스템과 같은 저널링 기술을 이용한 파일시스템을 얘기 하기 전에 과거의 저널링 파일시스템이 본격화된 시점부터 살펴봐야 할 것 같습니다.

레드헷 6 에서 7으로 넘어가면서 리눅스가 엔터프라이즈 급 운영체제로 넘어가면서 클러스터링과 서버에서 중요한 자리를 차지해 가면서 저널링 파일시스템은 필수적인 요건으로 자리잡았습니다.
우리가 MySQL의 MyISAM대신에 InnoDB 엔진을 쓰는 이유와 같습니다.
ext3는 저널링 기술이 필요했던 당시 ReiserFS와 더불어 유일하게 저널링 기술을 지원하는 파티션이었습니다.

그러면 왜 ext3라는 파일 시스템이 가장 사랑 받는 파일시스템이 되었을까요?

ext3파티션의 성공?을 얘기하는 것 보다는 ReiserFS의 실패?를 얘기하는 게 좋을 것 같습니다.
ReiserFS의 실패 이유! 바로 시스템의 다운 시 fsck의 복구율이 ext3에 비해 좋지 않았기 때문입니다.

저널링 파일 시스템이란 백업 및 복구 능력이 있는 파일 시스템을 말합니다. 디스크에 있는 인덱스가 갱신되기 전에 관련 내용이 로그에 기록되기 때문에 정전이나 다른 문제 때문에 인덱스에 이상이 생기더라도 다시 시스템을 재가동하면 운영체제가 로그를 보고 인덱스를 재 작성 및 복구하는 기능입니다.

예를 들어 디렉터리 정보를 변경하고 있다고 가정해봅니다.

거대한 디렉터리의 다섯 번째 블록에 있는 23개의 파일 만 수정하였고 디스크에서는 이 블록을 쓰고 있는데, 전원이 나가 해당 블록이 불완전하게 되어 오류가 발생해 버렸습니다.
리눅스가 리 부팅 되면 “fsck” (file system check)가 실행되어 파일시스템의 정보를 체크하고 올바른 블록을 만들어갑니다. Fsck는 오류가 발생한 디렉터리 엔트리를 발견하고 이것을 수정하려 합니다. 물론 fsck가 손상된 곳을 확실히 고쳐낸다는 보장은 없습니다.
때때로 디렉터리를 잃어 버릴 수도 있으며 파일 시스템이 거대해질수록 시간은 그만큼 길어 집니다. 만일 수 기가바이트가 되는 파일이 많이 있다면, 체크 시간은 10시간 혹은 그 이상이 될 수 도 있습니다. 이 시간 동안 시스템을 사용할 수 없게 됩니다.

이러한 경우 ReiserFS의 저널링 파일시스템은 ext3에 비해 만족할 만한 복구 시간과 복구율을 보여주지 못했습니다.
일 예로 다섯 번째 블록을 고치려다 모든 블록에 문제가 생기는 경우도 발생했으며 복구 중 시스템이 다운되는 경우도 발생했습니다.

ReiserFS의 이런 장애가 계속 보고 되면서 사용자는 비교적 안정적인 복구 능력을 보이는 ext3 파일시스템을 선호 하게 되었습니다.
이렇게 ReiserFS는 초기의 불안한 모습으로 많은 리눅서 들이 등을 돌리게 됩니다.

예전에 ext3 파일시스템이 가장 일반적인 파티션이 된 것은 이름 때문이라는 생각을 한적이 있었습니다.
과거 리눅스에서 ext2 파일시스템에서 저널링 기능을 추가한 파일시스템의 이름이 ‘ext3’였기 때문에 많은 사람이 ext2의 업그레이드 버전쯤으로 여기고 사용하지 않았나 하는 생각입니다.

각설하고 위에 얘기한 안정적인 복구 능력이 ext3 파일시스템의 선택에 가장 큰 이유입니다.
(ext3 파일 시스템도 완벽한 복구율은 보여주지는 않았습니다. 하드디스크와 같은 자기장치를 하드웨어로 하는 파일 시스템에서는 100%의 복구는 불가능 합니다.)
그리고 ext3 파일시스템은 ext2의 파일 메타 데이터 허가권, 소유권, 생성/접근 시간과 같은 정보가 같습니다.
거기에 ext2에서 ext3로 간편하게 컨버팅 가능한 툴을 기본 제공했습니다.

서버를 책임지는 엔지니어는 새로운 것에 대한 기대와 두려움을 같이 가지고 있습니다.
ext3 파일 시스템은 ext2 파일 시스템에 익숙해 있던 리눅서 엔지니어에게 새로운 것에 대한 두려움을 많은 부분 해소시켜줬을 겁니다.

이렇게 과거 ext3 파일시스템이 많은 리눅서들이 선택한 원인을 살펴봤습니다.

그럼 이제 현재! 사용할 수 있는 파일시스템에 대해서 얘기해 보겠습니다.

시간은 지나고 강력한 저널링 기술과 획기적인 자료구조를 들고 나온 파일시스템들이 리눅스에 포팅 되었습니다.
바로 업그레이드 ReiserFS, JFS, XFS, GFS와 같은 파티션들이 그들입니다.

하지만 깊이 알아볼 필요는 없습니다. 이미 그 한계를 드러냈기 때문입니다.

업그레이드 ReiserFS = 한번 놀랜 마음

JFS = 느립니다.

XFS = 한때 raw IO와 같은 처리 속도와 혁신적인 자료구조, 그리고 100만 테러바이트 지원이라는 어마어마한 스펙을 가지고 리눅스에 포팅 되었습니다.
하지만 커 널에서 직접 제어하는 방식이 아니라 4개의 데몬 에서 제어하는 방식이라 장애 시 안정성에 대한 의구심으로 많이 사랑 받지는 못했습니다.
(데몬이 죽으면 파일시스템도 정지됩니다.)

single GFS = GFS 파일 시스템은 태생이 네트워크 파일시스템을 기본으로 하는 파일시스템입니다.
아직 레드헷 5를 테스트 해보지 않아 어떤 성능을 보여줄 지는 알 수 없습니다.
하지만 이미 클러스터링에서 사용되었던 파일시스템인 만큼 안정성은 이미 입증되었다고 생각합니다.

문제는 레드헷 5 버전에 탑재되었다는 겁니다.
경험상 레드헷에서 발표되는 버전 중 첫 번째 숫자가 올라간 버전은 기존 버전에 비해 많은 부분이 변경되었기 때문에 충분한 시간을 가진 후 사용해 왔습니다.
즉, 레드헷 5.1 버전이 발표되는 시점이 single GFS 파일 시스템을 테스트 하는 적절한 시점으로 생각됩니다.

EXT3 = 가장 안정적인 성능, 안정적인 복구율. 그러나 대 용량에서 성능 저하가 있다.
위와 같은 이유로 현재까지 사랑 받고 있는 파일 시스템입니다.
안정성 면에서는 타의 추종을 불허합니다.
하지만 저널링 방식이 logging 방식이라 용량이 늘어날 수록 logging 정보가 커집니다.
테러바이트 이상의 대 용량에서 성능이 저하됩니다.

파일시스템의 선택에는 그 파일시스템이 필요한 이유가 있어야 합니다.
실제로 /usr와 같은 read가 주요한 파티션은 ext2와 같이 빠른 파일시스템이 보다 효율적입니다.
그러나 /var와 같은 write가 주요한 파티션은 ext3와 같은 저널링 기술이 필요한 파일 시스템이 효율적입니다.
하지만 안정성의 이유(MyISAM과 InnoDB와 같은 이유)로 현재 우리가 사용하는 리눅스 머신은 모두 ext3 시스템을 사용하고 있습니다.

일반적인 리눅스 서버의 경우 ext3 파일 시스템이면 충분합니다.

그러나 대 용량에서의 파일시스템은 이제 변화해야 하는 시점이 다가왔습니다.
앞으로 테러바이트 이상에서의 파티션은 ext3외의 다른 파티션이 필요 할 것으로 생각됩니다.

 

Published inLinux