1

PVFS에서 캐쉬 관리자의 설계 및 구현

김호중(Ho-Joong Kim) 황인철(In-Chul Hwang)

한국과학기술원 전자전산학과 전산학전공 컴퓨터구조연구실

2002년 07월 31일

요약

본 보고서에서는 PVFS에서의 프로토타입 캐쉬 관리자에 대하여 설명한다. PVFS 캐쉬 관리

자는 기존 리눅스 시스템의 버퍼캐쉬를 사용하지 않고 자신의 지역 영역 메모리를 사용하여

캐슁 역할을 수행한다. 따라서 기존 Linux 캐쉬 시스템과 연계가 필요하여 지역 영역 캐쉬

관리 기법이 필요하게 된다. PVFS 캐쉬 관리자는 Gigabit Ethernet으로 연결된 클러스터에

서 구현되었다.

2

목차

1. 서론

2. 설치과정

3. PVFS 구조

3.1 전체 구조

3.2 PVFS client 구조

4. PVFS 캐쉬 관리자 설계와 구현

4.1 캐쉬 구조

4.2 해쉬 테이블

4.2 캐쉬 대체 알고리즘

4.3 캐쉬 할당 알고리즘

4.4 캐쉬 관리

5. 성능

6. 결과

3

1. 서론

본 보고서에서는 PVFS에서 사용될 캐쉬 관리자에 대하여 설명한다.

PVFS의 캐쉬 관리자는 여러 PC를 Gigabit Ethernet으로 연결한 클러스터 시스템에서 설

계되고 구현되었다. 각 PC들은 1.8GHz Pentium IV 프로세스를 탑재하고 있으며, 운영체제

로 Linux 2.4.18을 사용한다.

PVFS 캐쉬 관리자는 기존 운영체제의 캐쉬 시스템을 고쳐 사용하지 않고 PVFS의 소스

코드에 추가하여 지역 메모리를 캐쉬 영역으로 할당 받아 사용한다. 따라서 기존 시스템의

캐쉬 시스템과의 연결이 필요하고, 이를 위하여 메모리 관리 알고리즘을 사용한다.

본 보고서의 구성은 다음과 같다. 2장에서는 PVFS의 설치 과정에 관하여 설명한다. 3장에

서는 기존에 만들어져 있던 PVFS의 구조를 설명한다. 4장에서는 기존 PVFS에 추가한 캐

쉬 관리자의 여러 기능들을 설명한다. 5장에서는 기존 파일 시스템, PVFS, PVFS와 캐쉬시

스템을 사용한 성능을 비교, 분석한다. 마지막으로 6장에서는 결론을 맺는다.

2. 설치과정

이 장은 PVFS의 설치 및 실행방법에 대하여 살펴본다.

현재 개발된 시스템은 Linux kernel version 2.4.14이상의 시스템에서 적용될 수 있다.

PVFS 소스코드는 ftp://ftp.parl.clemson.edu/pub/pvfs/ 에서 다운로드 받을 수 있다. 소스

코드는 크게 pvfs-1.5.x.tgz와 pvfs-kernel-1.5.x.tgz가 있다. Pvfs-1.5.x.tgz는 PVFS에서

I/O 노드와 meta-data 매니저, 그리고 pvfs 라이브러리로 되어 있다. Pvfs-kernel-

1.5.x.tgz는 PVFS kernel module과 daemon process에 대한 소스이다.

4

2.1 PVFS install

pvfs-1.5.x.tgz의 압축을 푼 후, 디렉토리에 들어가 다음과 같은 command를 수행한다.

$ ./configure

$ make

$ make install

2.2 Kernel Module Install

pvfs-kenel-1.5.x.tgz의 압축을 푼 후, 디렉토리에 들어가 다음과 같은 command를 수행

한다.

$ ./configure --with-kernel-headers=/usr/src/linux/include --with-libpvfs-

dir=/usr/local/lib/

$ make

$ make install

$ cp pvfs.o /usr/local/pvfs/

2.3 System Configuration

시스템은 can9와 can10은 client로, can11과 can12는 I/O 서버로 can 13은 meta-data

매니저로 한다.

2.4 System Install

2.4.1 Meta-data Manager Install

다음과 같은 command를 수행한다.

5

$ mkdir /pvfs-meta

$ /usr/local/bin/mkmgrconf

/var/pvfs

root

root

777

localhost

2.4.2 I/O server Install

다음과 같은 command를 수행한다.

$ mkdir /pvfs-data

$ chmod 700 /pvfs-data

$ chown nobody.nobody /pvfs-data

$ touch /etc/iod.conf

$ vi /etc/iod.conf

# iod.conf file for example cluster

datadir /pvfs-data

user nobody

group nobody

2.4.3 Client Install

다음과 같은 command를 실행한다.

6

$ mkdir /pvfs

$ mknod /dev/pvfsd c 60 0 // character & major 60 minor 0

$ cat > /etc/pvfstab

can9:/pvfs-meta /pfvs pvfs port=3000 0 0

2.5 Startup

2.5.1 Meta-data Manager

다음 command를 실행한다.

$ /usr/local/sbin/mgr

2.5.2 I/O 서버

다음 command를 실행한다.

$ /usr/local/sbin/iod

2.5.3 client

다음 command를 실행한다.

$ insmod /usr/local/pvfs/pvfs.o

$ /usr/local/sbin/pvfsd

$ /sbin/mount.pvfs can13:/pvfs-meta /pvfs

7

2.5.4 PVFS 실행되는지 확인하는 과정

다음 명령어를 실행하여 결과가 다음과 같이 나오는지 살펴본다.

$ df -h /pvfs

Filesystem Size Used Avail Use% Mounted on

can13:/var/pvfs-meta 19G 1.2G 18G 6% /pvfs

2.6 파일 사용

PVFS 의 파일을 사용하기 위해서는 /PVFS 디렉토리 밑에 파일을 두고 사용하면 된다.

3. PVFS 구조

본 장에서는 PVFS의 전체 구조와 그 중 본 연구에서 고쳐 만든 client부분에 대하여 살펴

본다.

3.1 PVFS의 전체 구조

PVFS의 구조는 다음 그림과 같다.

8

그림 1 PVFS의 구조

그림 1에서와 같이 PVFS는 크게 compute node와 management node 그리고 I/O node로

구성이 된다. Compute node는 PVFS의 서비스를 이용하는, 즉 PVFS 파일을 사용하는 사

용자이다. Management node는 meta-data manager라고 부르고, 여기서는 파일에 대한

metadata 정보를 지니고 있게 된다. 마지막으로 I/O node는 사용자 데이터를 특별한 방법

에 의해 가지고 있는 노드이다.

PVFS에서는 사용자 데이터를 사용자가 임의의 노드에 지정하여 일정 크기로 나누어 일정

I/O 서버에 저장할 수 있는 기능을 제공한다. 그림 2는 이를 설명해 주는 그림이다.

그림 2 stripping

그림에서와 같이 사용자는 임의의 파일은 일정한 크기(그림에서는 64KB)단위로 나누어 서

버에 저장하게 된다.

다음 그림 3은 사용자가 파일에 접근할 때 데이터의 흐름을 나타내는 그림이다.

9

그림 3 데이터 접근

그림에서와 같이 meta-data를 access할 때는 manager node에 접속하여 가져오게되고,

이후 데이터에 대한 접근(read/write operation)때에는 manager node에 접속하지 않고 I/O

서버에 접속하여 바로 데이터에 접근을 할 수 있다.

3.2 PVFS client 구조

PVFS의 client구조는 다음 그림 4와 같다.

그림 4 PVFS client 구조

그림에서와 같이 application은 /PVFS 하위 파일을 access하게 되고, 이를 VFS에서 이미

등록된 PVFS primitive를 작동 시켜 /dev/pvfsd의 가상 모듈의 queue에 그 access를 저장

10

하여 user level의 pvfsd가 그 내용을 가지고 와서 처리해 주는 역할을 수행하게된다.

4. PVFS 캐쉬 관리자 설계와 구현

본 장에서는 PVFS 캐쉬 관리자의 설계와 구현에 관하여 설명한다.

그림 5에서는 기존 PVFS client 구조와 통신을 나타낸다.

그림 5 기존 PVFS client 구조

위 그림 5와 같은 구조를 새로이 캐쉬 관리자를 추가하여 설계한 모습은 다음 그림 6와

같다.

11

그림 6 새로운 PVFS client 구조

그림에서와 같이 새로운 client의 구조 에서는 VFS layer에서 pvfs device queue에 요청

을 삽입하기 전, cache manager를 통하여 cache에 그 내용이 존재하는지 살펴본 후 queue

에 삽입하는 동작을 수행한다.

4.1 캐쉬 구조

cache는 단순 데이터를 지니고 있는 local data의 집합이다. 하나의 cache entry는 다음과

같은 구조체로 정의된다.

struct pvfs_cache{

char cache_data[DEFAULT_BLKSIZE];

}pcache;

DEFAULT_BLKSIZE는 하나의 stripping unit단위인 64KB이다.

12

이러한 cache data의 집합인 하나의 entry가 구성이되고 이에 대한 descriptor는 다음과

같이 정의가 된다.

struct pvfs_cache_desc{

struct inode *inode;

long inum;

int stripe_num;

struct pvfs_cache_desc* hash_next;

struct pvfs_cache* c_data;

int end;

}pcachedesc;

inode structure와, inode number, stripping number, hash table에서 entry가 하나이상일

경우 묶어줄 link인 hash_next, 그리고 앞에서 말한 cache_data에 대한 Pointer, 마지막으

로 현재 이 entry에서 어디까지가 실제 data가 존재하는지를 가르키는 offset(end)로 구성

이 된다.

4.2 해쉬 테이블

Hash table은 inode number와 stripe number로 indexing이 되며, 이를 가지고서 cache

entry를 빠르게 찾아서 access할 수 있게 된다. Hash table을 lookup하고, hash에 add하고

delete하는 함수가 정의되어 있다.

4.1과 4.2에서 살펴본 내용을 토대로 cache structure의 전체적인 구조를 그려보면 다음

7과 같다.

13

그림 7 캐쉬의 구조

4.2 캐쉬 대체 알고리즘

본 구현에서는 Linux에서 사용하는 것과 유사한 형태의 second-chance 캐쉬 대체 알고리

즘을 사용한다.

캐쉬 서술자(cache descriptor) 내에는 accessed 필드가 정의되어 있으며,

pvfs_hash_add() 또는 pvfs_hash_lookup()을 통해 해당 캐쉬 블록에 접근할 때 accessed

필드를 1로 설정한다. 한편 replacement_index라는 전역변수는 해쉬 테이블 내의 특정 위

치를 가리킨다. 캐쉬 관리자로부터 캐쉬 대체 명령이 수행되면 replacement_index로부터

시작하여 해쉬 테이블 전체를 순차적으로 검색하면서 accessed 필드가 1으로 설정된 서술

자들은 이 값을 0으로 변경하며 이미 accessed 필드가 0으로 설정된 서술자들은

pvfs_hash_free()를 수행하여 해당 캐쉬 블록을 해쉬 테이블에서 삭제하고 free list로 옮긴

다.

지정된 개수 만큼의 캐쉬 블록을 free list를 옮길 때까지 이러한 과정을 반복한 후

replacement_index를 현재의 위치로 갱신하고 캐쉬 대체 알고리즘을 끝낸다. 이러한 일련

의 알고리즘은 replacement_algorithm() 내에 구현되어 있다.

14

Replacement_algorithm()에 의해 대체된 메모리 블록들은 실제로는 해쉬 테이블로부터

free list로 옮겨졌을 뿐 여전히 캐쉬 관리자 내에서 할당 받은 채로 남아 있다. Free list에

들어있는 메모리 블록을 해제하여 시스템에 반환하는 작업은 purge_free_list()에서 수행한

다.

4.3 캐쉬 할당 알고리즘

pvfs_cache_alloc()은 해쉬 테이블에 추가하기 위한 새로운 캐쉬 블록을 할당한다. 우선

free list를 검색하여 free list에 할당된 메모리 블록이 있는지 찾는다. Free list가 NULL인

경우 캐쉬 메모리 관리를 수행하여 사용 가능한 메모리 블록을 확보하고 이를 free list에

우선 할당한 뒤 다시 free list로부터 꺼낸다. 캐쉬 서술자를 생성한 후 해당 메모리 블록을

캐쉬 서술자에 등록한다.

만일 사용 가능한 메모리 블록을 확보하지 못했다면 시스템의 메모리 자원이 부족한 상황

이므로 사용 가능한 메모리 블록을 확보할 때까지 캐쉬 메모리 관리를 수행하여야 한다.

pvfs_cache_free()는 pvfs_cache_alloc()과 반대의 역할을 수행한다. 먼저

pvfs_hash_del()을 수행하여 캐쉬 서술자를 해쉬 테이블에서 제거한 후 free list 서술자를

생성하여 해당 메모리 블록을 등록하고 캐쉬 서술자를 해제한다.

4.4 캐쉬 관리

캐쉬 관리자는 해쉬 테이블에 새로운 캐쉬 엔트리를 추가할 때 mem_management()를 수

행하여 현재 사용 가능한 메모리의 양을 측정하고 시스템 메모리 자원이 충분한가, 또는 캐

쉬된 메모리 크기가 너무 크지 않은가 등을 검사함으로써 메모리를 효율적으로 관리한다.

캐쉬 관리자는 내부적으로 CACHE_SIZE_LOW, CACHE_SIZE_HIGH, FREE_MEM_LOW,

FREE_MEM_HIGH의 네 개의 미리 지정된 값을 가지고 있다. CACHE_SIZE_LOW와

CACHE_SIZE_HIGH는 해쉬 테이블과 free list를 포함하여 캐쉬 관리자가 관리하는 메모리

15

블록의 크기를 결정짓는다. FREE_MEM_LOW와 FREE_MEM_HIGH는 시스템에서 사용 가

능한 메모리 자원 상태를 판단하기 위하여 사용한다.

시스템의 메모리 자원 상태를 알아보기 위해서는 커널에서 제공하는 si_meminfo() API를

사용한다. Si_meminfo()는 내부적으로는 nr_free_pages()와 같은 커널 내부 함수들로 구현

되어 있으며 시스템 전체 메모리, free 메모리, 버퍼 캐쉬 등의 크기를 알려준다.

지나치게 많은 메모리 블록이 캐쉬 대체 알고리즘에 의하여 대체되는 경우 전체 캐쉬 메모

리의 크기가 CACHE_SIZE_LOW 미만으로 줄어들 수 있다. 이때 free list에는 어떠한 메모

리 블록도 들어있지 않으며 캐쉬 관리자에서 관리하는 모든 메모리 블록은 해쉬 테이블에

등록되어 실제 데이터를 캐쉬한 상태이다. 캐쉬 크기가 너무 작은 경우 성능 향상 효과가

줄어들므로 항상 일정 수준 이상으로 메모리 블록을 확보하여 캐쉬를 유지하는 것이 바람직

하다.

한편 캐쉬 관리자가 메모리 블록을 해제하여야 하는 경우는 크게 두 가지로 나눌 수 있다.

첫째, 시스템 메모리 자원이 부족한 경우이다. 만일 si_meminfo()를 수행하여 시스템 메모

리 자원을 측정한 결과 전체 사용 가능한 free 메모리의 양이 FREE_MEM_LOW보다 작다

면 사용 가능한 메모리의 양이 FREE_MEM_HIGH보다 커질 때까지 캐쉬 관리자가 확보한

메모리 블록들을 해제하여야 한다. 둘째, 캐쉬 관리자가 CACHE_SIZE_HIGH 이상으로 너무

많은 수의 캐쉬 블록을 가지는 경우이다.

이러한 두 가지 경우 mem_management()는 필요한 만큼의 메모리를 해제한다. 먼저

purge_free_list()를 수행하여 free list에 들어있는 블록들을 해제하며, 이것으로 충분하지

않은 경우 캐쉬 대체 알고리즘인 replacement_algorithm()을 수행하여 해쉬 테이블에 속한

캐쉬된 데이터들을 free list로 옮긴 다음 다시 purge_free_list()를 수행한다.

캐쉬 대체 및 캐쉬 할당을 포함하여 전체 캐쉬 시스템이 동작하는 그림 8과 같다.

16

그림 8 캐쉬 관리자 동작 흐름도

5. 성능

5.1 성능 평가 환경

본 연구에서는 표 1과 같은 환경에서 성능 평가를 수행하였다.

CPU

MEMORY

HDD

Pentium-4 1.8GHz

512MB

7200RPM

512KB cache

266MHz (64bit bus)

60GB

NIC Gigabit Ethernet

OS Linux 2.4.14

표 1 성능 평가 환경

17

5.2 Iozone

Iozone[1]은 파일 시스템을 포함하여 시스템 전체의 I/O 특성을 분석할 수 있는 벤치마크

툴이다. 일반적으로 파일 시스템 벤치마크들은 대부분 데이터 전송 지연 시간(latency), 데

이터 전송 대역폭(bandwidth), metadata 작업 수행 시간 등을 측정하는데 중점을 둔다. 본

캐쉬 구현의 성능을 평가하기 위해서는 이러한 마이크로벤치마크 결과 외에 전체 시스템 수

행과 관련되어 보다 복합적인 평가가 이루어져야 한다. Iozone은 I/O 명령들이 실제로 시스

템에서 어떻게 동작하는가를 반영한다. 예를 들어 작은 파일을 읽고 쓰는 경우 메모리 및

하드웨어 캐쉬의 영향으로 인한 성능 증가가 벤치마크에 반영된다.

Iozone에서 제공하는 벤치마크 방법에는 read, write, re-read, re-write, read backward,

read strided, random read, random write, asynchronous I/O 등이 있다. 본 연구에서는 연

구 성격에 맞는 read, write, re-read, random read 벤치마크를 수행하고 그 결과를 분석하

였다.

read

write

re-read

random read

파일을 record 크기 단위로 순차적으로 읽는다.

파일을 record 크기 단위로 쓴다.

파일을 record 크기 단위로 순차적으로 읽은 뒤 다시 처음부터 읽는다.

파일을 열고 임의의 위치로부터 record 크기 단위로 읽는다.

표 2 벤치마크 방법

벤치마크 대상으로는 Linux에서 일반적으로 사용하는 파일시스템인 ext2와 기존의 PVFS,

그리고 본 연구에서 개발한 PVFS+cache를 선정하였다. Ext2 파일 시스템은 Linux의 버퍼

캐쉬를 사용하며 PVFS는 캐쉬를 사용하지 않고 모든 I/O 요청을 네트워크를 통해 I/O 서

버로 전달한다.

18

5.3 ext2 성능 평가

그림 9 ext2 파일 시스템의 성능

ext2 파일 시스템의 성능은 그림 9와 같다. 512KB 이하의 작은 파일들은 CPU의 하드웨

어 캐쉬 적중으로 인하여 데이터 전송률이 매우 높게 나타난다. 또한 record size가 작은

경우 read-ahead의 영향으로 연속된 여러 개의 record가 메모리 캐쉬에서 적중되므로 전

송률이 높게 나타난다.

클라이언트 노드의 전체 메모리는 512MB이므로 이보다 작은 크기의 파일을 읽는 경우 메

모리 캐쉬에 모두 저장된다. 따라서 Re-read의 성능은 그림과 같이 약 1.6GB/sec로 일정

하며 메모리 읽기 성능에 근접한다. 또한 작은 파일의 경우 모두 하드웨어 캐쉬에 적중되므

로 전송률이 더욱 높아진다. Random-read의 경우 re-read보다는 전송률이 낮음을 확인할

19

수 있다.

512MB 파일을 읽는 경우 모든 읽기 접근은 디스크를 거치게 된다. 측정 결과 디스크의

읽기 성능은 1024KB 레코드에서 약 37MB/sec이다.

Write 성능은 read에 비하여 1/3 이하로 매우 낮다. 그러나 실제로 중요한 결과인 512MB

파일 쓰기 성능은 1024KB 레코드에서 약 60MB/sec로 read보다 높게 나타났다. 이는

write buffering의 결과라고 생각된다.

5.4 기존 PVFS의 성능평가

그림 10 기존 PVFS의 성능평가

file size (KB)

record size (KB)

20

PVFS의 그래프는 ext2와는 매우 다른 모습을 보여준다. 이는 기본적으로 PVFS의 모든

읽기/쓰기 명령이 네트워크를 통해 I/O 서버로 전달되며 클라이언트 측에서 메모리 캐슁이

전혀 일어나지 않기 때문이다. 따라서 기존 PVFS에서는 네트워크 성능이 파일 전송률을 결

정한다. 한편 Re-read의 경우 같은 블록을 새로 읽기 위해 다시 네트워크에 접근해야 하므

로 read에 비하여 성능이 개선되지 않는다.

본 측정 결과에서는 I/O 서버에서의 디스크 접근은 일어나지 않는다. 가장 큰 크기인

512MB 파일을 읽는 경우라도 네 대의 I/O 서버에 분산되기 때문에 모든 파일 블록은 ext2

를 기반으로 하는 I/O 서버의 메모리 캐쉬에 저장되어 있다.

Read와 write 모두 record size가 64KB 이상으로 커짐에 따라 전송률이 높아진다. 본 실

험에서는 64KB 단위로 데이터를 저장하고 전송하므로 record size가 작은 경우 대역폭을

충분히 활용할 수 없어 성능 저하가 일어나기 때문이다.

Read와 re-read의 성능이 파일 크기와 무관한 반면 write와 random-read의 성능은 파일

크기가 커질수록 증가한다.

본 환경에서 네트워크의 최대 전송률은 1024KB 레코드 크기에서 약 70MB/sec이다.

5.5 PVFS + cache의 성능 평가

21

그림 11 PVFS+cache manager 의 성능 평가

그림 11은 본 연구에서 구현한 캐쉬 관리자를 사용한 PVFS의 성능 평가 그래프이다.

Write의 경우 write-through 캐쉬이므로 기존 PVFS와 동일한 결과를 보여준다. 그러나

read 성능은 기존 PVFS보다 ext2에 유사한 결과를 보여준다. 즉 메모리 읽기로 인한 성능

향상이 일어나는 것이다.

Re-read 및 random-read의 경우 CPU 하드웨어 캐쉬로 인하여 ext2와 동일한 형태의

성능 그래프를 보여준다. 그러나 Read 그래프의 경우 캐쉬 크기를 64MB로 제한하였으므로

파일 크기가 64MB 이하인 경우 점차 성능이 증가하며 파일 크기가 캐쉬 크기를 넘어가는

경우 conflict miss로 인하여 네트워크를 통해 I/O 서버에 접근해야 하므로 기존 PVFS와

22

동일한 성능을 보여준다.

한편 ext2는 Read시 파일 크기 64MB, 레코드 크기 128KB인 조건에서 약 1.6GB/sec의

최대 전송률을 얻는 반면 본 연구에서 구현한 캐쉬는 동일 조건에서 약 1.94GB/sec의 최

대 전송률을 얻었다. 이는 본 연구에서 구현한 캐쉬가 Linux의 버퍼 캐쉬보다 간단하고 효

율적으로 동작하도록 구현되었기 때문이다.

6. 결론

본 연구에서는 PVFS를 기반으로 캐쉬 관리자를 구현하였다. PVFS는 대용량 I/O를 효율적

으로 지원하므로 클러스터 시스템에서 과학 계산용으로 널리 사용되고 있지만 캐쉬를 사용

하지 않아 모든 파일 I/O 요청이 네트워크를 통해 전송되므로 네트워크 성능에 의해 파일

시스템 성능이 제한되는 단점이 있었다. 그러나 본 연구에서는 클라이언트 노드에 캐쉬 관

리자를 제공함으로써 네트워크에 비해 상대적으로 훨씬 빠른 메모리 접근으로 인하여 성능

향상을 도모하였다.

Iozone 벤치마크를 수행한 결과 본 연구의 성능 측정 환경에서 파일 읽기 성능은 디스크

접근 시 37MB/sec, Gigabit Ethernet 네트워크 상에서 PVFS를 사용하는 경우 70MB/sec

로 나타난 반면, 메모리 캐쉬에서 읽는 경우 1.9GB/sec로 기존 PVFS에 비하여 최대 27배

이상의 성능 향상을 가져왔다. 이 결과는 역시 메모리를 캐쉬로 사용하는 ext2의 최대 읽기

성능인 1.6GB/sec 보다 높은 것으로, Linux의 캐쉬 시스템과 비교하여 본 연구에서 커널

내부에 구현한 독자적인 캐쉬 시스템이 보다 효율적이고 우수함을 의미한다.

7. Reference

23

[1] http://www.iozone.org

[2] http://parlweb.parl.clemson.edu/pvfs/