Btrfs
는 그동안 비교적 짧은 역사를 갖고 있는데도 한동안, 여러 배포판들이 서로 먼저 Default 파일시스템으로 Delivery
하기 위해 꽤나 경쟁을 일으켜 올 만큼 현존하는 파일시스템과 앞으로의 미래에 대한 많은 문제들을 해결해 줄 차세대 파일시스템으로써, Hype cycle 의 많은 과정을 거쳐 왔고, 현재 그 막바지에 이르고 있는 것 같다.
따라서, 오랜기간 파일시스템을 개발해온 개발자들로 부터, 이 Btrfs 가 중요한 데이타 저장에 쓰여도 될지, 안정성에 대해 검증을 요구받게 되었는데,
사실 지금은, Btrfs 는 컨퍼런스등에서 사람들에게 긍정적인 내용을 들을 수 없는 상태이며 - 거품이고 과대포장이라는 평가를 받을 정도라고 한다.
어찌보면, Btrfs 는 점점 사라져갈 Filesystem 이 되는 게 아닌가 싶을정도로 위기라고 보여질 정도로...
하지만, Corbet 에 의하면 실재론 아주 그렇게 암울한 상황은 아니라는것. 그에 따르면, Btrfs 는 안정성과 성능을 역점으로 계속해서 개발되어 왔고, 많은 문제들은 해결되었고 사용자들은 이 약속된 Filesystem 에 대해서 다시 바라보기 시작하고 있다고 한다.
현재는 더 많은 사용자들이 이것을 사용하기 시작하고 있으며, OpenSUSE 는 이번 9월달에 다시 이 파일시스템을 기본 파일시스템으로 사용하는 것을 고려중이란다...
그는 앞으로 Btrfs 가 리눅스 파일시스템의 차세대 주자가 되기 까지, 다른 문제를 겪게 될 것이라고 언급하는데, 그것은 바로 느려터진 개발 속도 !! 이 부분은 나중에 설명하도록 하고,
일단 제목에 맞게, Btrfs 의 기본 디자인과 개발방식에 대해서 확인 하도록 하겠다.
참고로 그는 적절한 파일시스템 벤치마킹에 대한
올바른 비교항목을 선정하기 어려움이 있어, 벤치마킹은 하지 않았다고 한다.
(사실 맞는말이다 )
Btrfs 는 뭐가 달라졌음?
별로 오래되지는 않았지만, 리눅스 유저들은 아직까지 유닉스로부터 기원된 아주 약간 발전된 파일시스템 - ext3 같은 - 을 사용하고 있고,
ext3 의 경우 Block pointer 라는 것이 사용되는데,
이 파일시스템은 File 에 대한 모든 정보를 Main data structure(Super block 등) 에 저장하고,
각 파일의 inode 에는 파일의 데이타를 개별적인 Block 에 각각 저장하고
그에 대한 포인터가 저장되는 방식으로 디자인 되어 있는데,
이 디자인(아키텍쳐)은 파일이 작거나, 확장성이 떨어질때도 충분히 잘 동작 해 왔었지만,
대용량의 파일에 대한 성능 및 접근이 필요한 요즘, 디자인의 변화가 필연적이였다.
( 대략 1기가 파일은을 저장한다고 하면,
이에 대한 256K 의 개별
Block pointer 가 필요한 만큼 공간의 낭비가 따르게 된다..)
ext4 를 포함한 최근 파일시스템들은 "extents" 라는 개념을 사용하여,
Blcok pointer 를 대체하였고,
각각의
extent 는 인접된 (Contigonously) Block 의 그룹을 나타낸다.
이렇게 파일시스템이 인접하여(연속적으로) 데이타를 저장하게 함으로써,
extent 기반 저장기법은 파일의 저장공간에 대한 오버헤드를 상당히 줄일 수 있었다.
물론, Btrfs 역시 extents 를 사용한다.
그러나, 이것은 중요한 부분에 있어서 대부분의 다른 리눅스 파일시스템과
차이가 있는데 바로 그것은 "Copy-on-Write" (COW) 파일시스템이라는 것.
데이타가 덮어씌워져야 할 경우,
Ext4 에서는, 새로운 데이타를 스토리지상의
이미 존재하는 데이타의 앞부분에 그냥 바로 기록하여, 파일을 제거한다.
(복구가 어려운 이유)
Btrfs 는 이과정 대신, 덮어씌워진 "블럭" 을 파일시스템 안의 "다른 공간" 으로 옮기고,
새로운 데이타를 그 자리에 기록하여 파일을 덮어 쓴다.
COW 는 몇가지 상당한 유용한 기능을 제공하는데, 만약 데이타가 채 덮여씌워지지 않은 채 오랜시간이 걸리고,
그 와중에 만약 crash 또는 power failure 등이 발생했을 경우,
그것으로 부터 이전 파일들이 복구되어져야 할때, 간단한 과정을 통해 가능해야만 한다.
만약 이슈로 인해 트렌젝션이 완료되지 않았다면,
이전 데이타의 상태가 보전이 되야만 한다.
다른 파일시스템과 달리, COW 파일시스템에서는
이런식의 Crash 를 대비한 저널을 구분할 필요가 없게 된다는 것이다.
COW 는 또한 요즘들어 가장 주목받고있다고 볼 수 있는 스냅샷과 같은
몇몇 흥미로운 새로운 기능을 가능하게 해준다.
바로 스냅샷 이라는 기능인데, 이 스냅샷이란,
파일시스템의 Contents 를 가상으로 복제한 복제본을 뜻하며,
이것은 모든 전체 데이타의 실질적인 복제없이 상태를 기록하게 해주는 기능이다.
조금 더 설명하자면, 만약 각 스냅샷 또는 그 원본으로 부터 몇몇 특정 과거의 지점에서
데이타의 블록이 한두개 변경이 되는 경우,
스냅샷은 나머지 바뀌지 않은 데이타들을 그대로
남겨둔 채로 공유하고
변경된 그 몇개의 블록만 복사하여 보관한다.
이런 스냅샷을 이용하면 "Time machine" 과 같은 기능
- 시간대별로 기록해서 그 시점으로 roll-back 하는걸 표현한듯,ㅋ -
을 가능하게 만들며,
update 가 실패한 시스템의 간단한 복원도 쉽게 가능 할 수 있게 된다.
또 다른 중요한 Btrfs 의 기능은 내장된 volume manager 이다.
Btrfs 는 다중의 물리적
디바이스를 묶어 파일시스템 단위에서 레이드처럼 사용할 수 있다.
어떤 주어진 볼륨에 대해 내부적으로 Subvolume 으로 split 또한 가능하고,
해당 서브볼륨을 독립된 파일시스템 또는
하나의 물리적 볼륨으로 공유 할 수도 있다.
그래서 Btrfs 는 큰 스토리지 pool 내에서 필요한 시스템의 스토리지 전부 또는 부분으로
그룹 지을 수 있으며, 파일시스템과 pool 사이의 공유, 각각의 사용량을 제한 할 수도 있다.
Btrfs 는 다른 리눅스파일시스템에 의해 지원되지 않는 광범위한 다른 기능도 제공하는데,
바로 메타데이타와 데이타 모두의 checksumming 을 완벽히 지원하여,
하드웨어로 인한 데이타 corruption 에 대해서 견고함을 얻게 해주는 것이다.
비록 전체 풀의 무결성을 검사하는 일은 많은 비용을 필요로 하지만,
이는 재설치의 횟수를 줄여주는 큰 역할을 한다.
압축된 데이타형태 (compressed data) 로 디스크에 저장이 가능하며,
send/receive 의 기능은 스키마의 증분백업에 사용 될 수 도
있다.
온라인 Defragmentation 메카니즘은 운영중인 파일시스템에서 단편화된 파일들을 수정할 수 도 있다.
3.12
커널 에서는 Offline 중복제거
- 중복된 데이타를 갖는 블럭을 검색, 통합/제거해주는: De-dup(plication) -
기능역시 추가 될 것으로
보인다
이것은 COW 방식에 대한 접근이 없이는 이루 질 수 없는 부분이다.
명백하게, 일반 파일시스템의 경우, Garbage collection 등의 정리가 필요하거나,
모든 블럭들을 그대로 복제하기 때문에 사용 가능한 공간을 매우 빠르게 잠식당하게 된다.
블록에 대한 카피에 걸리는 시간은 훨씬 더 걸릴 수 있고,
파일시스템에서 요구되는 메모리의 양도 증가시킨다.
COW 는
파일의 단편화로 인한 성능 저하역시 줄여줄 수 있다.
하지만 모든 이 "빛나는" 기능들을 Btrfs 를 통해 사용하는 것은 아직 자유롭지 못하다.
대부분의 관리자들은
Btrfs 을 사용함으로써 얻는 이득보다 손해가 더 크다고 생각 할 것이며,
그 사이트들은 ext4/xfs 와 같은 기존 파일시스템을
도입할 것이다.
비록, Btrfs 와 함께 제공되는 유연성과 기능들이 매우 매력적으로 보임직 하더라도,
그들은 이 Btrfs 가 사용해도 될 만큼 검증이 되어 있어야지만,
많은 시스템에서 사용되는 모습을 볼 수 있을 것이라고 Corbet 은 말하고 있다..
개발상태
Corbet 은 한 컨퍼런스 복도에서 Btrfs 의 개발속도가 너무 느리다는 불평을 들었으며,.
그래서 호기심으로 그는, Kernel 에서 Btrfs 코드에 대한
changeset counthistory 를 확인한다. :
Year
Changesets
Developers
2008 (2.6.25—29)
913
42
2009 (2.6.30—33)
279
45
2010 (2.6.34—37)
193
33
2011 (2.6.38—3.2)
610
67
2012 (3.3—8)
773
63
2013 (3.9—13)
671
68
그는, 이 숫자를 봤을 때, Btrfs 의 개발이 느리다고 보이지는 않았고,
2010 에는 확실히 느리게 작업 한 것으로 보이지만,
개발자의 수와 체인지셋의 숫자를 통해,
그들이 2010 년 이후 꾸준히 작업하고 있음을 반증 하는 것으로 보인다고 얘기했다.
이 숫자들을 보았을때 기억할만한 몇가지가 있는데,
한가지는, 이 새로운 파일시스템의 기능들에 대한 작업이 꽤 오래전부터 시작되었다는것,
게다가 2013 에는 Changeset 을 보았을때 상당히 많은 문제들을
거의 해결 한 것으로 보인다는 점이고,
다른 한가지는
Btrfs 의 창시자 Chris Mason 이 최근에 커널 patch 를 많이 안했다는것.
즉,이 통계는 커널에 대한 filesystem patchset 을 통계 낸 것이므로,
그가 Btrfs progs code 를 대부분 userspace 로 옮겨 작업했기 때문에,
패치셋의 횟수가 줄어 들 수 밖에 없다는 것이고,
페이스북을 통해 보았을때, 그들이 꽤나 다른 이슈로 바빴던 것으로 보여진다는 점이다.
( 그의 말로는 집을 최근에 구매해서 인테리어에 바쁘다고 한다.
하여간 외국애들은 DIY 짱! 근성이야 -_- ㅋ )
정리하자면, 최근, 명백하게도, Btrfs 는 새로운 코드를 작성하는 양이 줄어들었고,
현재까지도 훌륭한 개발자들이 많은 노력을 하고 있으므로,
언젠가 안정된 상태로 머지 않아 모습을 나타나게 될 것이라는 것!!!!
Corbet 은 머지않아 Default filesystem 으로 많은 배포판에서 만나게 될 것이라고 전망하고있다.
다음호에서는
LWN 에서는 다음호부터 실제 Btrfs 를 설치하고 생성하고 사용하는 부분을
다룰 예정이라고 한다. +.,+...포괄적으로다가...
첨언하자면, 난 현재, 실제로 Oracle Linux 6 에서 Btrfs 를 이용하여,
Unbreakable Kernel git 를 받아 공부하고 있다.
이는 스냅샷 기능을 주로 이용하기 위한 것이다.
작업시 snapshot 을 미리 뜨고 작업한다는 점.
또 한가지 팁으로, yum-snapshot 이라는 플러그인이 있는데,
이걸 사용하면 yum 을 통해 패키지가 업데이트 될때마다
Btrfs 로 되어 있는 파일시스템을 자동을 찾아 날짜로 스냅샷을 생성해 준다.
사실 file 에 대한 data loss 문제를 포함하여 (젤 큰문제) 몇가지 이슈들이 남아있지만,