리눅스 FUSE 기반 경량 SSD 성능 평가 시뮬레이터 구현

2-1 SSD 관련 연구

SSD는 하드 디스크와 같이 블록 디바이스로 동작하지만 기존에 할당된 블록(섹터)의 데이터를 수정하는 순간 새로운 데이터는 다른 블록에 저장되어야 하고, 기존 블록은 가비지(garbage)가 된다. 이는 플래시 메모리의 읽기‧쓰기 단위의 크기와 지우기 단위의 크기가 달라 동일한 블록에서의 읽기→지우기→쓰기가 불가능하기 때문인데, 이로 인하여 운영체제에서는 SSD의 물리 블럭을 고정적으로 지정할 수 없다. 이를 해결하기 위해서 그림 1과 같이 SSD는 운영체제에게 고정된 블럭번호를 제공하되, SSD 내부에서 실제로 할당된 블럭번호로 변환하는 방법을 사용하는데 이러한 변환 기능의 범주가 FTL(Flash Translation Layer)이고, FTL은 SSD의 탄생과 함께 수반된 태생적 필수 기능이다 [6]. FTL은 SSD가 제공하는 제한된 RAM 공간에서 핵심인 변환 기능 외에 최적의 블럭 할당 알고리즘 [7], 캐싱 알고리즘 [8]-[9], 가비지 수집 알고리즘 [4][10] 등 다양한 기능을 수행해야 하고, 이들의 최적 조합에 대한 탐구는 시뮬레이션으로 이루어진다.

Fig. 1.

Translation Function of FTL

대부분의 SSD 성능평가 시뮬레이션은 널리 알려진 하드 디스크 성능평가 도구인 DiskSim [11]을 기반으로 변형하여 사용한다 [12]-[14]. 그런데 DiskSim은 입‧출력 버스나 제어기 특성 등 하드웨어를 포함하여 저장장치 하부의 모든 특성에 대한 모델링을 지원하기 때문에 그 규모가 방대하고 이식 과정이 간단하지 않다 [15]. 즉, DiskSim은 운영체제 관점에서의 FTL 기능 구현 시뮬레이션 도구로서는 너무 무겁다.

2-2 리눅스 FUSE

파일시스템은 운영체제의 핵심 구성요소 중의 하나로서 디스크의 물리 저장 공간을 바탕으로 사용자에게 논리적인 저장 조직체계를 제공한다. 운영체제 내에 탑재된 파일시스템과 달리 사용자가 구성하여 제공하는 파일시스템을 사용자 영역 파일시스템이라 하고 [16], 그 대표적인 사례가 리눅스의 FUSE(Filesystem in Userspace) [17]이다. 그림 2는 인터넷 데이터를 사용자에게 파일시스템 뷰로 조직하여 제공하는 리눅스 FUSE 적용 연구 [18]의 개념도이다. [19]는 리눅스 FUSE를 이용하여 파일 업데이트(write) 시 해당 부분을 이미 저장된 내용과 비교하여 일치할 경우 쓰기 작업을 생략하여 SSD 등의 디스크 수명을 연장하는 일종의 래퍼 파일시스템을 구현하였다.

Fig. 2.

Concept of Linux FUSE

리눅스 FUSE는 커널이 파일시스템을 운영하기 위해 사용자에게 요구하는 파일시스템 접근 프로시저들로 이루어지고, 그 중 대표적인 것들은 아래와 같다.

• create(path, mode) : FUSE 영역 즉, 사용자 파일시스템이 마운트된 지점 이하에서의 경로명과 모드를 전달받아 해당 파일을 생성하고, 이 파일을 특정할 자체 id를 돌려준다.
• open(path, mode) : 이미 존재하는 path가 가르키는 파일을 주어진 모드로 개방하여 이 파일을 특정하는 id를 돌려준다.
• mkdir(path, mode) : 주어진 경로명에 디렉터리를 생성한다.
• getattr(path, buf) : 주어진 경로명의 파일이나 디렉터리의 속성(stat)을 돌려준다.
• readdir(path, buf) : 주어진 경로명의 디렉터리 엔트리들의 속성(name, stat)을 돌려준다.
• read(id, buf, offset, size) : open(), create()에 의해 개방된 파일을 읽어 돌려준다.
• write(id, buf, offset, size) : open(), create()에 의해 개방된 파일에 주어진 내용을 쓴다.
• release(id) : open(), create()에 의해 개방된 파일을 폐쇄한다.
• ioctl(id, cmd, arg) : open(), create()에 의해 개방된 파일에 대하여 특정 커멘드를 수행한다.
• unlink(path) : 주어진 경로명의 파일을 제거한다.
• rmdir(path) : 주어진 경로명의 디렉터리를 제거한다.

위 프로시저 들은 그림 3과 같이 fuse_main() 라이브러리를 통해서 커널에 등록하고, 이 때 ac, av에는 해당 사용자 파일시스템을 가상으로 마운트할 지점(디렉터리 경로명)을 전달한다.

Fig. 3.

Enrollment of FUSE Procedures in Kernel

3-1 가상 SSD 파일 및 디렉터리

FUSE로 구현된 사용자 파일시스템(이하 FTL 파일시스템)에 접근하고자 하는 어플리케이션은 해당 파일시스템의 마운트 지점 이하를 접근한다. 이 때, 커널은 마운트 지점 이하의 경로명만을 FTL 파일시스템에 전달한다. FTL 파일시스템은 전달된 경로명을 의도한 실제 경로명으로 대응시켜 처리한다. 이를테면 FTL 파일시스템이 “/home/ftlfs"에 마운트되어 있을 때, 어플리케이션이 경로명으로 “/home/ftlfs/files/f000"을 지정하면 커널은 ”/files/f000"을 FTL 파일시스템에 전달하고, FTL 파일시스템은 실제 파일시스템의 특정 디렉터리(예 “/FTL_FS/”) 아래에 해당 경로명을 주입하여 “/FTL_FS/files/f000"를 최종 경로명으로 설정한다. 이와 같은 경로명 변환은 create(), open(), unlink(), mkdir(), rmdir() 등 경로명을 직접 필요로하는 모든 FUSE 프로시저들에게 적용된다. 그림 4에 FTL 파일시스템의 open() 프로시저를 보였다.

Fig. 4.

Open() Procedure of FTL Filesystem

3-2 FTL 파일시스템의 논리 및 물리 페이지

SSD를 사용하는 운영체제는 SSD를 논리 페이지(섹터)들의 집합으로 보고 할당된 논리 페이지를 파일시스템에 기록할 것이므로 모든 논리 페이지에 대한 할당 여부가 관리되어야 한다. 이를 위하여 FAT(File Allocation Table) 방법을 적용하여 ftlfs_get_lpn(), ftlfs_put_lpn() 프로시저를 둔다. 할당된 논리 페이지 번호는 FTL의 쓰기 프로시저(ftl_write())에 전달되어 실제 할당된 SSD 물리 페이지 번호로의 대응을 위해 매핑 테이블에 삽입된다. 이 때, 운영체제 관점에서의 논리 페이지 번호는 개방된 해당 파일의 내용으로 저장하여 관리한다. 이를테면 “/home/ftlfs/files/f000"에 논리 페이지 3241, 4352, 5463 번이 할당되었다면 이 파일의 내용으로 그림 5와 같이 이들 세 개의 번호를 저장한다. 이 때, 주어진 입‧출력 위치 offset에 대응되는 논리 페이지는 offset/page_size 식으로 얻을 수 있으며, 이 파일이 차지하는 페이지 단위 공간은 3*page_size로 얻을 수 있으나 정확한 크기는 자체로 관리하는 파일 테이블(Ftbl[])에 관리한다. 그림 4를 기반으로 작성된 FTL 파일시스템의 write() 프로시저를 그림 5에 보였고, read() 프로시저도 이와 유사하게 작성된다.

Fig. 5.

Logical and Physical Page of FTL Filesystem

Fig. 6.

Write() Procedure of FTL Filesystem

3-3 FTL 변환 및 쓰기‧읽기 모듈

FTL 모듈은 FTL 파일시스템으로부터 논리 페이지 번호를 전달받아 새로운 플래시 물리 페이지를 할당하여 맵 테이블에 대응시킨 후 쓰거나, 이미 대응되어있는 페이지에 대하여 읽기를 수행한다. 이 때, FTL 캐시 전략에 따라 플래시 물리 페이지에 대한 쓰기‧읽기는 일어나지 않을 수 있다. 이 과정에서 운영체제 수준에서의 입‧출력 요구 대비 물리적 입‧출력 비율을 얻을 수 있다. 그림 7 ~ 그림 8은 FTL 쓰기‧읽기 프로시저이고, 여기서 lpn은 논리 페이지 번호를, ppn은 물리 페이지 번호를, fbn 과 fpn은 플래시 블록 및 페이지 번호를, OWrite와 ORead는 운영체제의 요구 빈도를, TGpage와 TBpage는 플래시의 가비지 페이지와 데이터 페이지를 각각 카운트한다.

Fig. 7.

Write() Procedure of FTL

Fig. 8.

Read() Procedure of FTL

3-4 FTL 캐시 모듈

실험하고자 하는 캐시 정책에 따라 FTL 쓰기‧읽기 프로시저에 캐시 투과 과정을 둔다. 캐시의 크기는 실험 대상인 SSD가 제공하는 RAM의 범위로 설정하되, 실제 데이터를 기록할 필요는 없으므로 캐시 검색 키 등 운영상 필요한 항목만을 설정한다. 그림 9는 캐시를 그룹핑하고, 쓰기 시 곧바로 플래시까지 저장하지 않고 일단 캐시에만 저장하는 이른바 Read/Write 캐싱 기법을 사용하는 예이고, 여기서 TDcache는 캐시와 플래시의 내용이 불일치하는 불결(dirty) 캐시를 카운트한다. 그 밖에 캐시 히트 읽기와 쓰기를 HRead와 HWrite에 카운트 한다.

Fig. 9.

Read() Procedure of FTL Cache

3-5 FTL 가비지 수집 모듈

그림 9에 플래시 블록 하나를 랜덤하게 선택하여 그곳에 포함된 가비지를 회수하는 예를 보였다. 이 때 가비지 수집 대상이 되는 플래시 블록에 포함된 각 페이지가 빈 것인지, 유효한 것인지, 가비지인 것인지의 판단은 해당 페이지의 여분(spare) 영역에 기록된 lpn(논리 페이지) 값에 의해 아래와 같이 결정된다.

• lpn이 0(초기상태)이면 빈 페이지
• lpn에 대한 맵 테이블 내용과 해당 페이지가 일치하면 유효 페이지, 그렇지 않으면 가비지 페이지

가비지 수집 대상 블록에 포함된 유효 페이지 들은 다른 블록의 빈 페이지에 복사되어야 하므로, 이들 유효 페이지와 관련된 맵 테이블과 캐시의 수정이 필요하다. 그림 10에 보인 ftl_get_random_collect_block() 프로시저는 선택된 블럭의 유효 페이지들을 캐시의 앞 부분에 읽고, 바로 다음 캐시 위치를 돌려준다.

Fig. 10.

Garbage_collect() Procedure of FTL

가비지 수집 시점은 다양한 시점에서 다양한 방법으로 이루어질 수 있는데, 여기서는 빈 페이지 개수가 하한선 아래로 내려가면 그림 7의 FTL의 write() 프로시저에서 수행하도록 한다.

3-6 플래시 메모리 모듈

FTL 캐시와 마찬가지로 플래시 메모리에도 실제 데이터를 저장할 필요는 없으므로 페이지의 데이터 영역은 제거하고 여분 영역에 논리 페이지 번호(lpn) 항목만 배치하되, 그 개수가 방대하므로 디스크 파일에 메모리 주소를 대응시켜 할당한다. 그림 11에 플래시 메모리 관련 프로시저를 보였고, 이들 프로시저에서는 물리적 입‧출력 및 지우기 빈도를 FRead, FWrite, FErase에 각각 카운트한다.

Fig. 11.

Write()/read() Procedure of Flash

4-1 검증 방법 및 환경

구현 시뮬레이터의 기능 검증을 위해 에너지 소모 관점에서 캐시 전략이 미치는 영향을 분석한 연구 [9]의 실험을 동일하게 수행하여 동일한 결과가 도출되는지를 비교하여 기능을 검증하고, 리눅스 운영체제 자체의 캐시 정책을 반영한 새로운 분석 기능을 확인한다. 기능 검증은 그림 12 형태의 입‧출력 어플리케이션 유형을 표 1과 같이 분류하고, 이들을 표 2와 같이 3 가지로 조합한 각 워크로드를 LRU(Least Recently Used)와 NUR(Not Used Recently) 두 가지 캐시정 책별로 실행한 결과를 분석한다. 표 1의 각 어플리케이션들은 약 40MB 크기의 파일에 대하여 1,000~9,000 바이트의 레코드를 50,000번 입‧출력하고, 실험 플랫폼은 표 3과 같다.

Fig. 12.

A Sample Workload Application

Table 1.

Classification of I/O Application

Table 2.

Classification of I/O Workload

Table 3.

Experimental Environment

4-2 실험 결과 및 분석

1) 시뮬레이터 기능 검증

표 4에 표 2의 각 워크로드들이 FTL에서 유발한 캐시 읽기 적중(CR), 캐시 쓰기(CW), 플래시 읽기(FR), 플래시 쓰기(FW) 등의 빈도에 따른 캐시 적중률을 보였고, 그림 13에는 그 추이를 그래프로 보였다. 이 결과는 연구 [9]와 동일하다.

Table 4.

Hit Ratio by Cache Management Policy

Fig. 13.

Cache Hit Ratio of LRU and NUR

표 5에는 표 4의 FW 및 FW와 플래시 지우기(FE), 가비지 수집에 따른 플래시 읽기(GR) 및 플래시 쓰기(GW) 빈도를 종합한 결과에 표 1의 플래시 연산별 에너지 소모량을 적용하여 산출한 워크로드별 총 에너지 소모량을 보였고, 그림 14에 그 추이를 그래프로 보였다. 이는 LRU가 NUR보다 적중률은 높지만 에너지 효율성은 오히려 낮을 수 있다는 연구 [9]와 동일한 결과이고, 이는 시뮬레이터의 구현 방향이 적합함을 의미한다.

Table 5.

Energy Consumption by Cache Management Policy

Fig. 14.

Energy Consumption of LRU and NUR

2) 리눅스 커널 캐시 기반 실험

표 4~5의 실험은 리눅스 커널의 캐시를 우회하여 워크로드의 입‧출력 요구를 FTL에 직접 전달하는 환경이었으나, FUSE 기반의 시뮬레이터는 리눅스 커널의 캐시를 경유하여 전달함으로써 실제 운영체제 환경에서의 실험이 가능하다. 이를 위해서 그림 4의 FTL 파일 개방 프로시저에서 direct_io 항목을 0으로 설정한다. 표 6은 커널 캐시를 우회하는 경우(LRU, NUR)와 경유하는 경우(LRU-cache, NUR-cache)의 총 입‧출력 량을 보였는데, 커널 캐시를 경유하는 경우 그 양이 약 8% 가량 증가하지만, 그림 15의 총 에너지 소모량을 보면 오히려 약 절반으로 감소함을 볼 수 있다. 이는 그림 14에 보인 바와 같이 커널 캐시를 경유하면 FTL의 캐시 적중률이 크게 높아지기 때문인 것으로 분석되는데, 이 경우 FTL 캐시 적중률이 높아지는 이유에 대해서는 연구가 더 이루어져야 한다.

Table 6.

Total I/O Traffic (times)

Fig. 15.

Total Energy Consumption