윈도우즈 기반 플래시 디스크의 성능 분석을 위한 도구 개발

Presentation on theme: "윈도우즈 기반 플래시 디스크의 성능 분석을 위한 도구 개발"— Presentation transcript:

1 윈도우즈 기반 플래시 디스크의 성능 분석을 위한 도구 개발
시 기 : 2005/04/22 발표자 : 박 성 환 Development of Performance Analysis Tool for Flash Disk on 윈도우즈 Platform

2 목 차 서론 관련 연구 실험 실험 결과 결론 참고 문헌 윈도우즈 기반 플래시 메모리의 등장과 성능 분석의 필요성
FTL 알고리즘 윈도우즈의 I/O 윈도우즈 드라이버의 작성 실험 디스크 I/O를 얻기 위한 드라이버 작성 및 부착 FTL APAT(FTL Algorithm Performance Analysis Tool) 실험 구조 실험 조건 실험 결과 Diskiomo 드라이버의 부착모습 실험 프로그램의 동작 모습 결론 참고 문헌

3 서 론

4 플래시 메모리의 등장 배경 최근 플래시 메모리를 장착한 기기들이 많이 등장함 MP3 플레이어 디지털 카메라 핸드폰
최근 디지털 카메라, MP3 플레이어, 핸드폰등 이동성이 중요한 요소로 차지하는 기기들이 많이 등장하였다. 이에 따라 소형화, 대용량화, 저전력화, 비휘발성, 고속화 그리고 충격에 강한 메모리가 필요하게 되었다. 플래시 메모리는 이러한 요구사항을 만족시키는 메모리로 최근 많은 이슈(Issue)를 일으키고 있다. 때문에 플래시 메모리는 이동성이 강한 제품에 많이 장착되어 진다. 하지만, 플래시 메모리가 디스크보다 장점이 많아 점차 디스크를 대체해 나아갈 것이다. 디지털 카메라 핸드폰 MP3 플레이어

5 플래시 메모리의 장단점 이동성에 맞는 플래시 메모리의 장점들 플래시 메모리의 단점(극복 사항) 소형화 대용량화 저전력화
비휘발성 고속화 충격에 강함 플래시 메모리의 단점(극복 사항) 쓰기 전 소거 한 블록이 10만 번 이상 발생하게 되면 오류를 발생할 가능성이 높아짐

6 플래시 메모리란? 플래시 메모리는 EEPROM의 한 종류 분류 NAND 형 NOR 형
고집적이 가능하여 데이터를 저장하는 데 주로 사용 페이지 단위의 I/O만을 지원 NOR 형 처리 속도가 빨라 프로그램 코드를 저장하는데 주로 사용 바이트 단위의 I/O를 지원 접근시간 읽기 (Read) 쓰기 (Write) 소거 (Erase) NOR형 플래시 150ns(1B) 15μs(512B) 211μs(2B) 3.5ms(512B) 1.2s (128KB) NAND형 플래시 10μs(1B) 36μs(512B) 226μs(2B) 266μs(512B) 2ms(16KB) 하드 디스크 12.4ms(512B) - 표 1 플래시 메모리는 EEPROM (Electrically Erasable Programmable Read-Only Memory)의 한 종류이다. 종류로는 NAND 플래시 메모리와 NOR 플래시 메모리가 있다. NAND 플래시 메모리는 고집적이 가능하여 주로 정보를 저장하는데 사용하는 반면, NOR 플래시 메모리는 빠른 처리 속도 때문에 주로 프로그램 코드를 저장하는데 사용하고 있다. 중요한 것은 표1 에서 보듯이, NAND 플래시 메모리이든, NOR 플래시 메모리이든 하드 디스크보다는 더욱 빠른 속도로 동작한다는 것이다.

7 디스크에서 플래시 메모리로 기대 성능 현재 디스크를 플래시 메모리로 향후 대체 시 주의사항
휴대할 수 있을 정도의 크기와 무게를 제공함 휴대 시 발생하는 잦은 충격에 정보 보호력이 뛰어 남 현재 디스크를 플래시 메모리로 향후 대체 시 주의사항 플래시 메모리 는 쓰기 전 소거해야 하는 특징이 있음 플래시 메모리가 하드 디스크에 비해서 많은 장점이 존재한다. 때문에 점차 하드 디스크는 플래시 메모리로 대체되어 질 것으로 예상된다. 개인용 컴퓨터에서도 대용량의 플래시 메모리가 사용 될 것이며, 휴대용 기기, 가전 기기에서도 플래시 메모리가 사용되어 질 것이다. 특히 휴대 기기에서는 소비자가 만족 할만한 크기와 무게를 제공하며, 잦은 충격에도 높은 정보 보호력을 제공할 것이다. 플래시 메모리도 단점이 존재한다. 그것은 Erase Block Before Overwrite로서 기록된 곳에 Overwrite를 하려면 반드시 삭제 연산을 한 뒤에 기록를 수행해야 한다는 것이다. 이는 기록된 곳에 그대로 다시 기록을 하는 하드 디스크에 비해 동일 I/O요청에 대해 더 많은 수행 시간이 걸린다는 것을 의미 한다. 또한, 삭제 연산의 제한을 가지고 있는 것은 플래시 메모리의 입장에선 치명적인 단점이 된다.

8 FTL 알고리즘의 필요성 디스크와는 다른 플래시 메모리만의 단점을 보안하기 위함 플래시 메모리의 삭제 횟수의 최소화
플래시 메모리는 한 블록당 10만 번 정도의 삭제연산이 발생하면 오류를 발생하기 때문 삭제블록 평준화(Wear-Leveling)을 조절 특정 블록이 못쓰게 되면 플래시 메모리 전체를 못쓰게 되기 때문 FTL 알고리즘에서의 연산 속도의 최소화 평준화된 속도를 제공해야 함 플래시 메모리의 블록은 10만 번 이상 삭제가 되면 불량이 된다는 것과 때문에 모든 블록이 고르게 삭제되어야 수명이 길어진다는 것, 그와 동시에 연산 속도 역시 최소화, 평준화되어 제공되어야 한다. 이러한 요구사항을 해결하기 위해 Flash Translation Layer(이하 FTL)이 등장하게 되었다. FTL 알고리즘은 요청된 논리 섹터 번호(Logical Sector Number)와 물리 섹터 번호(Physical Sector Number)를 맵핑(Mapping)을 통해 상위 파일 시스템이 바라보는 논리적 수준과 실제 물리 플래시 메모리가 바라보는 물리적 수준을 연결시켜준다. 논리적 수준과 물리적 수준을 효율적으로 맵핑함으로 해서 플래시 메모리의 삭제 연산 횟수의 최소화가 가능하다. 또한 삭제 연산이 일어나는 블록의 평준화가 가능해져 전체적인 플래시 메모리의 수명이 늘어나게 된다. 한 I/O 요청에 대해 평준화된 연산 소요 시간을 제공함으로 해서 전반적으로 일괄적인 반응 속도를 제공하게 된다.

9 윈도우즈 선택 이유 거의 모든 개인 컴퓨터에는 윈도우즈가 주류를 이루고 있음
때문에 플래시 메모리를 적용한 기기들은 대부분 윈도우즈 를 지원함 FTL 알고리즘 작성시 윈도우즈의 디스크 I/O 패턴으로 시뮬레이션 하는 것이 좋음 하드 디스크와 마찬가지로 플래시 메모리도 와는 비 종속적이다. 플래시 메모리의 FTL 알고리즘 성능을 평가하기 위해 윈도우즈 를 선택한 이유는, 현재 대부분의 개인용 컴퓨터에서는 그래픽 기반의 윈도우즈 를 사용하고 있고, 플래시 메모리를 장착한 대부분의 기기가 윈도우즈 에서 호환되게 제작되어야 하기 때문이다. 때문에 플래시 메모리로 전달되는 I/O 분석을 윈도우즈 의 I/O로 실험 하는 것은 어찌보면 당연하다 할 수 있을 것이다.

10 관련 연구

11 플래시 시스템 File System FTL FTL Algorithm LSN PSN/ PBN Control
RAM Table Flash Memory LSN FTL Algorithm PSN/PBN

12 FTL 알고리즘 논리적 수준과 물리적 수준의 맵핑 블록의 효율적 사용 블록 삭제 연산의 평준화 및 최소화
플래시 메모리와 파일 시스템 사이에 위치 파일 시스템이 플래시 메모리를 하드 디스크처럼 사용할 수 있게 해줌 FTL을 사용하게 되면 기존의 파일 시스템 을 사용할 수 있다는 장점이 있음 블록의 효율적 사용 전체적인 블록을 효율적으로 사용해 읽기,쓰기와 삭제 연산을 줄이는 역할을 함 블록 삭제 연산의 평준화 및 최소화 전체 블록은 균등한 삭제 횟수를 가져야만 함 플래시 메모리는 한 블록당 10만 번 정도의 삭제연산이 발생하면 오류를 발생하기 때문 FTL 알고리즘은 플래시 메모리와 파일 시스템 사이에 존재하며 파일 시스템이 플래시 메모리를 논리적 수준에서 바라볼 수 있게 해준다. 때문에 파일 시스템은 플래시 메모리를 하드 디스크를 사용하듯이 단지 읽기와 쓰기 연산만으로 사용할 수 있다. FTL 알고리즘은 파일 시스템으로 부터 전달받은 섹터번호와 길이를 가지고 효율적으로 맵핑을 하여 전체적으로 읽기,쓰기와 삭제 연산을 줄이는 역할을 한다. 그 정도는 FTL 알고리즘의 성능에 달려있다고 할 수 있겠다. 플래시 메모리는 한 블록이 10만 번 이상 삭제가 되면, 오류를 발생시켜 전체 플래시 메모리를 사용할 수 없게 된다. 때문에 FTL 알고리즘이 블록 삭제 연산을 평준화 시켜줘야만 한다. 이것 또한, FTL 알고리즘의 성능에 따라 차이를 보일 수 있다.

13 FTL 맵핑 알고리즘 LSN FTL Algorithm PSN/PBN 페이지단위 주소변환(page-level address mapping) 은 정교하게 주소를 변환하기 때문에 성능은 좋은데 반하여 주소변환 테이블의 크기가 커 제작비용이 높다. 블록단위(block-level address mapping) 주소변환은 비 정교하게 주소를 변환하기 때문에 주소변환 테이블의 크기는 작지만, 내부의 하나의 페이지에 대한 수정연산이 발생해도 전체 블록을 삭제하고 갱신해야 하는 추가비용이 있다. 뿐만 아니라 이 과정을 수행하는 도중에 폴트가 발생하면 데이터의 일관성을 깨뜨릴 수 있다. 혼합단위(Hybrid address mapping) 주소 변환은 페이지단위 주소변환과 블록 단위 주소변환을 같이 사용하는 것을 말한다. FTL 알고리즘은 RAM을 이용해 논리적 수준을 물리적 수준으로 맵핑 시켜주는 역할도 하고 있다. 이때 맵핑 기법에는 크게 세가지로 구분된다. 페이지 맵핑은 정교하게 주소를 변환하기 때문에 성능이 좋은 반면, 테이블의 크기가 커져 테이블을 저장할 RAM의 크기가 커지는 단점이 있다. RAM 크기가 커지면, 제작 비용이 높아진다. 블록 맵핑은 페이지 맵핑 보다는 덜 정교하게 주소를 변환하기 때문에 해당 블록에서 알고리즘 별로 탐색하는 추가적인 연산이 소요된다. 이는 플래시 메모리의 읽기, 쓰기와 삭제 연산을 증가시키는 요인이 되기도 한다. 하지만, 맵핑 테이블의 크기는 작아져 RAM크기도 작아지기 때문에 제작 비용이 낮아지는 효과가 있다. 혼합 맵핑은 페이지 맵핑과 블록 맵핑 기법을 혼용하여 사용하기 때문에 두 기법의 장단점을 모두 가지고 있는 기법이다.

14 RAM(Random Access Memory) 테이블
RAM의크기는 전체 시스템의 비용에 중요요소, RAM의 크기가 작아 질수록 시스템의 비용이 작아지며, FTL 알고리즘은 자신의 RAM 구조를 가지고 있고 RAM 구조에 따라 FTL 알고리즘을 나눌 수 있음 논리-물리 멥핑 정보(Logical to physical mapping information): RAM의 주요한 사용은 물리 맵핑 정보를 논리적으로 저장하는 것이다. RAM 정보에 접근함으로써 자료를 읽거나 쓰는 물리 플래시 메모리의 위치는 효과적으로 찾을 수 있음 여유 메모리 공간 정보(Free memory space information):단지 플래시 메모리에 있는 빈 메모리 공간을 RAM에 저장함으로써 FTL 알고리즘은 그 이상의 플래시 메모리 접근 없이 메모리 공간을 관리할 수 있음 삭제블록 평준화 정보(Information for wear-leveling):수준을 지닌 정보는 RAM에 저장 될 수 있음. 예를 들어 플래시 메모리 블록의 삭제횟수는 RAM에 저장 될 것임 RAM의 크기는 전체 시스템의 비용에 중요요소이다. 왜냐하면 RAM의 크기가 작아 질수록 시스템의 제작 비용이 낮아지기 때문이다. FTL 알고리즘은 자신의 RAM 맵핑 구조를 가지고 있고 이에 따라 플래시 메모리 제작 비용은 달라질 수 있다. RAM에 저장하는 정보는 대략 다음과 같다. 논리-물리 멥핑 정보(Logical to physical mapping information) RAM의 주요한 사용은 물리 맵핑 정보를 논리적으로 저장하는 것이다. RAM 정보에 접근함으로써 자료를 읽거나 쓰는 물리 플래시 메모리의 위치는 효과적으로 찾을 수 있다. 여유 메모리 공간 정보(Free memory space information) 단지 플래시 메모리에 있는 빈 메모리 공간을 RAM에 저장함으로써 FTL 알고리즘은 그 이상의 플래시 메모리 접근 없이 메모리 공간을 관리할 수 있다. 삭제블록 평준화 정보(Information for wear-leveling) 수준을 지닌 정보는 RAM에 저장 될 수 있다. 예를 들어 플래시 메모리 블록의 삭제횟수는 RAM에 저장 될 것이다.

15 섹터 맵핑(Sector Mapping) 모든 논리 섹터(logical sector)는 대응하는 물리 섹터(physical sector)와 대응(mapping) 기본 동작 빈 물리 섹터를 찾고, 거기에 자료를 기록 한 후, 멥핑 테이블(mapping table)에 적용 만약 빈 섹터가 없다면, 플래시 메모리에서 희생할(victim) 블록을 찾아, 스페어 빈 블록(spare free block)에 유효한 자료를 복사한 후 멥핑 테이블을 갱신(update). 마지막에는 희생할 블록을 삭제하고, 그 블록은 스페어 블록(spare block)이 될 것임 섹터 맵핑은 모든 논리적 섹터를 물리적 섹터와 맵핑 시키는 기법이다. 때문에 RAM에는 플래시 메모리에 존재하는 모든 섹터의 개수만큼의 크기가 필요하다.

16 블록 맵핑(Block Mapping) 논리 블록(logical block) 내에 있는 논리 섹터 오프셋(logical sector offset)이 물리 블록 내에 있는 물리 섹터 오프셋(physical sector offset)과 동일 작은 크기의 멥핑 정보(mapping information)을 요구함. 그러나 만약 파일 시스템이 여러 번 같은 논리 섹터 번호(LSN:Logical Sector Number)에 기록를 요구하면 빈번히 복사와 삭제 연산을 수행하여 심각한 실행 하락을 야기 시킴 멥핑 테이블을 재구성하는 경우, 물리 블록 첫 번째 페이지(page)의 스페어 영역(spare area)에 논리 블록 번호(LBN:Logical Block Number)을 기록함 블록 맵핑은 섹터들을 블록으로 나누어 개념적으로 사용하는 것이다. 때문에 블록 번호만을 RAM에 저장하여 블록 안에서의 오프셋(Offset)을 계산해 해당 섹터를 찾아낸다. 때문에, RAM의 크기는 플래시 메모리에서 블록의 개수 만큼의 크기가 필요하게 된다. 블록 멥핑이 섹터 맵핑보다 장점이라고 할 수 있는 것은 RAM의 크기가 작아지는 것도 있지만, 삭제 연산이 블록 단위로 이루어 지기 때문에 삭제 연산에 있어서 더 효율적이라고 볼 수 있다.

17 혼합 맵핑(Hybrid Mapping) 물리 블록을 얻기 위해 블록 멥핑기술을 이용함. 그 다음 물리 블록 내에 있는 빈 섹터를 찾기 위해 섹터 멥핑기술을 이용 멥핑 테이블을 재구성 하는 경우에는 이 정보뿐만이 아니라 논리 블록 번호 또한 물리 블록의 스페어 영역에 기록 되어야만 함 플래시 메모리에서 자료를 읽을 때, 주어진 논리 섹터 번호를 이용하여 멥핑 테이블에서 물리 블록 번호를 찾음. 그런 다음 물리 블록의 스페어 영역에서 논리 섹터 번호를 읽어 원하는 자료의 가장 최근 값을 얻을 수 있음 혼합 맵핑은 섹터 맵핑과 블록 맵핑을 혼합하여 사용하는 것으로서 RAM의 크기는 섹터 맵핑과 블록 맵핑의 사이 값을 가지게 된다. 혼합 맵핑은 또한 섹터 맵핑과 블록 맵핑의 장단점을 모두 가지고 있게 된다.

18 윈도우즈 의 I/O Application User Mode Kernel Mode IRP Communication
File System (NTFS , FAT32 , FAT 등) IRP Communication I/O Manager IRP Communication Disk Driver IRP Communication Disk

19 윈도우즈 의 I/O (cont) 사용자 프로그램 에서 read 혹은 write의 시스템 호출을 통해 커널의 I/O 관리자에게 디스크 I/O를 요청하게 됨 커널 내에 있는 I/O 관리자가 요청을 받아들여 IRP(I/O Request Packet)로 파일 시스템 드라이버 에게 요청하게 됨 파일 시스템 드라이버는 논리 수준에서의 섹터 번호, 길이, 자료지시자를 연산해 디스크 드라이버에게 IRP를 전달함 디스크 드라이버는 IRP를 받아 물리 수준에서의 섹터 번호, 길이, 자료지시자로 IRP를 만들어 실제로 어떤 장치(Device)에게 전달되어야 하는 IRP인지를 보고 해당 물리 디스크에게 전송 윈도우즈 의 I/O의 흐름을 보겠다. 처음 사용자 모드에서의 프로그램이 read나 write의 시스템 호출을 통해서 커널의 I/O 관리자에게 I/O 요청을 하게 된다. I/O 관리자는 요청을 받아들여 IRP(I/O Request Packet)을 만들어 파일 시스템에게 IRP를 전달하게 된다. 이때 I/O 관리자는 해당 I/O 요청의 최종 목적지까지 생각해서 IRP를 작성하게 되고, IRP는 꼬리부(Stack)에 각 계층들이 수행해야 할 정보들을 저장하고 있게 된다. 이렇게 전달된 IRP는 파일 시스템에서 논리수준에서의 섹터 번호, 길이, 자료지시자를 연산해 디스크 드라이버에게 IRP를 재구성하여 전달하게 되고, 디스크 드라이버는 IRP를 받아 물리 수준에서의 섹터 번호, 길이, 자료지시자로 IRP를 재구성해 실제로 어떤 장치(Device)에게 전달되어야 하는 IRP인지를 보고 해당 물리 디스크에게 전송하게 된다.

20 IRP 통신 IRP Header Itatus I/O Manager 참조 Stack File System 참조 Locations
Disk Driver 참조 Disk 그렇다면 IRP는 어떻게 동작하는 것인지 알아보자. IRP는 크게 두부분으로 나누어 볼 수 있다. 머리부(Header)와 꼬리부(Stack Locations)이다. 머리부에서는 해당 IRP에 대한 정보와 상태를 저장하게 되고, 꼬리부에서는 각 계층마다 해야 할 루틴들이 저장되어 있다. 각 계층들은 IRP를 전달받아 꼬리부에서 자신들이 참조해야 할 부분을 참조하여 수행한다.

21 IRP 통신 IRP (I/O Request Packet)
I/O 요청을 하기 위한 객체간에 통신 수단으로서 패킷(Packet)의 특징인 머리부(Header)와 꼬리부(Stack Location)가 존재 머리부 현재 IRP의 상태 정보 저장 I/O 할 Buffer의 지시자를 가지고 있음 꼬리부 해당 객체가 수행해야 할 주함수(Major Function), 부함수(Minor Function), 인자(Parameter)가 있음 IRP가 객체들에게 전달이 되면서 각 객체들은 IRP를 보고 해야 할 일들을 수행

22 윈도우즈 드라이버 작성법 DDK (Device Development Kit)를 이용하여 드라이버를 작성
NTDDK.h 안에 모든 기술이 되어있음 자료형(Data Type), 구조체(Structure), 상수(Constant Value), 메크로(Macro) 등등 윈도우즈 는 범세계적인 이기에 Unicode 문자열을 사용 IRP를 작성 드라이버가 전송 받았을 때 수행할 루틴(Routines)를 작성해주어 드라이버를 만듬 DriverEntry Routine : 드라이버 코드의 시작점 Initialization Routine : 초기화 루틴 AddDevice Routine : 드라이버가 부착 시에 동작 할 루틴 Unload Routine : 드라이버를 해제 시에 동작 할 루틴 윈도우즈 드라이버는 DDK (Device Development Kit)을 이용하여 작성할 수 있다. 사용할 수 있는 자료형, 구조체, 상수, 메크로 등은 모두 NTDDK.h라는 헤더 파일에 기술되어 있다. 드라이버의 작성시 주의 해야 할 사항 중 하나는, 커널 프로그래밍을 하는 것이기에 잘못하면 를 망치는 결과를 초래하기에 신중을 기해야만 한다는 것이다. 또, 윈도우즈 는 범세계적인 이기에 Unicode 문자열을 사용해야 함을 주의 해야 한다. 드라이버는 IRP를 받았을 때 수행해야 할 루틴들을 작성해 주어야만 한다. 대표적인 루틴들은 꼭 알아야 할 필요가 있다. DriverEntry Routine : 드라이버 코드의 시작점 Initialization Routine : 초기화 루틴 AddDevice Routine : 드라이버가 부착 시에 동작 할 루틴 Unload Routine : 드라이버를 해제 시에 동작 할 루틴

23 계층 드라이버(Layered Driver)
계층 드라이버란? 드라이버를 계층 단위로 하는 일을 나누어 드라이버를 작성한 것 필터(Filter) 드라이버가 계층 드라이버라 할 수 있음 필터 (Filter) 드라이버의 투명성 마치 스니핑(sniffing)하듯이 IRP를 처리함 상위 드라이버나 하위 드라이버는 인식하지 못함 때문에 하위 드라이버가 지원하는 루틴을 모두 제공해주어야 함 하위 Level Driver 상위 Level Driver or Client Filter Driver 하위 Driver와 통신한다고 생각함 원하는 작업을 한뒤에 IRP 전달 IRP를 받아 원하는 작업후 처리한 IRP를 상위 Driver로 상위 Driver 에게 IRP가 온것으로 인식 하위 Driver가 IRP를 반환한 것으로 인식 드라이버는 계층적으로 나누어 작성할 수 있다. 한 드라이버가 해야 할 일들이 많거나, 개념적으로 다른 일을 수행 해야 한다거나 하면, 계층 드라이버로 나누어 작성 할 수 있다. 필터(Filter) 드라이버는 계층 드라이버의 한 예로서 마치 스니핑(sniffing)하듯 상위 계층 드라이버에서 내려온 IRP를 참조한 뒤 하위 계층 드라이버에게 전달해 준다. 예를 들어 한번에 4K씩 I/O를 수행하는 장치가 있다면 계층 드라이버를 통해 100K씩 I/O를 수행해주는 계층 드라이버를 작성할 수 있다.

24 실험 내용

25 Filter 드라이버를 이용한 Diskiomo 드라이버
Diskiomo 드라이버 (Disk I/O Monitoring Driver) 디스크 드라이버의 하위 필터 드라이버로서 물리 디스크에게 전송되는 IRP 탐색을 통해 섹터번호와 길이만을 스니핑을 통해 얻어 옴 얻은 섹터번호와 길이를 다른 디스크에 “diskio.log”로 저장 “diskio.log”를 통해 사용자 모드(User Mode)에서 FTL 알고리즘을 실험 할 수 있음 탐색한 뒤의 IRP는 그대로 물리 디스크에게 전송해 줌 Disk Driver IRP Communication diskiomo Driver Disk 우리는 디스크로 가는 I/O를 분석하기 위해 I/O를 빼내어 오는 드라이버를 작성하였다. 이 드라이버의 이름은 Diskiomo(Disk I/O Monitoring Driver)로서 디스크 드라이버의 하위 계층 드라이버로 작성하여 실제 디스크로 가는 IRP를 스니핑(Sniffing)하는 방법으로 I/O 패턴을 얻어 낼 수 있었다. 그림에서 보듯이 디스크 드라이버와 실제 물리 디스크 사이에 Diskiomo 드라이버를 부착시켰으며, 이때 얻어진 정보들은 “diskio.log”라는 파일로 다른 디스크에 저장을 시켜주었다.

26 실험 환경 Disk Driver diskiomo Driver LogFileReader File write File read
FTL_Alg Disk diskio.log File Virtual 플래시 메모리 우리가 실험한 구조를 보면 Diskiomo 드라이버는 얻은 정보를 물리적으로 다른 디스크에 “diskio.log”라는 파일로 저장을 하게 된다. 이때 우리가 작성한 실험 프로그램은 “diskio.log”라는 파일에서 로그 정보를 읽어와 사용자 모드에서 작성된 FTL 알고리즘에 적용시켜 가상으로 만든 플래시 메모리를 이용해 실험을 하게 된다. 실험 프로그램은 얻은 정보를 FTL 알고리즘에 적용시킴으로 해서 얻은 각종 통계 정보등을 기록해 FTL 알고리즘의 성능을 실시간으로 평가 하게 된다.

27 실험 환경(cont) diskiomo.sys 필터 드라이버는 Disk.sys 에서 받은 IRP를 탐색해 I/O에 대한 정보를 얻어냄 Read인지 Write인지 섹터번호 길이 Drive C에 “diskio.log”라는 파일을 생성해 이곳에 이진 타입(Binary Type)으로 계속 저장 시뮬레이션 프로그램은 Drive C에 “diskio.log” 파일을 탐색하다가 변화가 있으면 계속 읽어 연산을 수행 (실시간)

28 Diskiomo 드라이버 실험 환경 VMWare를 사용하여 윈도우즈 2000 Professional Version에 SCSI 하드 드스크(Hard Disk) 두 개를 생성 시스템 디스크(System Disk : Drive C) “diskio.log” 파일로 E Drive에 발생한 I/O 저장 잉여 디스크(Extra Disk : Drive E) 100 메가바이트(Mbytes) 의 크기 diskiomo.sys (하위 필터 드라이버)를 부착 Drive E에 파일 복사와 삭제 연산을 통해 강제로 I/O 발생 실험 프로그램을 작성해 Drive C에 있는 “diskio.log”에서 계속 로그(Log) 기록을 읽어 들임 diskiomo.sys 드라이버가 부착되지 않은 곳에 “diskio.log” 파일을 생성해야 하는 이유 “diskio.log”로 기록하라는 I/O 자체도 “diskio.log”에 기록하려 하려는 것을 방지하기 위함 우리가 실험한 환경은 효율적인 실험을 위해 VMWare라는 버추얼 머신(Virtual Machine)을 사용하였고, 이때 사용한 는 윈도우즈 2000 Professional Version을 사용하였다. I/O 로그 정보를 저장할 디스크로 시스템 디스크 (Drive C)를 사용해 “diskio.log”파일을 저장하였고, I/O 요청을 발생시키기 위해 잉여 디스크(Drive E)를 100메가 바이트(Mbytes)로 만들었다. 잉여 디스크에는 diskiomo 드라이버가 부착되어 I/O를 빼내어 오게 된다. 잉여 디스크에 JPG, MP3 그리고 혼합한 피일들을 강제로 복사와 삭제 연산을 수행시켰다. JPG는 200K~400K정도의 작은 파일들이기에 작은 길이의 순차 Log가 발생을 하게 된다. MP3는 3M~4M정도의 비교적 큰 파일들이기에 긴 길이의 순차 Log가 발생을 하게 된다. 혼합된 파일들은 다중 프로세스가 접근을 하게 하여 다량의 분할 I/O (Fragmentation) 이 발생하게 되어 임의(Random)의 섹터접근이 Log에 나타나게 된다. 또한 DB(DataBase)에서 쿼리(Query)를 발생시킬때의 Log도 실험을 하였다. JPG : 작은 길이의 순차 I/O MP3 : 긴 길이의 순차 I/O 혼합 : 아주 작은 길이의 임의의 I/O DB : 쿼리에 따른 I/O

29 실험 환경 윈도우즈 2000 Professional 파일시스템 FAT , NTFS 사용 디스크
Drive C : “diskio.log” 파일 저장 Drive E : diskiomo 드라이버를 부착 Drive E 크기 100 Mbytes 발생 I/O의 크기 130 Mbytes 정도의 자료를 이용해 약 3.5 Gbytes 정도의 I/O를 발생시킴

30 I/O 발생 패턴 JPG 200k~400k의 작은 크기의 파일 MP3 3M~5M의 큰 크기의 파일 혼합
JPG와 MP3를 혼합하여 다중 프로세스를 통해 다량의 분할(Fragmentation)발생 Database TPC-H 벤치마크 테스트

31 실험 환경 구조도 File Copy & Delete Program Simulating Program User Mode
Kernel Mode 수행 Disk Driver diskio.log에서 Log를 읽어서 수행 diskiomo Driver 실험 환경에 대한 구조를 보게 되면 우리가 작성한 파일 복사와 삭제를 수행하는 사용자 프로그램이 diskiomo 드라이버가 부착된 Drive E에 강제로 I/O를 발생시킨다. 이때 diskiomo 드라이버는 이에 따른 Log 를 만들어 Drive C에 “diskio.log”라는 파일에 기록을 하게 되고, 우리가 작성한 실험 프로그램은 사용자 모드에서 Drive C에 있는 “diskio.log”라는 파일에서 Log를 실시간으로 읽게 된다. 실험 프로그램은 Log를 FTL 알고리즘에 적용해 각종 정보를 얻어내고 통계치 등을 계산해 FTL 알고리즘의 성능을 평가 할 수 있다. Drive C Drive E diskio.log

32 diskio.log Structure 실험 할 때 실제로 필요한 정보만을 얻기 위한 구조체 #define READ 'r'
#define WRITE 'w' class Log { public: char RorW; // Read인지 Write인지 [1 Byte] int start; // Start Sector Number [4 Bytes] int length; // 연산할 Sector 길이 [4 Bytes] Log() RorW = ' '; start = 0; length = 0; } ~Log() {} }; 실험 할 때 실제로 필요한 정보만을 얻기 위한 구조체 그렇다면 “diskio.log” 파일에는 Log가 어떻게 기록이 되는지 알아 보자. 먼저 지금의 I/O가 읽기연산인지 쓰기 연산인지를 구분하여 기록해주어야 한다. 이것을 1바이트로 ‘r’ 과 ‘w’로 기록하였고, 연산의 시작 섹터 번호를 4바이트로, 길이를 4바이트로 기록을 하였다. 이때 실제 자료의 지시자는 기록을 하지 않았는데, 이는 실험시에 실제 자료가 저장되는 모습을 보는 것이 아니라, 단지 어떤식으로 맵핑이 되어 읽기, 쓰기 와 삭제 연산이 일어나는지 만을 알아보기 위해서 이다.

33 실험 결과

34 diskiomo.sys의 부착 모습 Filter Driver Load Order v1.0.005 실행 Drive E
Diskperf Driver PartMgr Driver Disk Driver Filter Driver Load Order 라는 프로그램은 앞에서 설명한 계층 드라이버의 일종은 필터 드라이버의 부착 여부를 보여주는 프로그램이다. 그림에서 보듯이 왼쪽에 Drive C와 Drive E가 보인다. 이때 실제 diskiomo 드라이버를 부착시킨 드라이버는 Drive E이고 오른쪽에 보면 실제 SCSI Drive로 E가 있으며 그 밑에 diskiomo 드라이버가 부착되어 있는 모습이 보인다. diskiomo Driver

35 Layered 드라이버의 Tree 구조 Device Tree V2.10 실행 Diskperf Driver
PartMgr Driver Disk Driver diskiomo Driver Device Tree라는 프로그램은 장치가 부착되어 있는 모습을 트리(Tree)구조로 계층적으로 보여주는 프로그램이다. 그림에서 보듯이 제일 상위에 Diskperf 드라이버, 그 밑에 PartMgr 드라이버, Disk 드라이버, 그 밑에 diskiomo 드라이버가 부착된 모습이 보인다.

36 실험 프로그램의 동작 모습 그림에서 보면, 왼쪽에 실험 프로그램이 동작하고 있다. 오른쪽에서는 강제로 복사,삭제 I/O를 발생 시키는 프로그램이 다중 프로세스로 동작하고 있다. 실시간으로 Log를 읽어 실험 프로그램은 통계치 및 현재 결과를 보여주고 있다. 실험 프로그램에서 보여주는 정보를 알아보자 1.Log 파일 정보 실험 날짜, 실험 환경, Memo 2.FTL 알고리즘 정보 알고리즘 이름, 특이사항, RAM 사용 크기 3.플래시 메모리 정보 플래시 메모리 이름 , 섹터 크기, 스페어 크기 , 페이지 크기 , 블록 당 섹터 수 , 총 블록 개수 , 총 메모리 크기 4.파일 시스템 정보 읽기 쓰기 비율 5. 물리 블록 삭제 정보 총 삭제 연산 횟수, 최대 삭제 횟수, 최소 삭제 횟수, 차이값, 평균 , 표준편차 6. 플래시 메모리 에러 확률 읽기, 쓰기, 삭제 오류 확률 7. 사용 블록 수 전체 블록 중 사용 블록 수

37 실험 프로그램 정보 Log 파일 정보 실험 날짜, 실험 환경, Memo FTL 알고리즘 정보
알고리즘 이름, 특이사항, RAM 사용 크기 플래시 메모리 정보 플래시 메모리 이름 , 섹터 크기, 스페어 크기 , 페이지 크기 , 블록 당 섹터 수 , 총 블록 개수 , 총 메모리 크기 파일 시스템 Log 정보 읽기 쓰기 비율 플래시 메모리 연산 정보 한 I/O 당 실제 플래시 메모리 읽기, 쓰기, 삭제 연산 호출 횟수 물리 블록 삭제 정보 총 삭제 연산 횟수, 최대 삭제 횟수, 최소 삭제 횟수, 차이값, 평균 , 표준편차 플래시 메모리 에러 확률 읽기, 쓰기, 삭제 오류 확률 사용 블록 수 전체 블록 중 사용중인 블록 수