AngelPlayer`s Diary

4. 성능 평가

제안된 FTL 설계 평가를 위해 그림 4에 나온 시제품 16MB CF 스토리지 시스템에서 체계 구현

제안된 로그 블록 체계의 성능을 대체 블록 체계 및 페이지 수준 리매핑 체계의 성능과 분석 비교를 위해 3가지 체계 각각에 대한 시뮬레이터 개발 및 추적 기반 시뮬레이션 수행

사용된 트레이스는 프로토타입을 4개의 다른 디지털 카메라(Canon Powershot GI, Canon PowerShot S100, Kodak DC290, and Sanyo VPC-SXSOO)와 PDA(Compaq iQH 3630), 리눅스 운영 체제를 실행하는 노트북 컴퓨터

프로토타입의 펌웨어를 수정하여 트레이스 수집을 가능하게 함

 

디지털 카메라의 워크로드(작업량)을 위해 사진을 찍고, 탐색, 지우는 일반적인 모드로 카메라를 작동

PDA는 웹 동기화, MP3 파일 다운로드 및 재생, 파일 복사 등

리눅스 노트북 컴퓨터의 워크로드는 Anderw 벤치마크 사용

쓰기 명령의 수 및 작성된 페이지의 총 개수 측면에서 추적의 특성은 표 2에 제시

추적에는 많은 순차적 접근과, 집중적으로 접근하는 핫스팟이 포함

순차적 액세스 패턴은 일반적으로 이미지 파일과 같은 사용자 데이터 저장에서 비롯되는 반면, 핫 스팟은 파일 생성/삭제로 인한 파일 시스템(Microsoft FAT 및 Linux Ext2)의 메타데이터 업데이트에서 비롯된다.

 

 

그림 5는 그리디 정책(greedy policy | P/G로 표시)과 비용 편익 정책(cost-benefit policy | P/C로 표시)을 가진 두 가지 버전의 페이지 레벨 매핑 체계를 포함하여 시뮬레이션된 세 가지 체계에 대한 결과를 보여줌

 

전용 블록에 매핑 테이블을 저장하는 비용을 확인하기 위해 맵 블록없이(L-M으로 표시) 체계를 시뮬레이션

추가 블록(Extra blocks) 수는 대체 블록 구성표의 대체 블록, 로그 블록, 자유 블록, 맵 블록의 추가 물리적 블록 수, 페이지 수준 재매핑 구성표의 사용 가능한 블록수

 

--> 정리 (맞는지 체크 필요)

R - 대체 블록 체계

L - 로그 블록 체계

맵 블록 없는 로그 블록 체계 - L-M

그리디 정책을 가진 페이지 레벨 매핑 체계 - P/G

비용 편익 정책을 가진 페이지 레벨 매핑 체계 - P/C

 

 

사용한 성능 지표는 추가 지우기 작업의 수이며, 이 값은 평가 중인 체계에 의해 수행되는 지우기 작업 수에서 이상적인 체계의 지우기 작업 수를 뺀 값으로 정의

이상적인 체계는 모든 n개의 페이지 쓰기 요청에 대해 하나의 지우기 작업을 수행하는 체계로 정의 (n = 블록당 페이지 수)

 

추가 지우기 작업의 주요 원인은

1. 대체 블록 체계에서 대체 블록을 병합할 때 사용되지 않은 상태로 남아있는 페이지

2. 로그 블록이 로그 블록 체계에서 병합될 때 자유 블록의 소비

3. 페이지 수준 재매핑 체계에서 블록을 정리할 때 유효한 페이지를 복사하기 위해 자유 페이지를 소비

 

추가 쓰기 작업 수는 평가 대상 시스템에서 수행된 쓰기 작업 수에서 요청된 페이지 쓰기 수를 뺀 값으로 정의

해당 오버헤드의 주 원인은 병합/지우기 작업을 수행할 때 복사된 페이지

측정 전에 동일한 기록를 실행하여 시스템을 활성화시켰음

 

 

결과를 통해 제안된 로그 블록 체계는 대체 블록 체계보다 모든 경우에 일관되게 추가 지우기 작업 수 측면에서 성능이 훨씬 우수함

반면 전체 성능은 호스트 시스템에 따라 크게 달라짐 (y축 참고)

 

블록 레벨 매핑의 한계로 인해 자주 반복되는 작은 크기의 쓰기를 처리하는데 대체 블록이 효율적이지 못하기 때문

반대로, 로그 블록 체계는 페이지 수준 매핑을 사용하여 로그 블록은 작은 크기 쓰기를 처리하며, 긴 순차 쓰기는 블록 수준 매핑에서처럼 효율적으로 수행

 

 

한가지 흥미로운 결과는 로그 블록 체계가 때때로 훨씬 더 많은 하드웨어 리소스를 필요로 하는 페이지 수준의 리매핑 체계를 능가한다는 것

호스트 요청의 25% 이상이 블록보다 크기가 작은 Kodak 카메라에서 두드러짐

 

이러한 원인의 이유로 기록에 기반한 파일 시스템의 성능은 일반적으로 파일 시스템의 활용률(총 용량에 대한 파일에 할당된 스토리지의 비율)에 매우 민감

스토리지 서브시스템의 관점에서 활용도는 파일 시스템에서 볼 수 있는 것보다 높으며 파일 시스템이 파일에 할당된 저장 공간을 확보하더라도 결코 낮아지지 않음

-> 스토리지 서브시스템은 이러한 상위 계층 활동을 엄격하게 계층 구조로 인식하지 못하기 때문에

--> ??

따라서 활용도는 16, 32, 64에서 1024의 총 블록인 여유 공간을 위해 예약된 추가 블록 수에만 의존

-> 추가 블록 수가 동일한 다른 스키마에 비해 페이지 수준 재매핑 스키마가 성능이 크게 저하됨

--> ??

 

지역 수집(locality gathering)과 함께 보다 정교한 지우기 정책이 페이지 수준 재매핑 체계의 성능 저하를 완화할 것으로 기대

하지만 근접 주소가 작성될 때 단일 로그 블록으로 수집되기 때문에 로그 블록 체계는 유사한 효과를 달성할 수 있음

이 방법은 연속적인 쓰기 요청을 순차적인 위치에서 수행하는 디스크 기반 스토리지 시스템 영역에서는 사용되지 않음

 

 

또한 로그 블록 체계의 마모 레벨링(wear-leveling) 특성을 측정

이를 위해 Microsoft FAT를 기반으로 디지털 카메라를 에뮬레이트하여 스토리지 시스템에 스트레스를 줄 만큼 긴 합성 추적을 생성

그림 6(a)는 논리 주소에 대해 생성된 추적의 쓰기 빈도를 표시 -> FAT의 빈번한 업데이트로 인해 만들어진 핫스팟을보여줌

 

 

그림 6(b)는 시뮬레이터를 구동하여 각 물리 블록에서 수행된 소거 작업의 수를 카운트

결과적으로 물리 블록을 병합/스위치 작업에 의해 교환함으로 핫스팟이 균일하게 분포

그러나 예외적으로 마모된 블록이 여전히 존재하며, 맵 블록이 해당

 

 

그림 6(c)와 같이 주기적으로 자유 블록과 교환을 통해서 해결 가능

 

 

또한 다양한 블록 크기와 다양한 수의 추가 블록에 대한 시뮬레이션도 유사한 결과가 나타남

전반적으로 로그 블록 체계가 블록 레벨 재매핑 체계보다 성능이 훨씬 우수하고, 페이지 레벨 재매핑 체계와 비교했을때 보다 안정적인 성능 특성을 제공하면서 리소스 요구 사항을 크게 낯춤

 

 

 

5. 결론

본 논문에서 두 극단적인 주소 변환사이에 있는 새로운 FTL 설계를 제안

기존 극단적인 주소 변환 방법

1. 블록 레벨 주소 변환 (페이지의 직접 매핑된 캐시와 유사한 제한을 가함)

2. 페이지 수준 주소 변환 (페이지 내 완전히 연관된 캐시에 제한없이 배치)

로그 블록 체계는 단일 로그 블록 내 어디에서나 배치될 수 있지만 다른 로그 블록에는 배치되지 않음

 

 

로그 블록 속성은 새로운 균형을 도입

1. 한계 추가 리소스 유고 사항만으로 작은 크기의 쓰기를 효율적으로 처리함으로써 블록 레벨 변환 체계보다 성능이 상당히 우수

2. 워크로드의 활용률(스토리지 하위 시스템의 추가 공간 비율)에 덜 밀감

-> 반대로 순수한 페이지 수준 변환 체계는 특정 구성에 대해 현저하게 성능이 저하됨을 보여줌

이 결과의 이유는 로그 블록 체계는 주소가 근접한 데이터를 단일 블록으로 수집되는 반면에, 페이지 수준 변환 구성표 데이터는 도착한 순서대로 배치되기 때문에, 이것은 자기 디스크의 검색 시간을 줄이는데는 유용하지만 플래시 메모리에는 영향을 미치지 않음

 

 

또한 플래시 메모리에서 요구에 따라(on demand) 변환 정보를 가져올 수 있도록 구성함으로써 리소스 요구사항을 줄임

스토리지 시스템의 용량과 독립적으로 매핑 테이블과 다른 FTL 데이터 구조를 저장하기 위해 6KB SRAM 예산을 충족

 

 

 

 

 

 

 

- 참고 문헌 -

A SPACE-EFFICIENT FLASH TRANSLATION LAYER FOR COMPACTFLASH SYSTEMS

https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.124.3802&rep=rep1&type=pdf

 

'개인 공부 > Flash Memory' 카테고리의 다른 글

HMB (Host Memory Buffer)  (0) 2021.03.25
BAST (2021-02-17)  (0) 2021.02.17
BAST (2021-02-16)  (0) 2021.02.16
A survey of Flash Translation Layer (2021-02-11)  (0) 2021.02.11
A survey of Flash Translation Layer (2021-02-09)  (0) 2021.02.09

공유하기

facebook twitter kakaoTalk kakaostory naver band