Btrfs 에 대한 두번째 문서는 간단한 설치와 사용법을 알아보는 getting started 문서이다. Brtfs 파일시스템의 코드는 kernel 2.6.29 (2009년) 부터 메인라인에 포함된 이후로, 대부분 in-kernel 개발코드가 업스트림에 반영되어 왔기때문에, 메인라인 커널에서 이 모든 것을 사용 할 준비가 되어있는 것으로 여겨졌다.
많은 사용자들은 이 Btrfs 가 실무에 사용되는 것이 가장 좋은 파일시스템이라는 얘기가 메인라인 릴리즈로부터 언급되기를 계속 고대하고 있는 중이었지만, 안타깝게도, Btrfs 는 아직까지 활발하게 수정작업이 진행중이며, 왜 아직까지 수정이 필요한것인지에 대해서는, 이 수정된 코드들이 Btrfs development reposity 에서 제공되고 있으나 그 양이 너무 방대하기 때문에 말로 설명하는 것 보다는 이 수정된 코드들을 직접 수행해 보면서 비교하는 것이 더 좋을 것으로 Corbet 은 판단하고 있었다.
Btrfs 의 관리와 생성에 대한 user-space tools 는 다음 GIT site 에서 가져 올 수 있다 :
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git (참고로, Git 는 기존의 svn 이나 cvs 같은 distributed 버젼관리 프로그램인데, Unix 계열의 상징이라고 할 수 있는 Emacs 마저도 balsarzarr 라는 툴에서 git 로 옮겨가기로 결정 할 만큼 편하고 강력한버젼관리 서비스이다. )
최근까지, 마지막 btrfs-progs 의 릴리즈 버젼은 2009년 1월에 만들어진 0.19 이다. 비록 11월 말쯤, 버젼 넘버가 v3.12 로 설정되었지만, 이것은 새로운 세대에 커널 대한 릴리즈 넘버링이 도입되었기 때문이라고 얘기하며 - 커널 버젼이 2.6대가 아닌 3.x로 급격히 바뀐 것에 대해서 얘기하는 것임 . Chris mason (Btrfs maintainer) 는 커널의 진행주기에 맞춰 btrfs-progs 의 릴리즈를 기대 해 보아도 될 거라고 언급했고, user-space side 작업을 많이 필요로 하는, 많은 개발자들이 기뻐할 만한 소식이 될 것이라고 얘기했다.
한편, Btrfs 의 진지한 사용을 하기 원한다는 것은, 유저스페이스 유틸리티 에 대한 작업 및 수행 요구가 많아지고 있다는 것으로 볼 수 있다. 몇몇 배포판들은 다른 것들보다 더 긴밀하게 btrfs-progs repository 의 진행도에 맞춰, 버젼 라인업을 준비하기도 한다. - Fedora 19 부터는 이미 v3.12 를 수용했고, 페도라 유저는 해당 버젼을 위해 따로 빌드 할 필요가 없었다. 물론 Btrfs-progs 에 대한 진행도를 맞춰가지 않는 배포본 사용자는 빌드해야 한다.
Creating and mounting Btrfs filesystems
Btrfs 의 생성을 위해서는 별로 놀랄만한 부분 없이, mkfs,btrfs 를 이용한다. 사실, 그냥 mkfs 커맨드에서도 포함되어 있다.
# mkfs.btrfs /dev/partition-name
물론, mkfs.btrfs 역시 몇가지 옵션을 갖고있다.:
이미 존재하는 파일시스템에 그냥 바로 덮어서 생성하는 --force, Label 을 설정 할 수 있는 --label, data와 metadata를 혼합해 사용하는 --mixed (속도의 저하가 발생 하ㄹ 수 있으므로, 특정 상황에서만 추천됨 - 맨페이지 참조).
Btrfs 는 일반적인 mount 커맨드로 사용이 가능한데, 대부분의 특정한 파일시스템들 처럼, 몇가지 특별한 마운트 옵션을 갖고있으며, 파일시스템 생성 후에도 필요에 따라 적용 할 수 있게 한다 :
autodefrag Defragmentaion 을 백그라운드로 수행 시켜 주는 옵션이다. 아직까지 모든 워크로드에 대한 최적화가 제공되어 있지 않으므로, 개발상황에서만 사용하는 것을 권장하고 있다. (개인적으로는 일반적인 상황에서는 전혀 문제없이 사용가능하므로, 추천하는 옵션이다)
compress [=zlib|lzo|no] 앞서 글이서, 압축된 데이타저장을 언급했던 부분에 대한 옵션이다. Lzo 와 zlib, 두가지 압축 알고리듬을 이용 할 수 있으며, compress-force 옵션을 통해 압축보관이 어려운 형식의 파일 일지라도, 압축하여 기록 하도록 시도 가능 하다.
nodatacow COW 매카니즘을 사용하지 않겠다는 것인데, 사실 이러면 뭐하러 사용하는지 의미가 없어지는 부분이 있으나, data check summing 과 compression 을 모두 disable 시켜주는 기능을 하며, Large database files 이 사용되야만 하는 상황등 특별한 퍼포먼스에 중점이 필요한 몇몇 상황에서 사용할 수 있다.
nodatasum Data checksum 기능을 끄는 옵션, 이미 생성된 파일에는 적용되지 않고, 새로 생성되는 경우 적용된다. 데이타 무결성에 대한 검증이 필요 없는 경우 성능향상을 위해 사용된다.
Btrfs 를 마운트해 사용하는 것은 다른 일반적 파일시스템을 사용하는 것과 비슷하다. 다만, 이따금 당황스러운 몇몇 경우가 발생하곤 하는데, 예를들어, 큰 파일을 지웠을 경우, 스냅샷응 사용하지 않았는데도, 1-2분이 지나기 전까지 삭제한 용량이 사용가능한 디스크 용량으로 적용되지 않는 경우가 발생한다는 것이다. Btrfs 는 다른 파일시스템들보다 백그라운드에서 수행되는 작업이 더 많다는 차이가 있다고 보면 된다.
Other Btrfs tools
Btrfs-progs 는 mkfs.btrfs 이 외에도 btrfsck 등의 몇가지 프로그램을 포함한다. Btrfsck 는 눈치챗듯이, 파일시스템에 대한 문제확인 및 복구를 제공하는 툴인데, 다만, man page 에서 당당하게도, 실제 상황(현업) 에서 충분한 테스트가 되지 않았으니 사용해서 문제가 생길수도 있으니, 안된다고 뭐라카지 말라고한다.. 멋진걸? ㅋ 무튼 --repair 모드를 사용하는 것 보다는 restore 기능을 이용하는게 낫다고 한다.
사실, 이 btrfsck 유틸리티는, 실전경험의 부족을 이유로, 많은 시스템 관리자들에게 외면되는 큰 이유중 하나이다. 그러나, 사실, 진짜 포괄적인 파일시스템에 대한 리페어 툴을 제공한다는 것은 매우 시간이 오래걸리며, 쉽지 않은 슬픈 현실로 인해, 결국, 다른 툴을 사용해야 할필요가 있었고, 매우 간단하게 사용되는 btrfs 라는 커맨드가 개발되었다. ( command 와 Filesystem name 이 헛갈리지 않기 위해 커맨드는 Italic 으로 쓴다. )
이 툴은 Btrfs 계의 Swiss army knife 이다. ( 이전에 기사에서 Swiss army knife 로 표현 한 글이 있다. )
이 툴은 Btrfs filesystem 상의 다양하고 광범위한 동작들을 수행하는데 사용된다. 따라서, btrfs 는 많은 수의 커맨드를 수행할 수 있으며, 본 연재기사의 후반부에서 검증할 예정이라고 한다. btrfs 커맨드의 몇가지 메리트를 가져오는 커맨드이다 :
# btrfs filesystem df filesystem - 일반 df 커맨드보다는 훨씬 상세한 filesystem 사용량을 확인 한다.
# btrfs filesystem show [filesystem] - 사용가능한 btrfs filesystem 의 상세정보를 나타낸다.
# btrfs filesystem defragment [file...] - 온라인 defragmentation 을 수행하며, 지목된 파일에 대해서만 수행하는 것도 가능하다.
# btrfs restore device - 문제가 생긴 파일시스템을 포함하고 있는 디바이스로부터 데이타를 추출하며, btrfsck 가 실패하더라도, 데이타 복구를 가능하게 해준다. 상세 내용은 위키페이지 를 확인.
# btrfs scrub filesystem - 메타데이타와 체크섬에 대한 에러를 찾아 바로잡는 일을 수행한다,
# btrfs send subvol # btrfs receive mount - 파일시스템의 리모트 복제에 사용되거나 증분백업의 수행에 사용될 수 있다.
기본적인 설명은 이정도면 충분하며, 여타 유닉스 스타일의 파일시스템처럼 다뤄지면서,
단순히 compression 과 data checksumming 기능만 추가된 것으로 보여진다.
그러나, 이것은 리눅스 세계에서 Btrfs 에서만 정말 독보적으로 구현된 기술임에 틀림없다.
다음 기사는 내장된 Multiple-device 와 Raid 기능에 대해서 알아 볼 것이라고 Corbet 의 두번째 Btrfs 에 대한 기사는 마무리 된다.
사실 Get start 문서는 btrfs wiki페이지를 봐도 되는 부분이지만, 어떤 부분이 개발에 난항을 격는 부분인지, 어떤 부분이 사용자 및 배포판들에서 우려하는 부분인지를 파악하고, 그걸 무시할만큼 매료될 좋은 기능들을 역홍보 하는것에 역점을 둔 기사가 아닐까 싶다.
위키페이지를 보면 알겠지만, 정말정말정말로 Btrfs 를 위해 특별한 도구들은, 전혀 필요가 없음을 알 수 있을 것이고, 이런 간결한 구성으로 훌륭한 기능들을 제공한다는 점은, 두말 할 나위 없이, 차세대 파일시스템으로 손꼽히는데, 손색이 없을 만 한 것으로 판단된다... (개인적으로다가....)
KM 만들어야 할 시점에 계속 딴짓거리중이긴 한데... 만들다보면 Btrfs 에 대한 마스터노트가 하나 나오지 않을까 싶어서 열심히 확인중...
왜냐하면, Oracle Linux 에서 LXC (Linux Containers) 를 사용하는 데 있어서, Btrfs 가 매우 중요한 역할을 할 것이기 때문이고, LXC 는, Redhat 에서 아직 구체적인 계획이 없기 때문에, Oracle Linux 에서 치고들어가고자 하는 부분이랄까?
우린 Database 를 위해서는 OCFS 나 ASM 도 여전히 라인업을 유지하고 있다는점.. (약간 얄밉긴 하지만 -_-)
Corbet 의 Btrfs 에 대한 마지막 연재기사가 종료되면... 양쪽 사이드에 함께 발담그고 있는 나의 개인적 리눅스의 벤더들의 미래가 살짝 드러나지 않을까 싶다.. (일단 스토리지분야....Openshift 도 언급할 기회가 생길거라고 구상중..)
맥주가 떨어져서 이제 자야겠어..셜록보면서... 셜록 뉴 시즌... 억지가 강하지만, 억지부터가 딱 내스타일 ㅋ 바보는 바보를 알아보는거지 ㅠㅠ