Swiss army knife 에 비견되는 BtrFS - 1부

요즘 이것저것 새롭게 하는게 많아 뜸해져 있던 차에,

간만에 BtrFS 에 대해서 스위스 아미 나이프에 비교한 LWN 기사를 읽고

잽싸게

추후에는 XFS, NoSQL 류 그리고 클라우드에 대한 패러다임 을 얘기해 보고 싶다.

1. Intro

BtrFS 는 Ohad Rodeh 의 B-Tree 자료구조를 바탕으로 만들어진 파일시스템이다.

Ohad Rodeh 라는 아저씨는 원래 IBM 에서 근무하고 있다가, B-Tree 자료구조의

단점을 극복한뒤 Linux File and Storage Workshop 2007 에서

새로운 Btree 구조를 발표 하고 오라클로 옮겨간다음에

그쪽에 있던 여러 파일시스템개발자들이랑

죽이 맞아 열심히 개발하게 된 것인다....
(암튼 유명하다...)

이것은 리눅스에서 보다 낳은 효율적인 스토리지 관리와 무결성을

보장하기위해 개발되어 졌다.

이녀석은 Raid 기능, 스냅샷, 데이타 압축, 암호화 기능 같은

고급 기능들을 내장하도록 설계되어 졌고, Checksum 을 통해

모든 메타데이타들과 데이타들을 확인 할 수 있고 또는 선택 할 수 있게 만들어졌단다.

이번 포스팅에서는 사실 그냥 간단하게 BtrFS 가 갖고 있는 기능들과,

그것들이 앞으로의 미래에 어떤 영향을 주게 될건지에 대한 소개정도만 할 예정이다.

원래 오래전부터 스토리지에 대한 관리부분은 리눅스에서 지원되지 않고 있었다.

고작 전통적인 mdadm 이나 dmraid 를 이용해 소프트웨어 레이드를 구성하는정도뿐..

그나마 LVM 이 도입되면서부터 일반적인 스토리지풀에서부터 가능한 논리적 디스크그룹으로

나누어 하나의 스토리지 풀에서 기본적인 매니지먼트가 가능하게 되었다.

그러나 이방법은 스토리지에 대한 설정이 변경이 필요 할 경우 복잡한 과정을

겪어야 한다는 단점이 존재했다.

예를들어, Home 디렉토리에 공간을 추가하기위해 논리디스크를 추가하려고 하면,

우선적으로 디스크 초기화(pvcreate) 를 하고, LVM Volume 그룹에 디스크를 추가 한 후,

논리볼륨을 extend 한 뒤, 파일시스템의 resizing 을 해주어야만 최종적인 확장이 가능하다.

BtrFS 의 목적은 이 모든 과정들을 수정하는 것에 있다.

BtrFS 의 경우 확장을 요구할 경우엔 매우 간단하게 한줄의 명령어로  이루어 진다.

비슷한 예로 스냅샷에 대해서도 얘기 할 수 있다.

LVM 을 사용하면, 볼륨그룹에서부터 남은 공간이 얼마나 있는지 확인이 필요하고,

가득 찬 상태라면 스냅샷을 생성한 볼륨등이 deactive 되어 접근 할 수 없게

되어버리지만, BtrFS 의 경우 남은 공간에 제약은 여전하지만,

간단하게 df 를 통해 남은 공간을 확인 하기만 하면 되고, Snapshot 을 찍는데

들어가는 용량 비용은 물론 시간또한 거의 소모되지 않는다.


2. B-Tree 에 대해서.

BrtFS 는 여러개의 B-Tree 로 메타데이타를 분할한다.

B-Tree 는 하나 또는 그 이상의 노드나 가지들로 구성되어 있고,

정보는 각 트리에 원본 키값과 함께 저장되어 진다.

노드들은 최소한의 키를 갖게되며, 다음 하위 레벨에서 노드 또는 Leaf 에

디스크위치를 저장하고, 실제 데이타는 또 다른 각 잎들에 저장되게 된다.

뭐 대략적으로 B-Tree 에 대해서 특징들만 설명하자면,

연결된 노드들과 각 노드들이 갖고있는 leaf 레벨에서 연결정보와

최소한의 데이타만 보유 한뒤 연결점들을 통해 인접한 Data 에 대한

빠른 접근을 가능하도록 하는게 특징이라고 할 수 있다.

쉽게 말해서 인접한 트리들과 인접한 정보들을 나무의 나뭇잎과 같이

가지들로 잘 연결시켜 놓았기때문에, 작은 파일들에 대한 검색에 대해서

매우 빠른 결과와 잇점을 가져 갈 수 있다는 얘기!!!

자세한건 자료구조쪽에대해서 따로 살펴보라 오래되서 생각잘 안난다 ㅡ,.ㅡ

자 그럼 왜 BtrFS 라는 이름을 갖고 있게 된건지 알 수 있을것이다.

말그대로 B-tree File System 이라는 것이다.

외국에서 이걸 부를때 Butter (버터) FS 라고 부르면 된다고 정의되어있다!!!

즉, BtrFS 로 생성되는 파일시스템은 다음과 같은

여러가지의 B-Tree 알고리즘의 조합된 구조들로 구성된다.

  @ Tree root B-tree
  @ Chunk B-tree
  @ Extent B-tree
  @ Checksum B-tree
  @ Filesystem B-tree

이렇게 파일시스템에서 필요로하는 모든 구조체(?) 들을

B-Tree 알고리즘으로 관리하겠다는 얘기!!

그리고 이렇게 다양한 B-Tree 알고리즘의 집함으로 인해

유연성을 확보 할 수 있게 된것이라는 말씀...


3. Snapshot ??

BtrFS 의 스냅샷은 매우 간단하다.

BtrFS 의 스냅샷은 snapshotted 이라는 따위 이름의 일반적 디렉토리 아래

그냥 디렉토리처럼 위치한채, 일반 디렉토리들처럼 자유롭게 이동 및 탐색이 가능하다.

기본적으로 모든 스냅샷은 쓰기가능하도록 되어있는데, 읽기만 가능하도록 할 수도 있다.

이 스냅샷은 매우 유용하고 뛰어난 활용이 가능한데,

예를들어 단순히 백업 후 바로 완료된 백업들을 지우고자 할때는

읽기전용 스냅샷으로 보관을 하여 일반적으로 사용 할 수 있고,

시스템을 업데이트할때 오류가 발생될 가능성이 있으므로 쓰기가능 스냅샷을 찍은뒤,

오류가 생겨 시스템이 정상동작 하지 않을때,

단순히 일반 파일시스템처럼 쓰기가능 스냅샷을 이용해 부팅하여 시스템을 복원 할 수 있다.

스냅샷을 만드는 방법또한 매우 쉽다.

Original Data 위치 생성

# btrfs subvolume create /Data_Org
# btrfs subvolume create snapshot /Data_Org /Data_snap

이라고 해주면 간단하게 스냅샷이 만들어진다.

물론 subvolume 으로 디렉토리를 선언해 줘야 하는 부분이 있지만 간단하지 않나?

[mirr@Mirr-N ~]$ df -h
Filesystem                    Size  Used Avail Use% Mounted on
rootfs                         21G   15G  5.5G  73% /
devtmpfs                      1.8G     0  1.8G   0% /dev
tmpfs                         1.8G  252K  1.8G   1% /dev/shm
/dev/mapper/vg_mirr-LogVol00   21G   15G  5.5G  73% /
tmpfs                         1.8G   50M  1.8G   3% /run
tmpfs                         1.8G     0  1.8G   0% /sys/fs/cgroup
tmpfs                         1.8G     0  1.8G   0% /media
/dev/sda1                     497M   97M  376M  21% /boot
/dev/mapper/vg_mirr-LogVol02  100G   50G   46G  52% /home
/dev/mapper/vg_mirr-LogVol03  200G  199G  1.3G 100% /data
/dev/mapper/vg_mirr-LogVol05   80G   65G   12G  85% /data2

[mirr@Mirr-N ~]$ btrfs filesystem df /data2
Data: total=67.01GB, used=64.27GB
System, DUP: total=8.00MB, used=16.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=1.88GB, used=253.17MB
Metadata: total=8.00MB, used=0.00

게다가 위와같이 이미 난 수십개의 스냅샷을 찍은 상태였는데도

실제적인 용량에 변화는 거의 없었다.

말 그대로 스냅샷이기때문이고, 각기 다른버젼(내용)의 스냅샷도 충분히 가능하다.

실제 원본에 대한 변화된 메타데이타를 위주로 갖고 있기때문인데, 매우 유용한 기능이다 역시.

근데 약간 IBrix  6.0 의 스냅샷과도 느낌이 매우 비슷하다....


4. Future Proof

Btrfs 는 64비트 파일시스템이다. 이녀석은 2의 64승이 되는 수의

Inodes 까지 핸들링 가능하다는것이고,

이것은 단순히 하나의 파일시스템 트리당 가능한 수이므로,

subvolume을 여러개 생성할 경우 그 이상의 Inode 들을 생성 할 수 있다는 것이다.

여기서 바로 작은 파일에 강하기 위해 태어난 녀석임을 알 수 있어진다.

서브볼륨들 역시 2의 64 승까지 생성이 가능하므로

파일의 아이노드 수는 무제한이라고 볼 수 있다.
(재밌게도 df -i 를 해보면 0 으로 나온다 ㅋ. )

이점이야말로 Btrfs 가 얼마나 미래지향적으로 개발되었는지를 알려 주는 항목이다.

이점을 이용하여 BtrFS 는 8 Exabytes 까지 확장이 가능하다.

즉 스토리지를 ScaleOut 하여 리눅스자체에서도 무리없이 관리 될 수 있도록 해준다는 얘기!!!


5. Extra Features

BtrFS 는 일반적인 파일시스템과 동일한 모양의 Directory 트리 들을 보여주고 있다.

하지만 기존의 Ext 파일시스템에서들의 Directory Re-optimizing 이 필요 없다.

B-Tree 의 서브볼륨에서 관리되어지고 있기때문에

구지 인덱싱을 다시할 필요가 없다는 것이다 쉽게말해..

또한 Btrfs 역시 일반적인 Filesystem 들과 동일하게 Chunk 단위로 할당한다.

다만, BtrFS 의 Chunk 스케일은 그것들과는 비교되지 않게 대인배스럽다.

무려 1G 의 Chunk 와 256 M 의 메타데이타를 기본적인 Chunk 단위로

사용하고 있기때문이고, 이것은 각 하드웨어 및 소프트웨어 Raid 들의 특성에도

맞추어 지기 위한 것이라고 한다. (사실 이부분은 좀 어려웠다...)

아무튼 이렇게 메타데이터와 DataChunk 를 나눠서 관리한다는

특성은 매우 대단한 점중 하나인데,

여러개의 스토리지 디바이스들이 하나로 묶여 있을때

각 디스크들에 데이타 Balancing 을 할 수도 있고,

특정 디스크에 필요한 데이타를 몰아 넣을 수도 있다는 것은

서비스 종류에 따라 매우 큰 유용성을 가져다 줄 수 있기때문이다.

위에서 btrfs filesystem df 를 한 모습을 보면 알 수 있다 ㅋ

이밖에도 여러가지 최신의 파일시스템들이 필요로 하는 기능들을

리눅스 커널차원에서 지원하고 있는데,
(Checksumming, Compress 등 )

이런 부분이 왜 필요로 하는지는 추후로 Big Data 를 위한 No SQL 관련된

부분들을 설명 할때 다시 정리하거나,

따로 각 부분들을 설명 후 컨버젼시하게 따로 작성하던가 해야 할 것 같다.
( 꼬리에 꼬리를 무는경우가 많아서 ㅋ )

추가적으로 BtrFS 의 강점중 하나는 SSD 핸들링에 관한 부분이다.

BtrFS 또한 TRIM 을 지원하고(기본은 off), B-tree 의 강력한 인덱싱을 이용하여

빠른 Seek time 을 가능 하도록 한다고 한다.

요즘 빅데이타의 대항마라기보다는 대항하는 방편으로 Data 의 하드웨어적

구조방식을 개선하는 연구도 활발한 편인데,

메타데이타등 주요 키인덱싱에 필요한 부분들을 SSD 로 선택해 사용하고,

일반 SATA 나 SAS 디스크들을 동시에 한 장비에서 사용하면서 데이타를

동일한 또는 다른 파일시스템들에 계층적으로 저장하는 방식으로 빠르고 안정되며,

대용량의 데이타를 저장 및 제공하는 방식들에 대해서

매우 영향을 미치는 파일시스템이라고 볼 수 있다는거~

일단 1부니까 여기까지하고, 담포스팅에서는 성능과

ZFS 등과의 비교 위주로 정리를 해봐야 겠다.