DBPIA-NURIMEDIA

Similar documents
6.24-9년 6월

Microsoft PowerPoint - o8.pptx

<4D F736F F F696E74202D20BCD2C7C1C6AEBFFEBEEEC6AFB7D03038B3E22E BC8A3C8AF20B8F0B5E55D>

경우 1) 80GB( 원본 ) => 2TB( 복사본 ), 원본 80GB 는 MBR 로디스크초기화하고 NTFS 로포맷한경우 복사본 HDD 도 MBR 로디스크초기화되고 80GB 만큼포맷되고나머지영역 (80GB~ 나머지부분 ) 은할당되지않음 으로나온다. A. Window P

Microsoft PowerPoint - 알고리즘_1주차_2차시.pptx

공개특허 (51) Int. Cl. G06F 12/08 ( ) (19) 대한민국특허청 (KR) (12) 공개특허공보 (A) (11) 공개번호 (43) 공개일자 년 07 월 02 일 (21) 출원

PowerPoint 프레젠테이션

(72) 발명자 이동희 서울 동작구 여의대방로44길 10, 101동 802호 (대 방동, 대림아파트) 노삼혁 서울 중구 정동길 21-31, B동 404호 (정동, 정동상 림원) 이 발명을 지원한 국가연구개발사업 과제고유번호 부처명 교육과학기술부

청구항 1. 소정데이터를저장하는비휘발성메모리 ; 상기비휘발성메모리를구비한휴대용장치의전원상태를체크하는전원상태체크부 ; 및 상기체크된전원상태를기초로상기비휘발성메모리에할당된물리블록을회수하는블록회수부를포함하는전원상태에따라비휘발성메모리의블록회수를수행하는장치. 청구항 2. 제 1

DBPIA-NURIMEDIA

±èÇö¿í Ãâ·Â

FMX M JPG 15MB 320x240 30fps, 160Kbps 11MB View operation,, seek seek Random Access Average Read Sequential Read 12 FMX () 2

API 매뉴얼

<4D F736F F F696E74202D C61645FB3EDB8AEC7D5BCBA20B9D720C5F8BBE7BFEBB9FD2E BC8A3C8AF20B8F0B5E55D>

[ 컴퓨터시스템 ] 3 주차 1 차시. 디렉토리사이의이동 3 주차 1 차시디렉토리사이의이동 학습목표 1. pwd 명령을사용하여현재디렉토리를확인할수있다. 2. cd 명령을사용하여다른디렉토리로이동할수있다. 3. ls 명령을사용하여디렉토리내의파일목록을옵션에따라다양하게확인할수

DBPIA-NURIMEDIA

슬라이드 1

Microsoft PowerPoint - 30.ppt [호환 모드]

이도경, 최덕재 Dokyeong Lee, Deokjai Choi 1. 서론


Microsoft Word - 산업분석리포트 doc

[Brochure] KOR_TunA

DE1-SoC Board

Windows Server 2012

김기남_ATDC2016_160620_[키노트].key

2) 활동하기 활동개요 활동과정 [ 예제 10-1]main.xml 1 <LinearLayout xmlns:android=" 2 xmlns:tools="

1217 WebTrafMon II

MPEG-4 Visual & 응용 장의선 삼성종합기술원멀티미디어랩

금오공대 컴퓨터공학전공 강의자료

Microsoft PowerPoint - Flash Memory Based Bottom Up Analysis for Smart Phone System _Final [호환 모드]

<333820B1E8C8AFBFEB2D5A B8A620C0CCBFEBC7D120BDC7BFDC20C0A7C4A1C3DFC1A42E687770>

DBPIA-NURIMEDIA

특징 찾아보기 열쇠 없이 문을 열 수 있어요! 비밀번호 및 RF카드로도 문을 열 수 있습니다. 또한 비밀번호가 외부인에게 알려질 위험에 대비, 통제번호까지 입력해 둘 수 있어 더욱 안심하고 사용할 수 있습니다. 나만의 비밀번호 및 RF카드를 가질 수 있어요! 다수의 가

À¯Çõ Ãâ·Â

Microsoft PowerPoint - 알고리즘_5주차_1차시.pptx

Microsoft PowerPoint - 알고리즘_2주차_1차시.pptx

05( ) CPLV12-04.hwp

Microsoft PowerPoint 자동설치시스템검증-V05-Baul.pptx

DBPIA-NURIMEDIA

<3132BFF93136C0CFC0DA2E687770>

<BBEABEF7B5BFC7E22DA5B12E687770>


Camel_C

이발명을지원한국가연구개발사업 과제고유번호 부처명 미래창조부 연구관리전문기관 한국산업기술평가관리원 연구사업명 산업융합원천기술개발 연구과제명 단일노드 48TB 이상을지원하는개방형하둡스토리지어플라이언스 (Hadoop Storage Appliance) 개발 기

초보자를 위한 분산 캐시 활용 전략

슬라이드 1

Windows 10 General Announcement v1.0-KO

Microsoft PowerPoint - 02_Linux_Fedora_Core_8_Vmware_Installation [호환 모드]

°í¼®ÁÖ Ãâ·Â

04서종철fig.6(121~131)ok

DBPIA-NURIMEDIA

슬라이드 1

이 장에서 사용되는 MATLAB 명령어들은 비교적 복잡하므로 MATLAB 창에서 명령어를 직접 입력하지 않고 확장자가 m 인 text 파일을 작성하여 실행을 한다

미래 서비스를 위한 스마트 클라우드 모델 수동적으로 웹에 접속을 해야만 요구에 맞는 서비스를 받을 수 있었다. 수동적인 아닌 사용자의 상황에 필요한 정보를 지능적으로 파악 하여 그에 맞는 적합한 서비스 를 제공할 수 새로운 연구 개발이 요구 되고 있다. 이를 위하여,

7장. 교착상태(deadlock)

untitled

Microsoft PowerPoint - [#4-2] File System Forensic Analysis.pptx

Microsoft Word - Armjtag_문서1.doc

리뉴얼 xtremI 최종 softcopy

Microsoft Word - 1-차우창.doc

0125_ 워크샵 발표자료_완성.key

알람음을 출력하는 이동통신 단말기에 있어서, 실시간 알람음을 출력하는 음향 출력 수단; 디지털 멀티미디어 방송(DMB: Digital Multimedia Broadcasting, 이하 'DMB'라 칭함) 신호를 수신하면 오디오 형태로 변 환하여 DMB의 음향을 전달하는

KDTÁ¾ÇÕ-2-07/03

아이콘의 정의 본 사용자 설명서에서는 다음 아이콘을 사용합니다. 참고 참고는 발생할 수 있는 상황에 대처하는 방법을 알려 주거나 다른 기능과 함께 작동하는 방법에 대한 요령을 제공합니다. 상표 Brother 로고는 Brother Industries, Ltd.의 등록 상

PowerPoint 프레젠테이션


HTML5* Web Development to the next level HTML5 ~= HTML + CSS + JS API

, N-. N- DLNA(Digital Living Network Alliance).,. DLNA DLNA. DLNA,, UPnP, IPv4, HTTP DLNA. DLNA, DLNA [1]. DLNA DLNA DLNA., [2]. DLNA UPnP. DLNA DLNA.

H3250_Wi-Fi_E.book

Microsoft Word - ntasFrameBuilderInstallGuide2.5.doc

C# Programming Guide - Types

PowerPoint 프레젠테이션

-. Data Field 의, 개수, data 등으로구성되며, 각 에따라구성이달라집니다. -. Data 모든 의 data는 2byte로구성됩니다. Data Type는 Integer, Float형에따라다르게처리됩니다. ( 부호가없는 data 0~65535 까지부호가있는

ePapyrus PDF Document

Voice Portal using Oracle 9i AS Wireless

Microsoft Word - windows server 2003 수동설치_non pro support_.doc

PowerPoint 프레젠테이션

Microsoft Word - FunctionCall

다음 사항을 꼭 확인하세요! 도움말 안내 - 본 도움말에는 iodd2511 조작방법 및 활용법이 적혀 있습니다. - 본 제품 사용 전에 안전을 위한 주의사항 을 반드시 숙지하십시오. - 문제가 발생하면 문제해결 을 참조하십시오. 중요한 Data 는 항상 백업 하십시오.

..,. Job Flow,. PC,.., (Drag & Drop),.,. PC,, Windows PC Mac,.,.,. NAS(Network Attached Storage),,,., Amazon Web Services*.,, (redundancy), SSL.,. * A

1

TTA Journal No.157_서체변경.indd

<3132BFF93136C0CFC0DA2E687770>

Microsoft Word _LT_리눅스 마운트강좌 mount 1편.doc

등록특허 (51) Int. Cl. G06F 12/00 ( ) (19) 대한민국특허청 (KR) (12) 등록특허공보 (B1) (45) 공고일자 (11) 등록번호 (24) 등록일자 2007 년 04 월 12 일 년

Microsoft Word - [2017SMA][T8]OOPT_Stage_2040 ver2.docx

슬라이드 제목 없음

KDTÁ¾ÇÕ-1-07/03

네이버블로그 :: 포스트내용 Print VMw are 에서 Linux 설치하기 (Centos 6.3, 리눅스 ) Linux 2013/02/23 22:52 /carrena/ VMware 에서 l

IP 심화 라우팅프로토콜적용시 라우팅테이블에서 이니셜이있는네트워크를설정하는것 : onnected 직접연결된네트워크를의미한다. 그러므로라우팅은 나는이런네트워크와연결되어있다. 를직접연결된라우터들에게알려주는것 1>en 1#conf t 1(config)#router rip 1

DBPIA-NURIMEDIA

À±½Â¿í Ãâ·Â

Windows Embedded Compact 2013 [그림 1]은 Windows CE 로 알려진 Microsoft의 Windows Embedded Compact OS의 history를 보여주고 있다. [표 1] 은 각 Windows CE 버전들의 주요 특징들을 담고

DBPIA-NURIMEDIA

View Licenses and Services (customer)

08SW

SchoolNet튜토리얼.PDF

User Guide

청구항 1. 주저장매체 ; 상기주저장매체의캐쉬로사용되며, 데이터의고정여부에따라고정영역및비고정영역을포함하는비휘발성메모리 ; 및 상기비휘발성메모리에할당되는블록을관리하는블록관리부를포함하는비휘발성메모리가캐쉬로사용되는저장장치. 청구항 2. 제 1 항에있어서, 상기블록관리부는,

Chapter ...

Transcription:

MNFS: NAND 플래시메모리를기반으로하는모바일멀티미디어파일시스템의설계 497 MNFS: NAND 플래시메모리를기반으로하는모바일멀티미디어파일시스템의설계 (MNFS: Design of Mobile Multimedia File System based on NAND FLASH Memory) 김효준 원유집 김요환 (Hyojin Kim) (Youjip Won) (Yohwan Kim) 요약본연구는 NAND 플래시메모리를기반으로하는모바일멀티미디어파일시스템 (MNFS) 에관한내용이다. 이연구에서제안하는파일시스템은기존범용플래시파일시스템과는달리 MP3 플레이어, PMP, 디지털캠코더등과같은모바일멀티미디어장치에서최적의성능을보장하기위하여설계된파일시스템이다. MNFS 는크게세가지의특징을갖는데, 첫째파일시스템의순차적인쓰기요청에대해균일한응답시간을보장하고, 둘째파일시스템마운트시간이빠르며, 셋째최소한의메모리만을소모한다. 이를위해 4 가지새로운기법들을사용한다. 파일시스템메타데이타와사용자데이타를서로다른맵핑기법으로관리하는혼합맵핑기법과, 파일데이타할당단위를 NAND 플래시메모리의블록단위로사용한블록단위사용자데이타할당, 메타데이타를최소화하기위한 ibat, 그리고상향식디렉토리표현기법이다. 프로토타입 MNFS 를 ARM9 프로세서와 1G 비트용량의 NAND 플래시메모리환경에서구현하고성능을측정한다. 기존의 NAND 플래시파일시스템인 YAFFS 와 FTL 을사용하는 FAT 파일시스템과비교하였으며, 순차적쓰기요청에대해빠르고균일한응답시간을확인할수있다. 또, 같은조건에서 YAFFS 에비해 30 배빠른마운트시간을보였고, Heap 메모리도 YAFFS 의 5% 밖에소모하지않았다. 키워드 :NAND 플래시메모리, 파일시스템, 모바일, 멀티미디어, 실시간 Abstract Mobile Multimedia File System, MNFS, is a file system which extensively exploits NAND FLASH Memory. Since general Flash file systems does not precisely meet the criteria of mobile devices such as MP3 Player, PMP, Digital Camcorder, MNFS is designed to guarantee the optimal performance of FLASH Memory file system. Among many features MNFS provides, there are three distinguishable characteristics. MNFS guarantees, first, constant response time in sequential write requests of the file system, second, fast file system mounting time, and lastly least memory footprint. MNFS implements four schemes to provide such features. Hybrid mapping scheme to map file system metadata and user data, manipulation of user data allocation to fit allocation unit of file data into allocation unit of NAND FLASH Memory, ibat (in-core only Block Allocation Table) to minimize the metadata, and bottom-up representation of directory. Prototype implementation of MNFS was tested and measured its performance on ARM9 processor and 1Gbit NAND FLASH Memory environment. Its performance was compared with YAFFS, NAND FLASH File system, and FAT file system which use FTL. This enables to observe constant request time for sequential write request. It shows 30 times faster mounting time to YAFFS, and reduces 95% of HEAP memory consumption compared to YAFFS. Key words :NAND Flash Memory, File System, Mobile Device, Multimedia, real time 비회원 : 종신회원 : 비회원 : 논문접수 : 심사완료 : 삼성전자기술총괄소프트웨어연구소선임연구원 zartoven@samsung.com 한양대학교전자컴퓨터통신공학과교수 yjwon@ece.hanyang.ac.kr 한양대학교전자컴퓨터통신공학과 yohwan82@ece.hanyang.ac.kr 2007년 10월 15일 2008년 10월 15일 Copyright@2008 한국정보과학회ː개인목적이나교육목적인경우, 이저작물의전체또는일부에대한복사본혹은디지털사본의제작을허가합니다. 이때, 사본은상업적수단으로사용할수없으며첫페이지에본문구와출처를반드시명시해야합니다. 이외의목적으로복제, 배포, 출판, 전송등모든유형의사용행위를하는경우에대하여는사전에허가를얻고비용을지불해야합니다. 정보과학회논문지 : 시스템및이론제35권제11호 (2008.12)

498 정보과학회논문지 : 시스템및이론제 35 권제 11 호 (2008.12) 1. 서론최근의모바일제품의가장큰특징은멀티미디어기능의확장이다. MP3플레이어는더이상벤처기업의아이디어상품이아니라대기업의주력업종이되었고, 대부분의필름카메라가디지털카메라로대치되었다. 또한, PMP(Portable Media Player) 를사용함으로써고화질의멀티미디어를언제어디서든감상할수있다. 또, 휴대폰에는카메라기능과 MP3 플레이어기능, 그리고디지털캠코더기능까지장착되고있으며심지어음악을듣거나동영상을감상할수있는전자사전까지개발되었다. 멀티미디어기능이휴대제품에채택됨에따라휴대용저장장치의중요성이더해졌다. 사용자들은큰용량의멀티미디어데이타를휴대하길원하고, 이를위해서는휴대하기에적합한저장장치가필요하다. 휴대장치에적합한저장장치는휴대제품에알맞은크기와, 배터리를고려한낮은전력소모 [1] 와, 물리적인충격에안전해야한다. 최근모바일제품의멀티미디어화트랜드의가장큰수혜자는조건들을가장잘만족시킬수있는 NAND 플래시메모리며, 그에따라관련기술에대한요구사항도크게증대하고있다. 본논문에서는모바일멀티미디어제품의요구사항에맞추어 MNFS (Implementation of Mobile Multimedia File System based on NAND FLASH Memory) 를제안한다. MNFS는모바일장치의스토리지로널리사용되고있는 NAND 플래시메모리를기반으로최적의성능과실시간응답을제공하면서도적은자원을소모하도록설계된파일시스템이다. 기존멀티미디어파일시스템이주로하드디스크기반스트리밍서버에서요구되는다중프로세스의읽기성능보장을목표로한다면, MNFS는모바일멀티미디어기기에서단일프로세스의주기적인쓰기요청에대해일정한쓰기응답시간을보장하는것을목표로한다. 또갑작스런전원차단에대한안정성을제공하며, 최소의코드와데이타만을사용하도록설계한다. 본논문의구성은다음과같다. 3장에서는 MNFS의설계에대해설명하고, 4장에서는 MNFS, YAFFS, FAT파일시스템의비교실험을통해성능을보이고, 마지막 5장에서는결론을맺는다. 2. 관련연구기존멀티미디어파일시스템연구의대상은멀티미디어데이타를스트리밍하는서버였다. 하드디스크는자기식으로데이타를읽고쓰기때문에읽기속도와쓰기속도가같다. 읽기작업과쓰기작업의비용이같을때, 병목현상이발생할곳은읽기작업이다. 여러개의멀티미디어데이타를동시에저장하는일은흔하지않지만, 여러개의멀티미디어데이타를동시에읽는일은빈번히발생하기때문이다. 즉, 기존하드디스크기반의멀티미디어파일시스템은여러개의프로세스가요청하는멀티미디어파일의읽기요청들을어떻게효율성있게처리할것인지가목표이다. 플래시메모리의특성은하드디스크와다르다. 쓰기작업일경우는읽기작업보다복잡하고시간도오래걸린다. 시간적으로플래시메모리의쓰기작업은하드디스크에비해서느린반면플래시메모리의읽기속도는하드디스크보다더빠르거나같다. 이러한저장미디어의특성차이는기존하드디스크를기반의멀티미디어파일시스템과플래시메모리를기반의모바일멀티미디어파일시스템간의중요한차이점이다. 또모바일멀티미디어기기에서여러개프로세스에의한다중입출력요구가거의일어나지않는다는점또한기존연구와의차이점이다. 이러한특성때문에플래시메모리를기반으로하는모바일멀티미디어파일시스템에서는단일프로세스의단일스트리밍에대한쓰기요청을어떻게안정적으로처리할것인가가가장중요한연구목적이된다. 모바일멀티미디어제품들에가장널리사용되고있는저장장치는 NAND 플래시메모리이다. NAND 플래시메모리는전력소모가작고충격에강하며소형화가가능한장점이있는반면에, 자기저장장치인하드디스크와달리섹터단위갱신이불가능한단점이있다 [2-4]. 즉, 쓰기작업이전에지우기작업이선행되어있어야한다는것과, 읽기 / 쓰기작업의단위보다지우기작업의단위가훨씬크다는것이다. NAND 플래시메모리의경우읽기 / 쓰기작업은 512바이트혹은 2048바이트크기를가지는페이지단위로이뤄지고, 지우기작업은이러한페이지들이여러개모인블록단위로이뤄진다. NAND 플래시메모리는용량에따라여러개의블록으로구성이된다. 하나의블록은 32개의페이지로이뤄져있으며, 하나의페이지는다시내부적으로 512바이트의메인영역과 16바이트의스페어영역으로구성된다 [2]. NAND 플래시메모리에서읽기 / 쓰기작업은페이지단위로이뤄지며, 하나의페이지에대해서메인영역과스페어영역에대해서각각읽고쓰거나혹은한번에읽고쓸수있다. 메인영역은사용자데이타를저장하기위한공간이며, 스페어영역은특별한목적으로사용하는예비공간이다 [2]. 스페어영역은대표적으로메인영역에대한오류정정코드 (ECC) 를보관하거나베드블록마크를보관한다. NAND 플래시메모리의용량을말할때에는스페어영역은포함시키지않는다. 예를들어 32개의페이지로구성된블록하나의용량은 16 Kbytes

MNFS: NAND 플래시메모리를기반으로하는모바일멀티미디어파일시스템의설계 499 이고, 128MBytes용량인 NAND 플래시메모리에는총 8,192개의블록이존재한다. 한편, 현재모바일제품에가장널리사용되고있는 FAT파일시스템은 [5] 하드디스크나플로피디스크와같은자기저장장치를위해설계된파일시스템으로서앞서언급한독특한특성을갖는 NAND 플래시메모리에는직접사용할수없다. 이런문제를해결하기위해사용하는소프트웨어가 FTL(Flash Translation Layer) 이다 [6]. FTL은파일시스템과플래시메모리의중간에위치하여플래시메모리가마치하드디스크처럼보이도록하는역할을한다. 즉, 논리섹터에대한쓰기요청을쓰기가능한물리섹터에처리하고그맵핑정보를따로관리하는방법으로 [7], 플래시메모리가마치섹터단위의갱신이가능한것처럼보이도록한다. 그렇기때문에 FTL을사용하면 FAT파일시스템과같은기존하드디스크용파일시스템을플래시메모리상에서사용할수있게된다. 하지만 FAT파일시스템과 FTL을사용하는시스템에는몇가지문제가있다. 첫째, 파일시스템과 FTL의분리된레이어를통해작업이이뤄지기때문에최상의성능을얻기힘든문제가있다. NAND 플래시메모리의성능향상이이뤄지고있지만모바일제품에사용되는멀티미디어데이타의정보량도또한급속히증가하고있다는것을감안하면보다최적의성능을얻기위하여개선이필요하다. 둘째, FAT파일시스템은안정성이부족하다. 모바일제품은그특성상갑작스런전원차단의문제가발생할수있다. FAT파일시스템은동작도중전원이차단되었을경우, 데이타가소실되거나파일시스템전체가깨질수있기때문에중요한사용자정보의유실이나제품의고장을초래할위험이있다. 셋째, FTL과 FAT파일시스템이모두실시간응답을보장하지못한다. 특히, FTL은같은쓰기작업에대해서도그응답시간이일정하지않다. 이것은 FTL 내부에서갱신이어려운플래시메모리의문제를해결하기위해내부알고리즘에의한블록삭제작업과페이지복사작업등을처리하기때문이다. 그러므로파일시스템유저는같은크기의쓰기요청이언제끝날지를예측할수없으며, 이는시스템설계에어려움을야기하기도한다. 이러한문제들을근본적으로극복하기위해플래시메모리를위한전용파일시스템을설계하고자하는노력이있어왔다. 그중가장성공적인파일시스템으로 JFFS2(Journaling Flash File System 2)[8] 와 YAFFS (Yet Another Flash File System)[9] 가있는데, JFFS2 는 1999년발표된 JFFS를발전시킨것으로, LFS(Log- Structured File System) 구조를사용한다 [10]. LFS는파일시스템메타데이타와일반데이타를묶어로그라는자료구조를만들고, 이로그를큐형태의디스크에계속 추가시켜나가는방식으로동작한다. 플래시메모리를위한소프트웨어는크게 3가지로분류할수있다. MTD(Memory Technology Devices), FTL(Flash Translation Layer), Flash File System이다. 먼저 MTD는 Linux에서플래시메모리를위해정의한드라이버모델이다. 플래시메모리를위한일종의디바이스드라이버라고보아도무관하며, 플래시메모리의읽기, 쓰기, 지우기등을담당하는 API를제공한다. FTL은플래시메모리를업데이트가가능한블록디바이스처럼보이도록하는소프트웨어다. MTD가 Linux에서만사용되고있는데반해, FTL은 Linux외의여러환경에서도사용되고있다. 마지막으로 Flash File System은플래시메모리를위해새롭게설계된파일시스템을말한다. JFFS, JFFS2, YAFFS, 등이이에해당하며 Linux환경에서는 FTL을없이 MTD를직접사용하는것이특징이다. 3. MNFS 설계 MNFS 설계의핵심기법은다음네가지로요약할수있다. 핵심기법으로는 (1) 혼합맵핑기법 (2) 블록단위의사용자데이타할당기법 (3) ibat (4) 상향식디렉토리표현기법이다. 먼저 3.1장에서 3.4장까지 MNFS의설계의 4가지핵심에대해설명하고, 마지막으로 3.5장에서순차적인쓰기요청에대한응답시간이어떻게예측되는지를설명한다. 3.1 혼합맵핑기법플래시메모리를대상으로 FTL이나파일시스템을설계할경우가장먼저해결해야할문제는하드디스크와다른플래시메모리의특성을어떻게해결할것인지를결정하는것이다. 플래시메모리는페이지단위로읽기쓰기가가능하지만업데이트를위해서는블록단위의지우기작업을먼저수행해야한다. 블록은여러페이지의집합으로구성되어있기때문에, 갱신하고자하는페이지이외에다른페이지의내용까지지워지는문제가있다. 이러한특성을극복하기위하여몇가지방법이사용되고있다. 대표적으로블록맵핑방법과페이지맵핑방법이있다. 블록맵핑방법은스마트카드표준에서사용하는가장간단한방법중의하나이며, 블록맵핑방법에서페이지의내용을갱신하기위한절차는다음과같다. 새로운블록을할당하고, 원래블록으로부터갱신할페이지만제외하고나머지페이지들을새로운블록으로복사한다음, 갱신할페이지를새로운블록에기록한다. 그리고마지막으로새로운블록이원래블록을대체하도록블록단위의맵핑테이블을수정하면페이지갱신이종료된다. 그림 1은블록맵핑기법의동작과정이다. 블록당페이지수를 4개로가정하고, 그중 2번

500 정보과학회논문지 : 시스템및이론제 35 권제 11 호 (2008.12) 섹터가갱신된다고가정한다. 블록맵핑을사용할때에는블록단위의맵핑테이블이메모리상에존재하게된다. 이맵핑테이블을사용하여논리적인블록번호를통해물리적인블록번호를찾을수있다. 그림 1과같이초기에논리블록 0번이물리블록 0번으로맵핑되어있음을알수있다. 임시블록은물리블록 100번이사용되고있는데, 2번섹터를갱신하는과정에서결국논리블록 0번이물리블록 100번으로바뀌었음을알수있다. 또, 기존 0번물리블록은임시블록으로바뀌었다. 페이지맵핑방법은 YAFFS등에서사용되는데, 페이 지의내용을갱신하기위한절차는블록맵핑에비해훨씬간단하다. 갱신하고자하는논리페이지내용을임의의비어있는물리페이지에기록하고, 해당논리페이지에대한페이지단위의맵핑정보를기록된물리페이지를가리키도록변경하면된다. 그림 2는페이지맵핑방법의동작과정이다. 페이지맵핑방식은페이지단위의큰맵핑테이블을사용하는대신업데이트에따른오버헤드가매우작다. 반면블록맵핑방식은블록단위의맵핑테이블만사용하기때문에적은메모리를소모하지만, 페이지단위 그림 1 블록맵핑기법의동작 그림 2 페이지맵핑기법의동작

MNFS: NAND 플래시메모리를기반으로하는모바일멀티미디어파일시스템의설계 501 표 1 페이지맵핑과블록맵핑의비교블록맵핑페이지맵핑섹터갱신작업의효율성비효율적효율적맵핑테이블의크기작다크다의갱신이일어날경우엔큰오버헤드가발생하는단점이있다. 페이지맵핑과블록맵핑에대한비교는표 1 과같다. MNFS에서는관리하는데이타의종류에따라페이지맵핑방법과블록맵핑방법을혼용하는혼합맵핑기법을사용한다. MNFS의혼합맵핑기법은업데이트가잦은파일시스템메타데이타는페이지맵핑기법을사용하여관리하고업데이트가자주일어나지않는사용자데이타는블록맵핑기법을사용하여관리한다. 이러한혼합맵핑기법을사용함에따라메모리사용량을최소화시키며, 파일시스템성능을향상을갖는다. 그림 3은 MNFS의파일시스템기본구조로써메타데이타영역과사용자데이타영역이구분되었지만, 이것은이해를돕기위한개념적인것으로실제로는블록단위로 NAND 플래시메모리상에영역구분없이기록되며, 로그블록에는 MNFS의메타데이타가, 데이타블록에는사용자데이타가기록된다. MNFS의모든로그블록은할당된순서에따라리스트를구성하며, 순차적으로증가하는로그블록번호를사 용하여그순서를유지한다. MNFS의로그블록첫째페이지에는메인영역과스페어영역에대한각각의로그블록헤더와로그블록번호가기록되고, 이외의페이지는 MNFS의메타데이타인디렉토리엔트리를기록하는목적으로사용한다. 디렉토리엔트리는각각하나의파일이나폴더에대응되며, 파일과디렉토리에대해서각각의이름, 생성날짜, 크기등의정보를가지며, 디렉토리는부모디렉토리엔트리의번호도포함된다. 디렉토리엔트리는각각의고유아이디를가지며, 각각의고유아이디는페이지의스페어영역에기록된다. 디렉토리엔트리는로그블록에시간에따라순차적으로기록되며, 같은아이디를가지는여러개의디렉토리엔트리가존재할경우, 가장나중에기록된엔트리가유효하다. 그림 4는로그블록구조이다. NAND 플래시메모리의페이지크기를고려하여 512 바이트크기를갖도록설계한다. 3.2 블록단위의사용자데이타할당기법기존파일시스템에서는파일에데이타를할당하기위해 4Kbytes 정도의크기를가지는클러스터단위를사용한다. 하지만멀티미디어파일시스템에서는비교적큰크기의멀티미디어파일크기를고려하여상대적으로큰크기의클러스터를사용하는것이일반적이다. MNFS 역시비교적큰 NAND 플래시메모리의블록을할당단위로사용한다. 이것은 MNFS는아무리작은파일이라 그림 3 MNFS 파일시스템의기본구조 그림 4 로그블록의구조

502 정보과학회논문지 : 시스템및이론제 35 권제 11 호 (2008.12) 그림 5 블록단위의사용자데이타할당 도, 하나의블록을할당한다는것이다. 그림 5는블록단위의사용자데이타할당에대한그림이다. NAND 플래시메모리에서는지우기단위가블록이다. MNFS에서는사용자데이타할당을블록단위로하기때문에파일을삭제할때해당파일의데이타를저장하던모든블록을지운다. 파일을지울때 NAND 플래시메모리의블록을지워둘수있다는것은대단히중요한의미를지닌다. NAND 플래시메모리를저장장치로사용하는과정에는결국페이지단위의쓰기작업들과블록단위의지우기작업들이포함된다. NAND 플래시메모리의블록삭제작업은페이지쓰기작업보다약 10배정도더오래걸리는작업이다. 이렇게오래걸리는지우기작업을실제파일이지워질때할수있다는것은중요한의미를갖는다. MNFS에서는파일을지울때정보를갖고있지않는블록들을미리지워놓기때문에이후쓰기작업에서는항상이미지워져있는블록을할당받을수있다. 즉, 시간이오래걸리는지우기작업없이쓰기작업을처리할수있어, 균등한쓰기응답이가능해진다. 기존의플래시파일시스템인 YAFFS나 JFFS2 등에서는파일을삭제할때블록을지워둘수없다. 따라서쓰기작업을진행하다공간이부족하면가비지컬렉션을수행하고 [11], 그과정을통해블록들을지운다. 따라서쓰기작업의응답이극단적으로느려진다. MNFS에서파일을삭제하는작업은기존파일시스템에비해더오래걸린다. 이부분은현재버전의단점이며, 앞으로개선이가능하다. 최신의 NAND 플래시메모리에서제공되는 Multiple Block Erase기능을사용할수있는데, 기존블록삭제작업이 2ms가걸리는데반해, 이기능을사용하면최대 64개의블록을 4ms 동안에지울수있다. 현재버전에서는이기능이구현되지 않았지만, 이기능을구현할경우파일삭제작업의시간도기존에비해크기느리지않으면서최적의쓰기속도를보장할수있다. 또, Multiple Block Erase가제공되지않는 NAND플래시메모리에서는백그라운드태스크를두어시스템이한가할때블록삭제작업을처리하도록하는방법도있다. 블록단위데이타할당의또다른장점은파일시스템에필요한메모리를최소화시킬수있다는점이다. 다음에설명하는 ibat은블록단위사용자데이타할당을기반으로저장공간의상태를관리하는 MNFS의자료구조다. 3.3 ibat: 호스트에만존재하는블록할당테이블 MNFS에서는 FAT파일시스템의 FAT테이블과유사한 ibat을사용한다. ibat은 FAT과유사하지만두가지면에서차이를갖는다. 첫째는 ibat의경우저장장치안에존재하지않고파일시스템을마운트할때블록스캔을통해동적으로구축된다. 또다른차이점은할당단위로써, FAT의경우클러스터단위로할당을하는데반해 ibat는 NAND 플래시메모리의블록단위로할당을하는점이다르다. 이러한설계의목적은균일한쓰기응답시간을보장하기위함과파일시스템의안정성을높이기위함이다. FAT파일시스템의경우파일의크기가증가함에따라주기적으로새로운클러스터를해당파일에할당해야하고, 이과정에서디스크의특정영역에존재하는 FAT테이블을업데이트해야한다. FAT테이블을업데이트하는일자체가파일시스템의쓰기작업의응답시간에영향을미치게되고, 이작업도중에전원이차단됐을경우엔 FAT 테이블의내용에문제가생기는등, 안정성측면에서도악영향을끼친다. MNFS의 ibat의경우, 사용자데이타가저장되는

MNFS: NAND 플래시메모리를기반으로하는모바일멀티미디어파일시스템의설계 503 그림 6 MNFS의데이타블록데이타블록의스페어영역의스캔과정을통해파일시스템이마운트될때재구축된다. 즉, 파일의크기가커짐에따라별도의파일시스템메타데이타의수정이필요없이, 쓰려고하는블록의스페어영역에파일 ID와블록번호를기록하는방식으로블록할당작업이처리된다. 이작업은 NAND 플래시메모리의메인영역에사용자데이타를기록함과동시에처리될수있어별도의시간을소모하지않기때문에, 항상일정한쓰기응답시간을보장할수있다. 또, FAT테이블과같은파일시스템메타데이타가디스크상에아예존재하지않으므로해당데이타때문에파일시스템이망가지는일이없게된다. 데이타블록의구조는그림 6과같다. 데이타블록의스페어영역에기록되는디렉토리엔트리번호는블록이포함된파일을가리키는역할을하고, 블록번호는해당파일내에서논리적으로몇번째위치하는블록인지를나타낸다. MNFS에서파일시스템을최초마운트하며, ibat을구축하는순서는다음과같다. 먼저 NAND 플래시메모리의모든블록에대해첫째페이지의스페어영역을읽는다. 이과정에서해당블록의타입을판별한다. MNFS에서는 4종류의블록이사용되는데, 디렉토리엔트리, 즉메타데이타를저장하기위한로그블록과사용자데이타를저장하기위해사용되는데이타블록, 지워진상태로데이타블록이나로그블록으로사용될수있는프리블록, 그리고하드웨어적인결함으로사용해서는안되는베드블록이다. 블록스캔작업을통해로그블록들을골라낸다음, 각로그블록들의 ID에따라생성된순서대로리스트를구성한다. 리스트가구성되면각로그블록의스페어영역을순서대로따라가며읽는다. 스페어영역에기록된디렉토리엔트리번호를통해유효한디렉토리엔트리를찾는다. 이과정이끝나고나면, 유효하다고선별된디렉토리엔트리들을읽어들이고해당디렉토리엔트리가파일을가리키는디렉토리엔트리일경우, 해당파일에속하는데이타블록들을선별하 여 ibat으로구성한다. 이때맨처음스페어영역스캔작업에서읽어두었던정보를사용하기때문에추가적인읽기작업이필요하진않다. 이상의과정을유효한모든디렉토리엔트리를대상으로반복하여 ibat 구축작업을완료한다. 3.4 상향식디렉토리표현기법 MNFS는기존파일시스템에서사용하던디렉토리파일을사용하지않도록설계되었다. 디렉토리파일은디렉토리에포함된파일또는서브디렉토리의이름과정보를가진파일로일반데이타파일과똑같은방식으로유지관리된다. MNFS에서이방법을사용하지않는이유는, 이파일의경우 MNFS에서가정한멀티미디어파일과는달리빈번한갱신작업이일어날수있기때문이다. MNFS에서는멀티미디어파일의경우갱신작업보다는순차적인쓰기작업위주로일어난다고가정한다. 본논문에서는 MNFS에서디렉토리파일대신사용할수있는방법으로, 상향식디렉토리표현기법을제안하였다. 이기법에서는각각의디렉토리엔트리가자신이포함된부모디렉토리엔트리번호를포함한다. 디렉토리에포함된자식디렉토리엔트리가부모디렉토리를가리키기때문에상향식이라고부른다. 예를들어표 2와같이디렉토리엔트리번호가구성되어있을경우, 디렉토리구조는그림 7과같이표현된다. 이러한방법을사용하려면항상모든디렉토리엔트리를읽어서계층적구조에대한정보를메모리상에구축해놓아야한다. 특히파일의개수가많을경우심각한성능저하와자원소모가발생할수있는위험이있다. 디렉토리엔트리번호 표 2 상향식디렉토리표현방식의예 이름 부모디렉토리엔트리번호 0 MNFS Volume 0 1 Animals 0 2 Birds 1 3 Tiger 1 4 Eagle 2 그림 7 상향식디렉토리표현

504 정보과학회논문지 : 시스템및이론제 35 권제 11 호 (2008.12) 다만, MNFS에서는대상으로하는파일의크기가 NAND 플래시메모리의용량에비해상대적으로커서, 파일의개수또한제한적일수밖에없기때문에그러한문제가심각하지않다. 예를들어, 1Gbytes의용량을가지는 MP3플레이어를가정할경우, 4Mbytes의 MP3파일이 256곡저장될수있다. 이경우상향식디렉토리표현기법을사용하면 256회의페이지읽기작업과 512Bytes의메모리밖에는소모되지않는다. 3.5 쓰기응답시간의보장 MNFS는 (S main * N) 바이트의순차적쓰기요청을 N번의페이지기록으로처리하도록설계되었다. 여기서 S main 은 NAND 플래시의한페이지의메인영역의크기로, 소블록플래시메모리에서는 512이고대블록플래시메모리에서는 2,048이다. 예를들어소블록플래시메모리에서 32Kbytes의쓰기요청은 64회의페이지쓰기로처리된다. 물론 CPU연산오버헤드가조금붙긴하지만이시간은페이지기록시간에비해상대적으로매우짧다. NAND 플래시메모리의한페이지에대한쓰기시간은플래시메모리로쓰고자하는데이타를전송하는시간과, 전송된데이타를실제로기록하는시간으로이뤄진다. 데이타전송시간은플래시메모리와 CPU의연결버스동작속도에의존적이다. 플래시메모리의페이지기록시간은플래시디바이스에따라달라지는데, 보통 200us 정도의시간이걸린다. NAND 플래시메모리에서한페이지를기록하는시간 을 t page 라고할때, t page 는다음과같이정의될수있다. page ( S page ttr ) t prog t = + 이때 S page 는페이지의크기로, 소블록플래시메모리에서는 528, 대블록플래시메모리에서는 2,112이다. t tr 은바이트당전송시간이고, t prog 는전송된페이지를기록하는시간이다. 따라서 (S main * N) 바이트의쓰기요청에대해 CPU오버헤드를무시한 MNFS의응답시간은다음 식으로정의될수있다. ( S t ) + t ) N page tr prog 4. 성능평가 4.1 실험환경 MNFS의성능평가및기존파일시스템과의비교를위해, MNFS와 YAFFS, FAT파일시스템을비교한다. 203Mhz로동작하는 ARM920T 프로세서를사용하는 SMDK2410 보드를사용하고, 1Gbits용량의소블록 NAND 플래시메모리를사용한다. FAT파일시스템은 psos2.5에포함된 phile을사용한다. 4.2 실험및결과실험은모바일멀티미디어파일시스템이사용되는환경을감안하여총 5가지의시나리오로실험을진행한다. 각시나리오에대해 YAFFS, FAT, MNFS 3종의파일시스템성능을비교한다. 시나리오 1: 123MB공간을 1~5 MB 크기의파일로채우는실험 128MB공간을 FAT파일시스템을사용하여포맷할경우, FTL오버헤드와 FAT파일시스템오버헤드등을제외하고총 123MB의공간이남는다. FAT 파일시스템의남은공간에서 1~5 Mbytes까지 1Mbytes 단위의임의의크기의파일을생성하며각파일이생성되는시간을측정한다. 그림 8의결과를보면, YAFFS가평균 686KB/s의쓰기속도를, FAT은 278KB/s, 그리고 MNFS는 1,538KB/s의쓰기속도를나타낸다. 각속도에대한분산값은각각 18, 631, 49이다. YAFFS는알고리즘상가비지컬렉션작업을하지않을경우이론적으로 MNFS와같은결과를가져야하지만, 실제로는절반이하의속도를보인다. 이것은 YAFFS가 MNFS에비해상대적으로복잡한알고리즘을사용하고있어프로세서의연산오버헤드가크기때문이다. 이를확인하기위해시나리오1의실험과정에서의쓰기회수를측정한결과, MNFS와 YAFFS의 NAND쓰기회수가거의비슷하다. 따라서복잡한자료구조로인한 CPU연산오버헤드때문임을알수있다. YAFFS는쓰기작업도중에자료구조를동적으로생성하고삭제한다. 특히이과정에사용되는 malloc()/free() 함수의오버헤드가매우크다. 시나리오 2: 시나리오 1을마친상태에서빈공간 64MB이상을확보할때까지임의의파일을선택하여삭제한다. 파일단위의삭제작업을통해파일삭제에소모되는시간을비교한다. 시나리오 1이끝난상태에서다시임의의파일을선택하여삭제하여, 디스크에조각이발생하도록한다. 그림 9의결과를보면, YAFFS와 FAT파일시스템에비해 MNFS의파일삭제시간이오래걸리는것을알수있다. 그래프에서 X축은삭제하는파일의크기이고 Y축시간은파일삭제에소요된시간을파일크기로나눈값이다. 즉, 1Mbytes당삭제시간이다. MNFS의경우 YAFFS나 FAT파일시스템에비해파일삭제작업이오래걸리는데, 이것은 MNFS가파일삭제작업에서할당되었던블록을모두지워놓기때문이다. 반면 YAFFS와 FAT에서는메타정보의수정만으로파일삭제작업을마친다. 따라서해당공간에대한가비지컬렉션이이후쓰기작업도중발생하게된다. 시나리오 3: 시나리오2를마친상태에서다시남은

MNFS: NAND 플래시메모리를기반으로하는모바일멀티미디어파일시스템의설계 505 그림 8 시나리오 1 의실험결과 그림 9 시나리오 2 의실험결과 공간을 1~5Mbytes 파일로채우는실험이번시나리오에서는시나리오1 과시나리오2를통해조각나있는볼륨에대해, 다시파일을생성하며쓰기성능을측정한다. 시나리오1과같은방법을사용하여 64M bytes공간을채운다. 그림 10의결과를보면 YAFFS의경우처음 2MB파일을생성할때, 가비지컬렉션작업이일어났음을예측할수있다. 가비지컬렉션작업을통해가용한공간을확보한다음에는, 다시 650KB/s 정도의쓰기성능을유지한다. FAT파일시스템의경우엔, 그응 답이매우불규칙하며, 이것은사용하는 FTL의알고리즘에의한것으로, 파일시스템에서파일을지우더라도그사실을 FTL에서는알지못하고, 시나리오 1의작업을통해전체볼륨이가득차게되고이로서 FTL의성능에영향을주게된다. 이에비해 MNFS는약 1,500KB/s의성능이유지된다. 시나리오 4: 32KB단위로 64MB파일쓰기응답시간측정시나리오 3을마친상태에서, 시나리오 2의방법으로

506 정보과학회논문지 : 시스템및이론제 35 권제 11 호 (2008.12) 그림 10 시나리오 3 의실험결과 그림 11 시나리오 4 의실험결과 볼륨에 64MB의공간을확보한다음, 하나의파일을만들고, 32KB씩 2048회쓰기요청을하여각쓰기요청에대한응답시간을측정하는실험이다. 이실험을통해멀티미디어데이타의녹음 / 녹화작업에대해파일시스템이얼마나균등한쓰기응답시간을보이는지비교할수있다. 그림 11을보면 YAFFS는초기약 520ms 정도의응답시간을보인후약 50ms의응답시간을꾸준히나타냄을알수있다. 이것은앞부분에서 YAFFS의가비지컬렉션작업이일어났다는것을의미한다. 볼륨이 가득찬상태에서 FTL의성능저하때문에, FAT파일시스템의경우응답이매우불규칙하다. 이에반해, MNFS의경우평균 21ms, 분산 0의결과를보인다. YAFFS의평균응답시간 62ms과분산값 7,097을나타내며, FAT파일시스템은 174ms의평균응답시간과 41,248의분산값을갖는다. 이상의실험을통해 MNFS가연속된파일쓰기요청에대해균등한쓰기응답을보이는것을확인할수있다. 또, 성능면에서도 YAFFS나 FAT파일시스템에비

MNFS: NAND 플래시메모리를기반으로하는모바일멀티미디어파일시스템의설계 507 표 3 마운트시간과 Heap 사용량비교 YAFFS FAT MNFS 마운트시간 6,441ms 220ms 185ms Heap 메모리사용량 680Kbytes N/A 34Kbytes 해월등히좋음을알수있다. MNFS의마운트시간과 Heap 메모리사용량을측정하는데, 시나리오 1을수행한상태, 즉볼륨이가득찼을때볼륨을마운트하는시간과 Heap메모리사용량은표 3과같다. FAT파일시스템의경우 psos컴포넌트인 phile을사용하기때문에 Heap사용량을측정할수없다. MNFS는 YAFFS에비해 30배이상빠르게마운트가가능하고, Heap메모리도 1/20 밖에는소모하지않는다. 시나리오 5: 512바이트~16Kbytes까지 512바이트단위로크기를늘려가며쓰기요청에대한응답시간의측정마지막실험으로 512바이트에서 16Kbytes까지 512바이트단위로증가시키며쓰기요청에대한응답시간을측정한다. 앞서정의한 MNFS의쓰기시간에대한실 험이다. ( S t ) + t ) N page tr prog 그림 12의결과를보면, 512바이트당약 334us의시간이비례적으로소모됨을알수있다. 약간의오차가 22회째와 29회째쓰기응답시간이예측값보다적게나왔으며, 오차는 6.8% 와 4.1% 로매우근소하다. 오차의원인으로수식에서무시한 CPU연산오버헤드와 NAND 페이지기록시간 t prog 의오차를생각할수있다. 특히 t prog 는데이타시트에따르면물리적인 NAND 플래시메 모리의마모도와상태에따라 200us에서최대 500us까지걸림을알수있다. 그림 12에서세모표시라인이 MNFS에 (512 * N) 바이트의쓰기요청에대한응답시간이다. 네모표시라인은 (0.334 * N) 의값을그래프로표시한것으로, 한섹터에대해약 334us가소모된다고가정한그래프다. 두그래프가거의일치하는것으로, MNFS가연속된쓰기요청에대해예측가능하게동작함을알수있다. 참고로, t prog 를데이타시트상의 Typical 값인 200us로가정할경우, t tr 은약 253ns이며, 이를반영하면 512 * N 바이트의쓰기요청에대해 MNFS의쓰기응답시간을다음식으로예측할수있다. (( 0.253) + 200) N 528 (us) 5. 결론 MNFS는모바일멀티미디어제품에적합하도록설계된 NAND플래시메모리기반의파일시스템이다. 빠른마운트시간과적은자원의소모, 그리고순차적인쓰기요청에대해예측가능한쓰기응답시간을보장하는것을목표로하였으며, 이를통해멀티미디어스트리밍을안정적으로저장할수있도록설계되었다. 특히모바일멀티미디어제품에서요구되는파일시스템사용패턴을분석하여, 적게일어나는갱신작업대신순차적인읽기 / 쓰기작업에초점을두어설계하였으며, 이와같은접근은매우의미가있다. 저장장치의대부분을차지하는멀티미디어파일의경우데이타갱신이필요한경우가적지만, DRM 정보나재생목록과같이멀티미디어파일을다루기위해보조 그림 12 쓰기섹터개수에따른쓰기응답시간

508 정보과학회논문지 : 시스템및이론제 35 권제 11 호 (2008.12) 적으로필요한일부정보의경우갱신작업이부분적으로필요하다. 이러한파일을 MNFS에서사용하면성능감소와저장공간의낭비를초래할우려가있지만, 현재로서는이러한파일들을위하여별도의파티션과별도의파일시스템을추가로사용하는방법이최선이다. MNFS는주기적으로발생하는스트리밍데이타를효과적으로저장할수있는모바일멀티미디어파일시스템으로서는그목표를달성하지만, 그과정에서다양한파일에대한배려를하지못하게되었다는문제점을갖게된다. 즉, 멀티미디어파일이아닌파일을저장하기에는적합하지못한구조를갖추었으며, 이러한부분때문에실용성이떨어지는파일시스템이되었다. MNFS 가연구목적의파일시스템에서벗어나실제제품에사용될수있는파일시스템이되기위해서는, 이러한부분에있어서의보완이필요하다. 참고문헌 [1] W. Mangione-Smith, P. Ghang, S. Nazareth, P. Lettieri, W. Boring, R. Jain, "A low power architecture for wireless multimedia systems: lessons learned from building a power hog," Proceedings of the 1996 international symposium on Low power electronics and design, pp. 23-28. [2] Samsung Electronics, "16M 8 Bit NAND Flash Memory," http://www.samsung.com/. [3] SSFDC Forum, "SmartMediaTM Specification," http://www.ssfdc.or.jp [4] Samsung Electronics, "512 Mb/1Gb OneNANDTM Flash Memory," http://www.samsung.com/. [5] Microsoft, "FAT: General Overview of On-Disk Format," Ver.1.03, 2000. [6] Intel Corporation, "Understanding the flash translation layer (FTL) specification," http://developer. intel.com/. [7] Li-Pin Chang, Tei-Wei Kuo, "An efficient management scheme for large-scale flash-memory storage systems," in Proceedings of the 2004 ACM symposium on Applied computing, 2004, pp. 862-868. [8] D. Woodhouse, "JFFS: The Journaling Flash File System," in Ottawa Linux Symposium, 2001. [9] Aleph One Company, "Yet Another Flash Filing System," http://www.aleph1.co.uk/yaffs. [10] M. Rosenblum, and J. K. Ousterhout, "The Design and Implementation of a Log-Structured File System," ACM Transactions on Computer Systems, Vol. 10, No. 1, 1992, pp. 26-52. [11] Li-Pin Chang, Tei-Wei Kuo, Shi-Wu Lo, "Realtime garbage collection for flash-memory storage systems of real-time embedded systems," in ACM Transactions on Embedded Computing Systems (TECS), Volume 3 Issue 4, 2004, pp. 837-863. 김효준 2006 년한양대학교대학원전자통신컴퓨터공학부석사. 삼성전자선임연구원기술총괄소프트웨어연구소. 관심분야는파일시스템 원유집 1990년 2월서울대학교계산통계학과졸업. 1992년 2월서울대학교전산과학과석사. 1997년 7월 Univ. of Minesota 졸업 ( 박사 ). 1997년 9월~1999년 2월 Intel 연구원. 1999년 3월~현재한양대학교전자컴퓨터통신공학부부교수. 관심분야는 O/S and File system support for massive scale byte-addressable NVRAM, Large scale archiving and storage and file system support for multimedia application, Storage systems, Multimedia Networking, Internet Traffic Modeling and Analysis 김요환 2005년한양대학교전자컴퓨터공학부 ( 학사 ). 2007년~현재한양대학교대학원전자통신컴퓨터공학부석사과정. 관심분야는멀티미디시스템, 파일시스템