Chinese Journ al of Elect ronicsVo1.19, No.3, J uly 2010

Analysis and Comparison of NAND Flash SpecificFile Systems*

LIU Shu, GUAN Xuetao, TO NG Dong and CHENG Xu(Microprocessor Research and Development Center of Peking University , Beij ing 100811, China)

Abstra c t - N A N D fla sh m emory b ecomes one of themost popula r s t o rage d e vice s in e m bed d e d sy stem a n d m o­b ile computers. Efficient flash fil e sy stem designs are im­portant for sy st e m d esigners a n d use r s . In t his p aper, w es t u d y the d esign issues and p erforma n ce of flash-specificfil e systems a n d d efine four p e rfo rmance metrics t o eval­uate fla sh fil e systems. Then, d e t aile d comparisons o fthree m ains t r eam flash fil e systems are conducted, includ­ing JFFS2 , Y A F F S2 a n d UBIFS . Taking t ech n iqu e s used inthe thre e fil e systems a n d e va luatio n r es u lts int o accou n t ,fla sh fil e system d esig n s p ace is d is cussed . T h is paper canprovide u sers a comprehensi ve understanding o f NANDfla sh fil e system d e si gn, present guidelines for measu re­m ent of fla sh file systems a n d help use r s d e t e r min e w hichfil e sy stem best m ee t s their n eed.

Key words - NAND flash, F ile system , Embedded sys­

t e m , Performance evaluat ion.

I. IntroductionFlas h memory is widely used because of it s non-volatile , shock

resist ant , and power-economic features. T her e are two di fferentty pes of flash me mory : NO R flash and NAN D flas h. NOR flashis typically used for code storage and direct execut ion in port ableelectronic devices. NAND flas h is used pr imarily as a high -d ensityda ta storage medium. W ith rec ent t echnology breakthroughs inboth capacity and reliability, NAND flash has qu ickly taken placeof hard disk as data sto rage device[l] . As a resu lt , flash-based filesystem research is now one of t he most act ive research areas.

However , t here are some hardwar e lim it at ions in flas h mem­ory wh ich ar e significant ly di fferent from hard dis k, mak ing con­ven t ional file system designed for d isks cannot be applied dire ct ly.First , flash mem ory is organized in blocks, which cons ist of fixednumb er of p ages . The unit of erase operat ion is a block and t heunit of read/ writ e op er ation is a page. There are three ty pes ofop erations in flash mem ory : read , write and erase, wh ose costs a redist inct . Second, blocks of flash memory need to be erased befor et hey can be rewrit t en . T here for e, in-place updates used in disk arenot a llowed . Data are up dated to free pages and t he obsolete dat aare left as gar bage. The ga rbage collection pro cess is needed to copylive pages t o free pages and erase the block. Third , bad blocks mayexist in NAND flash memory wh en shipped or may occur dur ingoperation. System mu st be able to mas k out t he invali d blocks . Inaddit ion, the erase number of each block is limited . Wear levelingis import ant t o lengthen the life t ime of flash memory.

To address t hese issues, flash file sys tem design t echniques havebeen studied since t he widespread int roduction of flash mem ori es inea rly 1990s . T wo di fferent approaches have been proposed[2]: Flashtranslat ion layers (F T L) in combination with tradit ional file sys ­tems and flas h-specific file systems . FTL hides t he flas h constraints

"Manusc ript Received June 2009; Accept ed Nov . 2009.

and presents t he flash device as a rewritable blo ck device, so t hatt radit ional d isk file sys tems such as EXT2 and FAT ca n be used .In contra st , the flash-specific file sys te m is designed for dir ect useon flash chips. It is obvious t ha t flash-specific file sys te m can bemore efficient t han stacking a file sys t em designed for disks on topof t he t rans lat ion layer. Wi t h th e t rend of us ing flas h memo ry assecondary storage device, it is importan t to cons t ruc t an efficientflash file system both for system designers and users. However , itis hard to understand t he internal det ai ls of flash file sys te ms anddeter mi ning t he "best fit" one for sp ecific scenario. For example,t he limi ta tion of memory in embedded sys tems and t he capacity de­mand in mobile comp ute rs may induce different challenges for flashfile system des ign . In the past few year s, many excellent file systemdesigns and p erformance enha nceme nt mechanisms of flash mem­ory have been proposed . Many of t hem are eit her just discussed inresearch are a or patented to so me compani es . Data structures andalgorit hms used in flas h t ran sla tio n layer are studied in Refs .[2, 31.C hung et at. add ress FT L rela ted research issues and provides per­formance evalua t ion res ultsl'll. But analysis of flash-specific file sys­t em is limi ted now . We got t he same troubles when we build flashspeci fic file system on our PKUnity-SK SoC platform [5,6] , whichmoti ves this resear ch .

Most of this pap er is devoted to a discussion of flash-specificfile system design issues, a im ing to provide designers and users acomprehensive underst andi ng of what an efficient flas h file syste mshould be, key te chniques in flash file syste m design and help themdet ermine which file sys te m best meets their need . There are fourcont ributions: (1) T he functions and work pr oces ses of flas h-sp ecificfile system are described . Also, some basi c design pr incip les are pre­sented . (2) Aft er exam ining flash -b ased file system researches, wede fine four pe rformance met rics to evaluate flash file sys te m des ign.(3) We conduct det ail comparisons of t hree mainst rea m flash filesys te ms which are availa ble and popular in op en literat ur e, includ­ing JFFS2[71, YAFFS2[8], and UBIFS[9) on our PKUni ty-SK SoC

- system. Results are analyzed and discussed t aking file sys tem im­plem ent ati on det a ils into account . (4) Based on t he analysis andcompar isons, we don 't only give the strengt hs and weaknesses oft hese t hree file syst ems in different application scenar ios , bu t alsopr esent some guidelines of flash file system design and select ion .

The rest of t his paper is organized as follows. Section II pro­vides a br ief overv iew of flash file systems fun ct ions and design prin­ciples . Section III gives a detail ed analysis of cur re nt ava ilable flash

• file sys tem implementat ions in Linux . Section IV defines flash filesystem performance metrics. Section V presents t he ex per imentalmethodology and results. F inally, we conclude in Section VI.

II. Flash-sp ecific File SystemThe very distinct characte rist ics of flas h memory introduce seri­

ously challenges to file system design . A flash memo ry-b ased st oragesystem must be able to make effect ive use of t he adva ntage of flash

404 Chinese Journ al of Electronics 2010

Partition I

Fi g. 3. MTD partit ion

F ig. 4. UB I archite ctur e

Partition I

F ig. 2. Lin ux storage subsystem

MTD sub system is a generi c inter face to memory devices suchas flash and R AM , providing simple read, wri te and erase access toflash devic es . MTD layer is well aware of t he differences betweenflas h wri te and erase , knows t he size of an erase block and can per­form ga rbage collection . As shown in Fig.3, flash chip may be splitinto severa l MT D part iti ons , where eac h MTD partit ion is a MTDdevice. A MTD parti ti on consists of a set of consecutive blocks.Bad blocks are not hidden to MTD layer . Both flash t ranslationlayer FTL/NFTL and flas h-sp ecific file system JFFS2/YAFF S2 canbe b uilt on top of MTD dev ices . However , there are several disad ­vant ages of MT D layer. F irst , t he parti ti on is st at ic. If users wantto cha nge their par ti ti on scheme, t hey have to modify t he drivercode or kernel boot ing parameters. Second , MTD do es no t provid ewear-leveling for t he who le chip . As a result , the blocks in t he par­t it ion storing read-only da ta such as boot loader are far less erasedt han the read/write par ti t ion .

UB I is a general purpose flash man agement layer which providest he managem ent for mult iple logical volumes. It encapsula tes theflash chip management from file syst ems an d user space inter faces .UBI provides logical volumes inst ead of MTD partitions . As shownin F ig.4 , Volu me A and Volume B consist of Logical erase block(LE B). UBI layer im plements logical to physical blo ck mappi ng sot hat wea r-leveling across t he whole device and bad block manage­ment can be eas ily implemented . Furthermore, UBI allows dy namicvolum e creation , del etion and re-sizing, provid ing user mor e flex i­bility.

Memory

parbaf':COllCC IiO~~

I Logical-physi ca l mapping IFlas management

---- -- - ---- - - - - - - - --- - - --- - --- - - - - - - - - - --- ------- - - - - - - - ----_.

'----,--_'-_---'--_----.J'-~----.J--,----.J----'-----'-,_...L-I Flash layout

memory while over com ing its constraints.

F ig. 1. F lash file sys te m architec t ure

A logical a rchite ct ur e of flash file sys te m is shown in F ig. 1. Fil esare stored on t he flash, while a ll t he run-time in formation is inmem ory, including st ruct ures for file man agem ent , metadata, andbuffered file data. When the file system is mounted , it construct sin-memory met adata according t o dat a sto red on flas h . The mos tsignificant fun ctions being provid ed by flash file sys te m are :

• Flash layoutUsually, two kinds of dat a are stored on the physical me­

d ia: met ad at a (e. g. superblock and inod e) and file dat a . Mostflash-specific file sys te ms use t he same overall pr inciple t hat a log­structured file sys te m is appropriate for flash to im plement out-o f­place upd ate. When wri te op eration is performed t he out-of-placeup date po licy marks old dat a as invalid and writ es new dat a to a freepage, as show n by t he arrows in F ig.1. The layout on flash memorysho uld take advantage of flash mem ory characteristics , such as sparearea, flash page size and t he features of met ad at a and file data .

• In-memory data organizationThe metadata is st ored in memory at run ti me . As file da ta ,

new pages are added t o buffer cache when rea ding from or writingto physical media. Fil e system provides mechanisms and stru ct uresto manage metadat a and buffer cac he, which will affect the per for­mance of file accesses.

• F lash man agementFrom t he user 's p ersp ect ive, t hey on ly concern which file is ac­

cessed and the offset and lengt h of accessed dat a in t he file. How­ever , lite syste ms mu st determine t he physical locat ion of t hat data .The flash management unit locat es t he positi on of request ed dat aon flash. Furthermore, bad blocks mu st be masked out and ga rbagecollect ion is pr ovided to copy val id pages and erase obsolet e block.Some sys tems use an ind ependent man agem ent layer bet ween filesys te m and flash. In t his condit ion , t he address used in file syst emis logical. T he managem ent layer tr anslates logical addresses top hysical addresses on flash and manages bad blocks . In embeddedsoftware system, t he logical-to-physical mapping is usually imple­mented in file syste m.

IV. Flash Specific File System Case Study

Most exist ing flas h file systems provid e simila r fun ct ions. How­ever , different internal mechanisms and techniques result in dis­parate performance and application features . In t his sect ion , we de­scribe thr ee mainstream flash file systems in open lit erat ur e whichare impl emented in Linux .

1. O vervi e wThe subsystems relat ed to storage device organiza t ion and file

system in Linux are shown in F ig.2. Block devi ces offer storagefor hard disks. T he generic block layer hides t he hardware sp ecificcharacteri st ics and provides a unified AP I to access t he block de­vices . Due to t he distinct featur es of flash memory, the generic blocklayer is not suitable for man agem ent of flash . So, Memory techn ol­ogy device (MTD) and Unsorted block image (UBI) subsyste ms aredeveloped .

2 . JFFS2J FF S2[7], the Journalling flash file system version 2 was orig­

inally design ed for small NOR flash es, whose capacity is less than32MB. Lat er , NAN D support was added.

J FF S2 is a log-st ruct ur ed file sys tem. T he basi c uni t of JFFS2is a nod e in wh ich variable-sized dat a and metadata of t he file sys ­te m are stored . Each no de in JFFS2 mainta ins met adat a for a givenfile such as the physical address, it s length and pointer to t he nextnod e which belongs to the same file. J FFS2 makes a new node whenwrit e operation is perfor med . The corresponding inode' s version isincreased by 1 for every nod e writes. Ther efor e, J F FS2 needs toscan the ent ire flash partit ion to const ruc t in-memory data struc­tures which lin k t he whol e directory tree of t he file syst em . It isobv ious t hat t he larger JFFS2 parti tion is , the longer it takes tomount it .

JFFS2 keeps a number of linked lists of st ructure s. During

An alysis and Compar ison of NAN D Flash Speci fic F ile Syste ms 405

t he nor mal operation, t he majority of erase blocks will be on theclean-l i st or t he dir ty-l i s t , which represent blocks full of valid nodesand blocks which contain a t leas t one obso lete node, resp ectively.Blo cks in f r ee.list conta in only one vali d node, a mar ker which ispresent to show that t he block was pr op erl y and completely erased .When garbage collection pro cess is t riggered , JFFS2 uses t he liststo cho ose a block for ga rbage collection. A very simple pro babilis­t ic method based on the jiffies counter is used . If jij jies%100 isnon-zero, a block is taken from the dirtu.list . Otherwise, on the one­in-one-hundred occasions t hat the formula is zero, a blo ck is takenform t he clean-list. In t his way, wear-leveling is implem ented .

JFFS2 has summar y support, whi ch helps speed up t he mo untt ime . There are two kinds of summaries: Erase block sum mary(EBS) and Cent ralized summary (CS) . EBS st ores summary in­form ation at the end of every er ase block , so t hat it is no longernecessary to scan all nodes separately. During t he mount process , ift here is no summary informat ion , the original scan process will beexecuted. CS st ores very important memory data st ruct ur es ont othe flash at umount time. If there was clean umount , at t he nextmount this stored infor mat ion will be read directly into the memoryand no scanning will b e necessary.

Furthermore, compression is supp orted in JFFS2 to make itpossible t o fit quite a lot of dat a . Algorithms such as zlib and Izoar e optional.

3. YAFFS2YAFFS (Yet another flash file system) 18) is the first file syst em

that was specially designed for NAN D flas h. However , it has notbeen added in Linux t ree. It is prov ided in the form of patches.

YAFFS2 is the second vers ion of YAF F S, which suppo rt lar gerpages, and stricte r write requi rement . Each page within a blockmust be written to in sequent ia l order , and each page mu st be writ­ten on ly once. In YAFFS2 , each page is marked wit h a file ID anda chunk number. T he file ID de notes the file inode number andthe chunk number is det ermined by dividing t he file positi on by thepage size. These number s are st ore d in t he spare region of NANDflash mem ory. Therefore, only spare regions are read at the boot ingtime to build file structures. However , t he entire scan of flas h isstill required , and the memory cons umption is also proport ional tothe size of flash. Checkpoints can be used t o spee d up the mo untprocess.

The heur ist ics to find a block wort h ga rbage collect ion inYAFFS2 t ry to delay garbage collect ion when possible to reducethe amount of collect ion that need s to be performed, thus increas­ing aver age system performance. If ther e are many erased blo cksavai lable, YAFFS2 doesn 't work har d , but will instead on ly at temptto perfo rm garbage collection of blocks with very few chunks in use.However , if there are very few erased blocks, YAFF S2 will recovermor e space a nd garbage collect blocks with mor e chun ks in use.Gr eedy ga rbage collec t ion algorit hm is used to select t he di rti estblo ck t o erase .

4. UBIFSUBI FS (9) stands for UBI file system. It wor ks on top of UBI vol­

um es. Similarly t o JFF S2, UBIF S follows a node-structured design .The difference between JFFS2 and UBIFS is tha t UBIFS stores filesystem informati on on t he flash medi a wh ereas JFFS2 stores t hemon ly in main memory.

Unfortunately, storing information on flash is very complex be­cause of out -of-place up date. Fig.5 show s the layout of an UBIFSpartition. There are six areas whose positions are fixed wh en the filesyste m is created . The superblock ar ea LEBO conta ins file sys temparameters . Mas t er node are a occupying LEBl and LEB2 storesthe positi on of all on-flas h st ruct ur es tha t are not at fixed logicalpositions. The log area is a part of UB IFS's jou rn al. UB IF S useswander ing t ree where only t he leaves contain file infor mati on . T heinternal elements of t he t ree are index nod es and cont ain on ly ref­erences to their children . To update t he file syst em , a leaf nodemu st be added or repl aced in t he wandering t ree and all the ances­tral index nodes should b e updated accordingly. It would be veryinefficient if the on-flash index is updated every time a leaf nod e is

writ ten . Inst ead , UB IFS up dates the indexes in memory and peri­odically commits t hem to log area. The size of log area is definedwhen t he file system is created. The next area LPT stores LEBprop ert ies tree. There are t hree LEB prop er t ies : free space, d ir tyspace and whether the erase bock is an ind ex erase block or not ,whi ch are essenti a l to find space to add to the log and to find thedirti est erase blo cks to ga rbage collect. LPT are a is only updatedwh en log is committed . The size of LPT area is automatica lly cal­cu lat ed based on t he LEB size and maximum LE B count specifiedwh en t he file sys tem is created . After LP T , comes t he or pha n area.An or phan is an inode num ber whose inode has been commi t te d tot he index wit h a link count of zero. T his hap pens when an openfile is delet ed and t hen a commit is run. In t he nor mal cases, t heinod e would be de leted when the file is closed. However , if an un­clean um oun t happens, orpha ns need to be accounted for. T he las ta rea is t he main area, which cont a ins the nod es t hat make up thefile syst em dat a and the ind ex. Notice t hat LEBs in t his figur e ar elogically creat ed by UBI. UBI map s P EBs to LEBs.

Fi g. 5. Layout of an UBIFS part it ion

The area organization and st ructures of trees in UB IFS makeit scale logarithmically. T herefore, the moun t t ime and the mem­or y consumption do not linearly dep end on t he flash size. However ,UBIFS dep ends on UB I, which scales linearly. In addition, UBIFSuses t ree node cac he in memory, support ing wr it e-back , whi ch makesUB IF S much fas ter on writes.

UBIF S also supports on-t he- flight compres sion. LZO and zlibalgorit hms are integrated . And t he mkfs.ubifs tool supports favorLZO compression method .

IV. MetricsIn recent years, flas h-memory man agement has drawn a lot of

at tention . After exam ining existing researches, we define four per­formance metrics to eva luate flash file system design .

1. Mount timeT he mou nt t ime of flash file system has become t he most dom­

inant reason of t he delay of sys te m start-up t im e, especially whenbot h the flash capacity and stored data size are large. Mount ti meis an important as pe ct of user experience both in embedded syste mand mob ile computers. Many fast mount ing techniques have beendevelop ed for embe dded and desktop sys te ms[ lO,lll.

The org anizat ions of flash file sys tems ar e different . T herefore,the b ehaviors of sys te m mount ar e disparat e. C han ges of file sizeand t he utili zati on of whole par ti ti on affect the mount t ime of filesyste ms in differ ent ways. Fortun ately, it is easy to meas ur e themou nt t ime using mo un t command .

2 . Mem o ry co nsu m ptio nMemory consumpt ion is another impor t ant aspect of efficient

file system design . T he memory resour ce is usuall y lim ited in em­b edded syste ms. W ith t he increasing ca pa city of flash memory,designers mu st reso lve the huge demand of main-memory space forflash- memory management .

The scalability pr obl ems ar e deep insid e the design of the filesystem . Bot h st ruct ures for managem ent and file sys te m organi­zat ion affect the ut ilization of memory. Many resear ches tr y tominim ize of t he main-memory foot pr int and t he amo unt of house­keepi ng data for flash memory managem ent [12- 18j .

Calculat ing an exact memo ry footprint of file system is not aneasy task. T here are many dependencies. We define code size andrun-time memory usage as two measurement of mem ory consump­t ion . Code size dep ends on var ious factors including CPU choice ,com piler options etc . An d it will be mad e smaller by str ipping thedebug text. Run-t ime data st ruc tures cha nge wit h t he ut ilizat ion offile system. We sho u ld make the precondit ions of com par iso n be def­ini te. The mem ory usage informat ion is read from / pr oc/me minfo.

406 Chinese Journal of Electronics 2010

3 . System p erformanceSystem performance is a comprehensive description of file sys­

te m. In disk file system , read/write la tency is usu ally an importantmetric and it is affected by seek t ime. However, the elem ents t hataffect the performance of flash file system ar e more complex . T heefficiency of map mechanism l12J, garbage collec t ion algor it hm [19,20],flash architecture[21], compression algorit hm and so on have effecton system performance. In order to quantify the performance offlash file system , we pr esent results in terms of read/write sp eed .F ile sys te m ben chm arks can be used directly to evaluate the systemperfor mance.

4 . Garbage collection cost and wear levelin gBesides read /write speed, garbage collect ion cost and wear lev­

eling are important metrics, which ar e related to t he lifet im e offlash . The primary concerns of garbage collect ion algorithms are toreduce t he cleaning cost and cleaning freq uency as mu ch as possibl e,and to evenly dist ribute erase cycles over a ll blo cks. We define t hetota l cost C as in Eq.( I ), where Pi and Ej de no te the wr ite countof page i and erase count of block j , respectively.

2 . Resu lts(1) Mount timeResource consumption is related to the capacity an d t he uti ­

lization of flash . To make our expe riments easy re-conducted, weuse OpenMoko rootfs version 2 as the test file suit . T her e are 653directories and 6435 files in t he rootfs. The total size of t he filesis 128MB. T wo cases are used in our evaluat ion to represent twodiffer ent utili zat ions of flash . On e is full OpenMoko rootfs and theot her is a file subset whose size is 3.8MB, which are denoted byfull-OM and sub- OM res pect ively.

T able 2 P ost mar k p a rametersP arameter syntax Comme ntSet nu mber 1000 Number of files

Set transactions 1000 0 Nu mber of transactionsDirectories across which

Set sub di rector ies 1000 the files are scat teredSe t size 10 15000 Range of file sizeSet buffering fa lse Do not use buffering in the C librar y

Set se ed 2 Rando m seed

Table 1. Environment d e s c ription

v. Performance Evaluation

First , we examine the changes of mount t ime for full-OM andsub-O M . From the result s in Tabl e 3, we can find out two phenom­ena . Firs t, the mount latencies of J F F S2 and YAFFS2 are propor­t iona l to the utilization of flash memory. On the contrary, UBIFScan be mounted instantly. This is becau se of the met ad ata layouton flash and organization mechanism in memory. Met ad ata in bothJFFS2 and YAFFS2 scatters on t he flash memory. F ile sys temshave to scan all t he flash to build in memory data. However , thesup erblock and inod e informati on can be read directl y in speci ficregion in UBIFS , which can save ti me. Second, t he mount lat encyof YAFFS2 is larger t han t hat of JFF S2 for full-O M. But it is nottrue for sub- OM. In the mo unt process, J F F S2 scans all t he nod es,and does com plex computing using data structures stored in mem­ory. YAFFS2 intends to read spare area on ly to reduce I/ O t ime .But the hard ware controllers a re not a llowed to read spare areaseparately. As a result , it has to read the whole pa ge and t here isno advantage of YAF F S2 in terms of I/O access t ime . In contrast,when t he utilization of flash is large, the dat a chunk mechanismmaybe increases t he number of pages accessed wh ich induces largermount latency.

Then we eva luate the effect of com press ion algor it hms . Both Izoand zlib are used in J FFS2 and UBIFS . Zlib has high compressionrate than Izo. Symbol J FFS2-lzo den otes JFFS 2 file system with lzoalgor it hm and ot he r sy mbols use t he same ru le. Tab le 4 lists the re­sults . We not ice tha t high er compression rate induces higher mountlatency. In fact , t he mount ti me cons ists of CPU time and I/O t ime .Compress ion algor ithm tries to reduce I/ O t ime . However , complexalgorit hm will cons ume mor e CPU t ime. The final mount t ime isa t ra de-off between CPU performance and I/ O performance. If t hetime spent on compression can com pensate t he t ime savin g on I/O ,the mo unt time can be improved . For UB IFS , t he mount t ime doesnot change obviously according to t he com pression algor it hm . Themain reason is t hat t he compression is on ly used to file data bu t notmetadata and the mount process op erates mostly on met ad a ta .

Las t , t he checkpoint mechani sms in JFFS 2 and YAFFS2 areassessed . Results show that t he scann ing t ime in mount pr ocess isredu ced efficient ly. For full-O M, t he mount t ime of JFF S2 can bereduced from 37.507s to 6.41s , while the mount time of YAFFS 2can be reduced to only 1.153s.

(1)

(3)

(2)e = E m ax - E m in

C = ",pag es P. + ", blocksE.u,= o ' uJ = O J

Type Va lu ePKUnit y-SK SoC Un iC ore-2 600MHz CPU+ IP s

Mem ory 512MB DDRIIG cc 4 .2.2

Linux Linux 2.6.27 for PKUnity-SK SoCNAN D HY27UG088G5M x 2

In addition, both wear levelin g differ ence e and stand ard devia­tion of erase counts S are used to eva luate t he wear leveling degreeof flash file system . The wear leveling difference e is defined as t hedifference between the maximu m erase count E m ax and t he mini­mum erase count Emi n in Eq.(2) as in Ref.[21]. The smaller e is,the longer t he lifeti me of system is. However , if a block is worn out ,it can be marked as bad block. So, we use t he standard devi ati onof erase counts in Eq.(3) as anot her metric for wea r leveling degree,where n is the number of blocks of flash, and E; is t he erase num berof block i, E is the average erase number.

Designers and users should focus on one or more metrics ac­cording to t heir use scenarios. In embedded sys te ms, mount t ime isimportant to provide acceptable user expe rience. Because of limit edmemory and flash resource , it is a lso necessary to reduce memoryconsumpt ion and make every block to be used evenly. For mo bilecom pute rs with large capacity flash, system performance is usu all yro ncorncd . Furthermore , low memory consum ption is helpful to

syste m power.

1. Experimental environmen tT he ex p erimental envir onme nt we use is a system using

PKUn ity-SK SoC chip wit h 2GB NAND flash, as shown in Ta­ble 1. PKUnity -SK SoC is a sing le chip so lution for UMP C whichintegrates UniCor e-2 CPU developed by MP RC , and many popularI/ O cont rollers[5,61. Page size and block size of t he NAND flash are2kI3 and 128kB, respectively. One page read t ime and programmingt ime are 25/1s and 200/lS, respectively. Block erase t ime is 2ms .

F ile system benchmark Postmark is used in the followin g eva lu­a t ion . It works by creating a pool of rando m t ext files . Tran sactionsare th en performed on t he poll. Each transaction consists of a pairof cre ate/delete or read/appe nd operations . The par am eters usedin our expe riment are list ed in Table 2.

Analysis and Comparison of NAND Flash Specific File Systems 407

(2) Memo ry con sumptionTable 5 compares t he code size and the total mem ory cons ump­

t ion after ea ch file sy stem is mo unt ed. Using default compile config­ur ation in Linux 2.6.27, the code size of DB IFS is lar ger t han t hatof J F FS2 and YAF F S2. It is clear t hat t he m emory cons umptionsof J FFS2 and YAFFS2 are rela ted to the ut ilizat ion of flash . Ont he contrary, DBIFS scales cons iderably bet ter. T he rela tive perfor­mance of J FF S2 an d YAF F S2 in terms of memory cons umption issimilar to t hat in terms of mount la ten cy. T his is becau se t he inter­na l struct ur e designs in file system. JFFS2 m aint a ins vari ous list sand no de informati on . YAFF S simplify t he dat a st ructure and useT Node trees to locate data chunks . For sub-OM, J F FS2 consumesmo re mem or y t han YAFF S2. We can infer t hat t he in memory dat aorganization mec han ism in J F F S2 uses more memory than YAFF S2 .However , for full-OM , t he mem ory usage of YAFFS2 increases mo rerapid ly t han t hat of J F F S2, which means t hat t he buffers and struc­tures used in YAFFS2 don't sca le well wit h t he nu mber of files inflash file system . Resu lts show t hat DBIFS scales better becau semost of the struct ures used in DB IFS are trees. However , even ift he number of files on flash is small , it con sumes certain number ofmemory, which is far larger than JFF S2 and YAF FS2. In addit ion,we ca n find out t hat t he mem ory consumptions change with com­pression a lgorit hms . T here is no obvious r ule betw een com pressionrate and mem ory consumption.

gram op eration s. T hough YAFFS2 induces less erase op erationst han J F F S2 does, it has no advantage in terms of erase count inPost mark-7 t est . DB IF S outperfor ms J F FS2 and YAFFS2 in bothprogram count and erase count . As mentioned above, Postmark ismet adat a intensive. In JFF S2, metadat a is written in a nod e. How­ever , it is wr itten to a 2KB page in YAFFS2, whic h is not only awaste on space, bu t a lso indu ces more programming and er as e op­erations. T ho ugh YAFFS2 has software cache for data op eration,it makes no effective use in Po stmark. UB IFS is a wr ite-back filesystem. The op erati ons are conducted in memory and pe rio dic a llycommitted to log area. Because Po stmar k creates and deletes filesin short t ime, t he mo dificat ion may not be committed to flas h . Asa result , t he program and erase ope rations are reduced .

Wear leveling resu lt is list ed in Table 8. All t he three file sys­te ms show well wear-levelin g resu lts. T he wear-leveling d iffer enceof YAFFS2 is sm all er t han th at of JFFS2. T his is because YAFFS2uses Greedy garbage collection po licy, which erases blocks efficient ly.DB IFS induces t he least erase operations , and the number of eraseop er ati on s do esn 't increase in proportio nal to t he run t im es of Post­mark because of it s write-back mec hanism . Even t he standard de­viati on of DB IF S is a lit tl e larger t han that of YAF FS2 whe re Post­mark runs seve n t imes, DBIFS perfor ms bette r t han YAFFS2 in theseco nd line wh ere the average erase count is 1 too.

Tab le 7 . C ost of fla sh ( in unit of 1000 t imes)

Tab le 6 P o s tmark r e s u lt s

Tab le 5 M emory cons u m p tion ( in unit o f k B ) Postmark-1 Postm ark-7Type # of write #of en"e cost # of write #of erase I cost

JFFS2 230 6 236 1621 27 _~YAFFS2 297 4 301 2083 32 ' 115Ul3l F S 13 3 ]6 78 4 ~~

--

T ype F ile system Av g # e SJFFS2 2 3 0.97

Postmark-1 YAFFS2 1 2 0.95UElFS 1 2 0.30J F F S2 13 5 0.86

Postmark-7 YAFFS2 15 3 0 .57UElFS 1 2 0.77

3 . D iscu ssionJ F F S2, YAF FS2 and DB IFS ar e specific flas h file systems in

Linux, which consider the cha ra cterist ics of flas h memory. Fromabove experi me nts, we can find out t hat file system performan ce isrela ted to user 's scenarios . F irst, t he hardware resource is t he basicof system design . For systems wit h large ca pacity flas h, DB IFS isbest in t erms of mount t ime , mem ory cons umpt ion , wear-levelingand read/write p erfo rmance. J FFS2 and YAFFS2 ar e com pa rable ,However , for systems who se memory or flash space is lim it ed , t hemem or y cons umption and space pena lty in DB IFS is cons iderable.In contrast, JFFS2 is most space efficient, wher e t he compressiona lgorithm ca n im prove t he space ut iliza t ion further. Second, filefeatures sho uld be consi de red. T wo different sets of file are used int he performance eva luat ion. Most res ults are dist inguished . In ad­d iti on , so me system op erat ions ar e met adat a in tensiv e while ot hersaccess file dat a mostly. T he compression algorit hms in DB IF S areon ly effect ive for file dat a. As a resul t , it will not improve p er for­m ance obvious ly in met ada ta-int ensive operat ions .

Tak ing techniques used in t he t hr ee file systems and a ll t he re­sults into account , we t h ink t hat an efficient flas h file system designis driven by t he flash memor y technology and application dem ands .Foll owing design space can be exploite d . F irst, t he complex ity of in­memory metad ata st ru ctures and algori t hms should be op ti mi zed .List , B-tree etc. will induce d ifferent space and man agement over ­head . Second , t aking advantage of softwa re cache to reduce acces sof flash media, so t hat t he read /writ e performance ca n be enhancedand t he lifeti me of flas h can be len gthen ed . Meanwhile , t he robust­ness of file system sho uld be consi de red. T hird, t he data layou t onflash must take advant age of flas h characteristics . Compress ion a l­gorithms can be used to improve space util izat ion . The flas h layoutwill a ffect the mount time and per for mance. Fourth, garbage collec­t ion and wea r-leveling algorithms is another asp ect to affect perfor-

T able 8 . Wear- leveling d e g r e e

UBIFS

[J None. Lzo 0 Zlib

JFFS2o

l600r===~~===:=!=1

T y p e co de s ize fu ll-O M su b-O M--

JFF S2- lzo 99 1012 80.JFFS2-z lib 100 980 148

J F F S2 100 109 2 228YAFFS 96 1640 64

UBiFS-lzo 155 512 512Ul3lFS-z lib 155 528 512

UBiFS 155 &16 51 2

Type J F FS2 YA FFS2 UBI F F ST ime (s) 590 552 177

T rans . rat e (#/s) 86 93 292Read t hroug hp ut (kB/s) 410 .12 438 .36 134 0Wr it e t hroug hput (kB/s) 428.33 45 7.82 1390

Time (s) 59 0 552 177

3 l2001-----j

"..§ 8001-- - --1c::I

00: 400

(3) P erfo r m a nceThe resul t s of Po stmar k ar e compare d in Table 6. DBIF S out­

p er forms J F F S2 and YAFFS both in terms of t he to t al elapsed t imeto run Post mark and operation p er for m ance. YAF F S2 per formsbetter t han JFF S2. We also eva luate t he file syste m performancewit h compression a lgorit hm . Results are show n in Fig.6. We ca nobserve t hat t he high er the compression rate, t he lower t he p erfor­mance .

F ig. 6. Postmark run t im e wit h compression algorithms

(4 ) Cost and Wea r- leveli ngWe trace the progr am and erase op er ation s to eva luate the cost

and wear leveling degree of flash file system s. Two gro up s of test sa re conduct ed . First , we r un P ostmark once to get the basi c infor­mation . T hen , we ru n Postmark seven t imes for long term op er a­t ions . Postmark- l and Postmark-7 are used to denote t he two casesin following result s .

Table 7 shows t he op er ation stat istics for Postmark- l andPostmark-7. It is obv ious tha t YAFFS2 induces t he most pro-

408 Chinese Journ al of Electroni cs 2010

mance. In embe dded sys te ms and mobile computers, t he hard wareresou rce and operation feat ur es may propose different demands ont he four metrics defined in t he pap er. Designers sho uld make trade­off in the design spaces, and users ca n select appropriate flas h filesystem according to these metrics.

VI. ConclusionsF las h mem ory has become one of the major components of data

sto rage bo th in embedded sys te ms and mobil e comput ers since itsca pacity has been inc reased dramat ically during las t few years . Effi­cient file syste m imp lementat ions are imp ort ant to sys tem designersand users .

It is hard to define what an efficiency flash file sys tem is. Int his pap er, we define four per for mance met rics to eva luate flashfile system design : mount ti me, memory consu mp t ion , read/writeper formance, ga rbage collection cost and wea r- leveling . We takeJ F F S2, YAF FS2, and UB IFS in open literat ur e as examples, ana­lyzin g t he impl emen t ations and key techni ques of the t hree file sys ­tems and cond uct ing det ail ed comparisons. Our result s show t hatthe performance varies wid ely across different use scenarios. Eachfile sys tem has it s own st re ngths and weaknesses whi ch dep end ont he internal design det ail s . The design space cr it ica l to sys tem per­formance are discussed . We believe that t his pap er can provide usersa comprehens ive underst and ing of NAN D flash file systems design ,pr esent guide lines for perform ing measurement of flash file systemand help users determine whi ch file system best meets t he ir need .Future resear ch will further explore how t he algor it hms in flash filesystem affects t heir performan ce, and how t he performance can beimproved.

Refe rences

[IJ S.L. Min, E. H. Na m, "C urrent trend s in flash memory tech­no logy", Proc. of Conference on A sia Sou th Pa cific DesignAutomation, Yokohama , J apan , pp .332- 333, 2006 .

[2] E . Gal , S. Toledo , "Algor it hms and dat a structures for flas hmemories" , A CM Computing Surveys, Vo1.37 , No.2, pp .138­163, 2005.

[3] E . Gal , S. Toledo , "Mapping structures for flash mem ories:techniques and ope n problems" , Proc. of IEEE Intern ationalConfe rence on Software Sci ence, Technology and Engineering,Her zelia , Israel , pp .83-92, 2005.

[41 T .S . Chung, D.J . Park, S. Park and D.H. Lee et al., "A sur­vey of flash trans lation layer " , Journal of System s Architecture,Vo1.55, No.5-6, pp.332- 343, 2009 .

[5] X . Cheng, "Super-K : a SoC for single-chip ultra mobile com ­puter" , Proc. of Asia and South Pa cific Design Autom ationConf eren ce, Seoul, Korea, pp .284-284, 2008.

[6] X. Cheng et al., "Architectur e of P KUn ity-SK SoC for UMPC",Chinese Journ al of Com puters, Vo1.30, No .11, 2008.

[7] J F F S: The Jour nalling F lash Fil e Sys te m, htt p:/ / sourceware.org/jffs2/jffs2-htm lj

[8J Yet Another F lash F ilin g System, http:/ / www.yaffs.net/[9J T . Gleixner , F . Haverkamp and A. Bityutskiy, UBI- Uns orted

B lock Im age, 2006.[10] K .S . Yim , J . Kim and K. Koh , "A fas t start-up technique for

flash mem ory based com put ing sys tems" , Proc. of the A CMS ym posium on A pplied Computing, Santa Fe, New Mexico,pp.843- 849, 2005.

[11] J . Ryn , C. Park, "Fas t init ialization and memory managementt echniques for log-b ased flash memory file sys tems " , Proc. ofth e 3rd Intern ational Conf erence on Emb edded Software andS ystems , Daegu , Korea, pp .219-228, 2007.

[12] L.P. Chang, T .W . Kuo, "An efficient man agem ent scheme forla rge-scale flash-memory storage sys te ms", Proc. of the ACMS ymposium on Applied Com puting, Nicos ia, Cyprus, pp .862­868,2004 .

[131 C .H. Wu , T .W. Ku o and C.L. Yan g, "A space-efficientcaching mechanism for flash-memory address t rans la t ion",Proc. of Ninth IEEE Intern ational Sympo sium on Obj ect

and Component-Oriented Real-T ime Dist ributed Computing,Gyeongju, Silla, pp.8- 15, 2006.

[14] C. H. Wu, T. W . Ku o, "An adapt ive two-level management fort he flash t ranslat ion layer in embedded syste ms", Proc. of theIEEE/ A CM Intern ational Confe rence on Computer-a ided De­sign , San Jo se, Californ ia, pp .601- 606, 2006 .

[15J S. Lin et al., "Efficient indexing dat a stru ct ure s for flash-b asedsensor devices" , A CM Transactions on Storag e, Vo1.2, No.4,pp.468- 503, 2006 .

[16J L.P. Chang, T .W . Kuo, "Efficient managem ent for large­sca le flash-memory storage systems wit h resource conservation" ,A CM Tran sactions on Storage, YoU, No.4, pp.381- 418, 2005.

[17] C.H. Wu et al., "An efficient B-t ree layer implementatio n forflas h-memory storage systems" , A CM Tran sac tions on Embed­ded Computing Systems, Vo1.6, No .3, 2007 .

[18] X. Xian g et al., "A re lia ble B-tree implementat ion over flashmemory" , Proc. of the A CM Sym posium on A pplied Comput­ing, Fort aleza, Ceara, Brazil, pp.1487- 1491 , 2008.

[19] Y. Du, M. Cai and J . Dong, "Adapt ive garbage collection mech­anism for N-log blo ck flash memory storage systems" , Proc. of16th Intern ational Conference on Artificial Reality and Telex­istence, Han gzhou, China, pp.532- 535, 2006 .

[20] L. Han , Y. Ryu and K. Yim, "CATA: a garbage collect ionscheme for flash memory file systems" , Ubiqui tous Int elligenceand Com puting, Vo1.4195, pp.103- 112, 2006. /'

[21J L.P. C ha ng, T. W . Kuo, "An adaptive strip ing ar chitecture forflash memory storage systems of embe dded systems", Proc. ofthe Eighth IEEE Real-Tim e and Em bedded Technology and A p­plications Symposium , San Jose, C A, USA, pp.187-196, 2002 .

LID Shu was born in 1982. Sh eis a Ph.D . candidate in MPRC of PekingUnivers ity. She received B.S. degreein comput er science from Beijing Inst i­tute of Technology in 2004 . Her re­sear ch inter ests include op erating sys tem,file system and storage system . (Email:liu shu@mprc.pku.edu.cn)

GDAN X uet a o was born in 1974 .He is a lecturer at Peking Universy. He re­ceived P h. D. degree in 2006. His researchint erest s include oper a t ing sys tem , embed­ded system , system software and sys temchips.

TONG Dong was born in 1971.Now he is an associate professor at PekingUnivers ity. His research int erests in­clud e computer architecture, storage sys­tem , interconnect ion network and System ­on-C hip .

CHENG X u was born in 1964 .He is a professor and doctoral super visorat Peking Uni versity. He received Ph.D .degree from Harbin Insti tute of Techn ol­ogy in 1994 and Post Doctor from Com­puter Science Depart ment of Peking Uni­versity in 1996 . His main research inter­ests are high per formance micropro cessordesign , SoC design , embe dded system, in­stru ct ion level par all elism, compiler opti­

mization and hardwar e software co-des ign.