차세대 Linux 파일 시스템인 NiLFS(2)와 exofs 로그와 오브젝트를 사용하는 고급 Linux 파일 시스템

로그와 오브젝트를 사용하는 고급 Linux 파일 시스템

Linux는 파일 시스템 분야에서 혁신을 거듭하고 있습니다. 모든 운영 시스템에서 사용하는 다양한 파일 시스템을 대부분 지원합니다. 또한, 최신 파일 시스템 기술을 제공합니다. Linux에서 새로 지원하는 두 가지 파일 시스템은 NiLFS(2) Log-structured 파일 시스템과 exofs 오브젝트 기반 스토리지 시스템입니다. 이 기사에서는 Linux에 새로 추가된 이 두 가지 파일 시스템의 목적과 장점을 살펴볼 수 있습니다.  

새로운 Linux 파일 시스템이 발표된다는 소식이 들려오면 왠지 두렵기도 하고 흥분되기도 한다. 파일 시스템 분야가 흥미롭게 진보하고 있는 새로운 영역이어서 그런지 이러한 소식을 들으면 호기심이 생긴다. 또한, 초기 단계에서는 파일 시스템이 실험적인 경향이 있고 일반적으로 사용하기에는 다소 문제가 있을 수 있기 때문에 두려운 마음이 들기도 한다. 그러나 때로는 이러한 발표를 통해 Linux의 미래에 대한 투자에 관한 소식을 듣게 되며 실제로 2.6.30-rc1에 대한 최근 발표에서는 매우 흥미로운 미래가 제시되었다. 지난 수분기 동안 Linux와 관련하여 세 가지 주요 파일 시스템이 발표되었다. 2008년 후반에는 Btrfs(B-Tree File System)가 도입되었으며 최근에는 다른 두 개의 고유한 파일 시스템인 NiLFS(2)와 exofs가 도입되었다.

파일 시스템 배경

먼저, 이러한 새로운 파일 시스템의 접근 방식을 간단히 소개한 후, NiLFS(2)와 exofs의 특징을 살펴보기로 한다.

Log-structured 파일 시스템

Log-structured 파일 시스템에는 최신 컴퓨팅 시스템과 관련된 다양한 이야기가 있다. 첫 번째 Log-structured 파일 시스템은 John Ousterhout와 Fred Douglis가 1988년에 제안했으며 그 후 1992년에 Sprite 운영 체제에서 구현되었다. 이름에서 알 수 있듯이 Log-structured 파일 시스템에서는 파일 시스템을 새 데이터와 파일 시스템 메타데이터를 로그의 헤드에 쓴 순환 로그로 여기며 여유 공간은 끝에서부터 사용된다(그림 1 참조). 이렇게 하면 로그에 데이터가 두 번 이상 표시될 수도 있지만 로그는 시간에 따라 정렬되기 때문에 가장 최근의 데이터가 활성 데이터로 표시된다. 로그에 다수의 데이터 사본이 있으면 몇 가지 중요한 장점이 생기며 이러한 사항은 아래에서 자세히 설명한다.

그림 1. Log-structured 파일 시스템의 간단한 구조

Log-structured 방식은 장점이라기보다는 아키텍처적인 개념이라고 할 수 있으며 이러한 방식은 몇 가지 독특한 장점을 제공한다. 한 가지 중요한 장점으로는 시스템이 파손되었을 때 복구하는 기능을 들 수 있으며 Log-structured 방식을 사용하면 이 기능이 더 단순해진다.

또 다른 장점은 기본 스토리지 시스템을 사용하여 성능을 개선할 수 있다는 점이다. 순차적으로 디스크에 쓰는 동작은 무작위로 I/O에 쓰는 동작보다 훨씬 더 빠르다. 쓰기 동작은 모두 순차적으로 행해지기 때문에 찾기에 대한 부담이 제거되고 결과적으로 디스크 I/O 속도가 빨라져 파일 시스템의 속도가 개선된다.

오브젝트 기반의 스토리지 시스템

기존의 스토리지 시스템은 디스크 드라이브와 드라이브에 내장된 인터페이스를 기반으로 지속적으로 데이터를 저장한다. 이러한 인터페이스는 블록 스토리지 시맨틱에 의존하며 여기에서는 작은 고정 크기의 데이터 블록이 맵핑 정보(파일 시스템 메타데이터)와 함께 전달된다. 오브젝트 스토리지 시스템은 매우 다른 접근 방식을 취하며 고정 크기 블록을 관리하는 대신 가변 크기 오브젝트와 시스템 레벨의 오브젝트 정보를 제공하는 관련 메타데이터를 관리한다.

오브젝트 스토리지 시스템은 멀티 테넌시(Multi-tenancy)와 보안이 통합된 확장 가능한 스토리지를 구현할 수 있는 유일한 방식이다. OSD 표준(사이드바 참조)은 다양한 방식으로 이용할 수 있다. OSD 드라이브 및 개시자와 같은 OSD 호환 구성요소나 상위 레벨 구성요소(기존의 드라이브상에서 OSD 작동을 이용하는 대상 시스템)를 사용할 수 있다. 그러나 블록 기반 스토리지와 오브젝트 기반 스토리지 시스템의 기본적인 차이는 블록 기반 스토리지 시스템에서는 사용자가 블록과 통신하는 프로토콜을 사용하여 데이터와 메타데이터가 포함된 블록의 컬렉션으로 오브젝트를 작성한다는 점이다. 반면에 오브젝트 기반 스토리지 시스템에서는 사용자가 오브젝트 및 관련 메타데이터와 통신한다(그림 2 참조). 그러면 오브젝트 스토리지 장치는 오브젝트로 구성된 일반 네임스페이스가 되며 필요한 경우에는 여기에서 스토리지 시스템 스택 상부에 계층 구조가 세워진다.

그림 2. 블록 기반 스토리지 시스템 대 오브젝트 기반 스토리지 시스템

이 기사에서는 오브젝트 기반 스토리지 시스템상에서 구현된 하나의 파일 시스템을 살펴본다.

새로 구현된 Log-structured 파일 시스템: NiLFS(2)

NiLFS(2)는 일본의 NTT(Nippon Telegraph and Telephone)에서 두 번째로 개발한 Log-structured 파일 시스템이다. 이 파일 시스템은 개발이 활발히 진행 중이며 최근에는 NetBSD 커널을 비롯한 주요 Linux 커널에 도입되었다. NILFS 첫 번째 버전(버전 1)은 2005년에 개발되었지만 가비지 컬렉션 기능이 부족했다. 버전 2는 2007년 중반에 처음 릴리스되었으며 이 버전에는 가비지 콜렉터와 다수의 스냅샷을 작성하고 유지하는 기능이 포함되었다. 2009년에는 NiLFS(2) 파일 시스템이 주요 Linux 커널에 포함되었으며 Linux의 로더 가능형 모듈을 설치하면 이 파일 시스템을 간단히 사용할 수 있다.

NiLFS(2)에서 주목할만한 부분은 연속해서 스냅샷을 할 수 있는 기술이다. NILFS는 로그 형태로 구조화되어 있기 때문에 새 데이터는 로그의 헤드에 쓰여지며 기존 데이터는 가비지 컬렉션되지 않는 한 계속 존재한다. 기존 데이터가 계속 존재하기 때문에 원하는 시점으로 돌아가서 해당 파일 시스템의 에포크(epoch)를 조사할 수 있다. 이러한 에포크는 NiLFS(2)에서 체크포인트라고 불리며 파일 시스템의 핵심 부분이 된다. NiLFS(2)에서는 파일 시스템에 변화가 생길 때마다 이러한 체크포인트가 작성되지만 사용자가 강제로 체크포인트를 작성할 수도 있다.

자세히 살펴보겠지만, 체크포인트(복구 포인트)는 스냅샷으로 변경될 수 있을 뿐만 아니라 볼 수도 있다. 스냅샷은 다른 파일 시스템과 마찬가지로 Linux 파일 시스템 공간에 마운트될 수 있지만 현재는 읽기만 가능하다. 스냅샷을 마운트하여 이전에 삭제한 파일을 복구하거나 파일의 이전 버전을 확인할 수 있다는 점에서 스냅샷은 매우 유용하다.

연속적인 스냅샷 외에도 NiLFS(2)에서 다양한 혜택을 얻을 수 있다. 가용성 면에서 가장 중요한 점은 신속하게 다시 시작할 수 있다는 점이다. 현재의 체크포인트가 올바르지 않으면 올바른 마지막 체크포인트로 돌아가서 파일 시스템을 올바르게 하기만 하면 된다. 이러한5 class=sub_title>NiLFS(2)의 과제

연속적인 스냅샷이 유용한 기능이긴 하지만 이에 따르는 대가가 문제가 된다. 언급한 바와 같이 긍정적인 면은 스냅샷이 로그 형태로 구조화되어 있어서 본질적으로 쓰기가 순차적으로 행해지고 이로 인해 실제 디스크의 찾기 작동이 최소화되고 따라서 속도가 매우 빠르다는 점이다. 부정적인 면은 스냅샷이 로그 형태로 구조화되어 있기 때문에 가비지 컬렉션을 수행하여 이전 데이터와 메타데이터를 정리해야 한다는 점이다. 일반적으로 이 파일 시스템은 매우 빠르게 작동하지만 가비지 컬렉션이 필요한 경우에는 성능이 저하된다.

NiLFS(2) 탐구

작동 중인 NiLFS(2)를 살펴보자. 이 데모를 통해 루프 장치(파일 시스템을 테스트하는 간단한 방법)에서 NiLFS(2) 파일 시스템을 작성하는 방법과 NiLFS(2)의 일부 기능을 확인할 수 있다. 먼저, 다음 명령을 수행하여 NiLFS(2) 커널 모듈을 설치한다.

$ sudo modprobe nilfs2


$

그런 다음, 해당 파일 시스템(루프 장치를 통해 자체 파일 시스템으로 마운트하는 호스트 운영 체제의 영역)이 포함된 파일을 작성 한 후, mkfs를 사용하여 이 파일 안에서 NiLFS(2) 파일 시스템을 구축한다(Listing 1 참조).

Listing 1. NiLFS(2) 파일 시스템 준비

$ dd if=/dev/zero of=/tmp/disk.img bs=384M count=1


1+0 records in


1+0 records out


402653184 bytes (403 MB) copied, 60.7253 s, 6.6 MB/s


$ mkfs.nilfs2 /tmp/disk.img


mkfs.nilfs2 ver 2.0


Start writing file system initial data to the device


       Blocksize:4096  Device:/tmp/disk.img  Device Size:402653184


File system initialization succeeded !!


$

그러면, NiLFS(2) 파일 시스템 형식으로 초기화된 디스크 이미지가 생성된다. 이제, 루프 장치를 사용하여 마운트 지점에 파일 시스템을 마운트한다(Listing 2 참조). 해당 파일 시스템이 마운트되면 nilfs_cleanerd라고 하는 사용자 공간 프로그램이 시작되어 가비지 컬렉션 서비스를 제공하게 된다.

Listing 2. 루프 장치를 사용하여 NiLFS(2) 마운트하기

$ sudo losetup /dev/loop0 /tmp/disk.img


$ sudo mkdir /mnt/nilfs


$ sudo mount -t nilfs2 /dev/loop0 /mnt/nilfs/


mount.nilfs2: WARNING! - The NILFS on-disk format may change at any time.


mount.nilfs2: WARNING! - Do not place critical data on a NILFS filesystem.


$ ls /mnt/nilfs


$

이제, 해당 파일 시스템에 몇 개의 파일을 추가한 후, lscp 명령을 사용하여 사용 가능한 현재 체크포인트를 표시한다(Listing 3 참조). mkcp 명령을 사용하여 스냅샷을 정의한 후, 다시 체크포인트를 확인한다. 다시 lscp를 실행하면 CNO나 체크포인트 번호가 있는 모든 체크포인트와 스냅샷이 새로 작성된 스냅샷과 함께 표시된다.

Listing 3. 체크포인트 표시 및 스냅샷 작성

$ cd /mnt/nilfs


$ sudo touch file1.txt file2.txt


$ lscp


                 CNO        DATE     TIME  MODE  FLG   NBLKINC       ICNT


                   1  2009-08-21 22:29:31   cp    -         11          3


                   2  2009-08-21 22:36:44   cp    -         11          5


$ sudo mkcp -s


$ lscp


                 CNO        DATE     TIME  MODE  FLG   NBLKINC       ICNT


                   1  2009-08-21 22:29:31   cp    -         11          3


                   2  2009-08-21 22:36:44   ss    -         11          5


                   3  2009-08-21 22:39:47   cp    i          7          5


$

스냅샷을 작성했으므로 다시 touch 명령을 사용하여 현재 파일 시스템에 파일을 몇 개 더 추가한다(Listing 4 참조).

Listing 4. NiLFS(2) 파일 시스템에 파일을 몇 개 더 추가하기

$ sudo touch file3.txt file4.txt


$ ls


file1.txt  file2.txt  file3.txt  file4.txt


$

이제 스냅샷을 읽기 전용 파일 시스템으로서 마운트한다. 앞서와 비슷한 방식으로 마운트하면 되지만, 이 경우에는 마운트할 스냅샷을 지정해야 한다. 이번에는 cp 옵션을 사용하여 마운트한다. 앞서 실행한 lscp 명령의 결과에서 작성한 스냅샷이 CNO=2에 해당된다는 것을 알 수 있다. mount 명령에서 이 CNO를 사용하여 스냅샷을 읽기 전용 파일 시스템으로 마운트한다. 마운트가 되면 먼저, 마운트된 읽기/쓰기 파일 시스템에서 ls 명령을 실행하여 모든 파일을 표시한다. 읽기 전용 스냅샷에서는 스냅샷을 작성했을 때 있었던 두 개의 파일만 표시된다(Listing 5 참조).

Listing 5. 읽기 전용 NiLFS(2) 스냅샷 마운트하기

$ sudo mkdir /mnt/nilfs-ss2


$ sudo mount.nilfs2 -r /dev/loop0 /mnt/nilfs-ss2/ -o cp=2


$ ls /mnt/nilfs


file1.txt  file2.txt  file3.txt  file4.txt


$ ls /mnt/nilfs-ss2/


file1.txt  file2.txt


$

이러한 스냅샷은 일단 체크포인트에서 변환되면 계속 유지된다. 공간이 필요하면 파일 시스템에서 체크포인트를 다시 사용할 수 있지만 스냅샷은 계속 유지된다.

이 데모에서는 NiLFS(2)용 명령행 유틸리티인 lscp(체크포인트와 스냅샷을 표시)와 mkcp(체크포인트 또는 스냅샷 작성)를 사용했다. 체크포인트를 스냅샷으로 변환하거나 그 반대의 작업을 할 수 있는 chcp 유틸리티와 체크포인트나 스냅샷을 무효화하는 rmcp 명령도 있다.

이 파일 시스템의 시간적 특성을 감안하여 NTT에서는 미래를 위한 몇 가지 매우 혁신적인 도구를 생각해냈으며 이러한 도구는 tls(시간적 ls), tdiff(시간적 diff) 및 tgrep(시간적 grep)이다. 논리적으로 보았을 때 다음 단계에서는 시간을 기반으로 하는 기능을 도입하게 될 것으로 보인다.

exofs(Extended Object File System)

exofs(Extended Object File System)는 기존의 Linux 파일 시스템으로 오브젝트 스토리지 시스템상에서 빌드된다. exofs는 IBM의 Avishay Traeger가 처음 개발했으며 그 당시에는 OSD 파일 시스템 또는 osdfs라고 했다. Panasas(오브젝트 스토리지 시스템을 확립한 회사)는 이 프로젝트를 인수하여 이 파일 시스템의 이름을 exofs로 바꾸었다. (이 이름은 ext2 파일 시스템에서 따온 것이다.)

오브젝트 스토리지 시스템을 기반으로 하는 파일 시스템

개념적으로 오브젝트 스토리지 시스템은 오브젝트와 관련 메타데이터로 구성된 일반 네임스페이스로 볼 수 있다. 오브젝트 스토리지 시스템은 의미상의 교착점을 제공하기 위해 일부 블록을 점유하는 메타데이터를 사용한다는 점에서 블록을 기반으로 하는 기존의 스토리지 시스템과 비교된다. 상위 레벨에서는 exofs가 그림 3에 표시된 것과 같이 구성된다. OSD 개시자를 통해 OSD T-10 표준 SCSI 명령을 구현한다.

그림 3. 상위 레벨에서 본 exofs/OSD 구조

exofs의 기본 개념은 OSD 백스토어를 기반으로 기존 파일 시스템을 제공하는 데 있다. 존재하는 파일 시스템이 기존의 파일 시스템이기 때문에 이렇게 하면 오브젝트 레벨 스토리지로 더 쉽게 마이그레이션할 수 있다.

파일 시스템 맵핑

OSD의 각 오브젝트는 일반 네임스페이스에서 64비트 ID로 표현된다. 표준 POSIX 인터페이스를 오브젝트 시스템으로 오버레이하려면 맵핑을 해야한다. exofs에서는 확장 가능한 간단한 맵핑을 제공한다.

파일 시스템에 있는 파일은 inode로 고유하게 표현된다. exofs는 inode를 오브젝트 시스템의 OID(Object Identifier)에 맵핑한다. 이렇게 하고 나면 파일 시스템의 모든 요소가 오브젝트로 표현된다. 파일은 오브젝트로 직접 맵핑되며 디렉토리는 디렉토리 내에 포함된 파일을 파일 이름과 inode-OID 쌍을 통해 참조하는 파일이 된다. 그림 4에는 이러한 내용이 간단하게 표시되어 있다. 기타 오브젝트는 inode를 할당하는 데 필요한 inode 비트맵과 같은 것을 지원하기 위해 존재한다.

그림 4. 상위 레벨에서 본 OSD 표현

오브젝트 공간에서 오브젝트를 표현하는 데 사용되는 OID의 크기는 64비트이며 이 OID를 통해 대용량 오브젝트 공간을 지원한다.

오브젝트 스토리지를 사용하는 이유

오브젝트 스토리지는 중요한 개념이며 확장 가능한 시스템을 개선해 나가는 데 도움이 된다. 오브젝트 스토리지로 인해 파일 시스템 일부가 호스트에서 제거되어 스토리지 서브시스템으로 포함되었다. 여기에는 상충되는 관계가 있지만 파일 시스템의 일부를 다수의 엔드포인트로 분산함으로써 워크로드를 분산할 수 있고 오브젝트 기반의 메소드를 더 단순화하여 스토리지 시스템의 규모를 더 크게 확장할 수 있다. 블록을 파일에 맵핑해야 하는 호스트 운영 체제 대신 스토리지 장치 자체에서 이러한 맵핑을 제공하게 되면 호스트를 파일 레벨에서 운영할 수 있다.

또한, 오브젝트 스토리지 시스템에서는 사용 가능한 메타데이터를 쿼리하는 기능을 제공한다. 이 기능을 이용하면 검색 기능을 엔드포인트 오브젝트 시스템으로 분산할 수 있기 때문에 추가로 몇 가지 장점을 얻을 수 있다.

최근에는 오브젝트 스토리지가 클라우드 스토리지 영역에 다시 등장했다. 스토리지를 서비스 형태로 판매하는 클라우드 스토리지 제공업체는 스토리지를 기본의 블록 API 대신 오브젝트로 표현한다. 이 제공업체들은 API를 구현하여 오브젝트를 전송하고 관리하거나 메타데이터를 관리한다.

전망

NiLFS(2)와 exofs는 Linux 파일 시스템 목록에 추가될 만한 중요하고 유용한 기능이지만 보완해야 할 부분이 많이 있다. 최근에 Oracle에서 도입한 Btrfs를 이미 살펴보았듯이 이 파일 시스템은 Linux에서 Sun Microsystems의 ZFS(Zettabyte File System)를 대체할 수 있는 수단을 제공한다. 최근에 개발된 또 다른 파일 시스템은 Ceph이며 이 파일 시스템은 SPOF(Single Point of Failure)가 없는 신뢰할 수 있는 POSIX 기반의 분산 파일 시스템을 제공한다. 이 기사에서는 새로운 Log-structure 파일 시스템을 살펴보고 오브젝트 스토어 기반의 파일 시스템을 소개했다. Linux는 엔터프라이즈 클래스 운영 체제는 물론이고 연구용 플랫폼으로 선택된다는 사실이 계속해서 입증되고 있다.  

<<필자소개>>

M. Tim Jones는 임베디드 펌웨어 아키텍트이자 Artificial Intelligence: A Systems Approach, GNU/Linux Application Programming(현재 2판), AI Application Programming(현재 2판) 및 BSD Sockets Programming from a Multilanguage Perspective의 저자이다. 정지 위성을 위한 커널 개발에서 시작해 임베디드 시스템 아키텍처와 네트워크 프로토콜 개발에 이르기까지 다양한 분야에 대한 공학 지식을 가지고 있다. 콜로라도주 롱몬트 소재의 Emulex Corp.에서 컨설턴트 엔지니어로 활약하고 있다.

출처 : 한국 IBM