Secure Deletion on Log-structured File Systems

Secure Deletion on Log-structured File Systems Joel Reardon, Claudio Marf orio , Srdjan Capkun, David Basin Depar tment of Computer Science, ETH Zurich ABSTRA CT W e address the problem of sec ure data deletion on log- structured file systems. W e focus on the Y AFFS file sys- tem, widely used on Android smartphones. W e sho w that these systems pro vide no temp oral guarantees on data dele- tion and that deleted data still p ersists for nearly 44 h ours with a verage phone use and indefinitely if the phone is not used after the deletion. F u rthermore, we sho w that file o ver- writing and encryption, metho ds commonly used for secure deletion on bloc k-structured file systems, do n ot ensure data deletion in log-structured file systems. W e propose three mechanisms for secure deletion on log- structured file systems. Pur ging is a user-lev el mechanism that guaran tees secure deletion at the cost of negligible de- vice wear. Bal lo oning is a user-lev el mechanism that runs con tinuously and gives probabilistic improv emen ts to se- cure deletion. Zer o overwriting is a kernel-lev el mec ha- nism that guarantees immediate secure deletion without de- vice w ear. W e implemen t these mechanisms on Nexus One smartphones and show that they succeed in secure deletion and neither prohibitively reduce the longevit y of the flash memory nor noticeably reduce the device’s battery lifetime. These techniques provide mobile phone users more confi- dence that data they delete from their phones are indeed deleted. 1. INTR ODUCTION Deleting a file from a storage medium serves tw o purp oses: it reclaims storage and ensures that any sensitive information con tained in the file is no longer accessible. When done for the latter purp ose, it is critical that the file is se cur ely deleted, meaning that its conten t do es not persist on the storage medium after deletion. Secure deletion is almost alw a ys ignored in file system de- sign [2, 3, 7, 11, 14, 17], largely for performance reasons. T ypically , deletion is implemen ted as a rapid operation where a file is unlinke d , meaning its metadata states that it is no longer presen t while the file’s conten ts remain in storage un til o verwritten by new data [4]. While many users ex- pect that deleting messages will delete them, clearing the bro wser’s history will clear it, and c hanging their lo cation will ov erwrite their previous location, in realit y this infor- mation remains on their devices without any guarantees of deletion. Surveys of repurp osed hard drives found that many con tained priv ate financial or medical data that could b e re- co vered with trivial forensic cost and effort [4]. How ever, secure deletion is not only imp ortan t when media is repur- posed; it also enables users to protect the confidentialit y of their data if their devices are compromised, stolen, or con- fiscated under a subp oena. In the case of a subp oena, the user may b e forced to disclose all passw ords, keys, or other creden tials that enable access to the data stored on the de- vice; in such a scenario, users can only sanitize their device before it is seized. Secure deletion is particularly imp ortan t on mo dern smart- phones, as they increasingly store p ersonal data such as the o wner’s priv ate conv ersations, browsing history , and lo catio n history . Mobile phones further store business data, whic h for company p olicy or legal reasons should b e deleted after some time elapses or should not b e av ailable at some ge- ographic lo catio ns, e.g., should b e deleted b efore a phone o wner leav es a certain jurisdiction. Curren tly , the only se- cure deletion option av ailable on the Android mobile phone is the factory r eset : a procedure that securely erases all user data on the phone, returning the phone to its initial state. This is clearly inappropriate for users who wish to selectiv ely delete data, suc h as som e emails, but retain other data, suc h as their address b ooks or installed applications. Secure deletion mechanisms ha ve b een proposed for some widely-used block-structured and journalled file systems, lik e ext2 and ext3 [1, 8, 9]. These mechanisms typically modify the k ernel and enforce that when a file is mark ed for deletion it is ov erwritten with arbitrary data. Anoth er mec hanism that was prop osed for preserving data confidentialit y under device seizure is full-driv e encryption, where the decryption k ey is generated from user’s password up on system b oot. This mechanism is effective but has limitations: users can be co erced or legally b ound to disclose their credentials, or migh t b e legally obliged to delete data. In this work, we address secure deletion on mo dern smart- phones with a fo cus on the file system Y AFFS [3]. Un- lik e ext2 and ext3, Y AFFS is a log-structured file system dev elop ed sp ecifically for flash memory storage. A ndroid phones’ internal memory uses Y AFFS to store data such as bro wsing cache, maps cache, names of nearby wireless net- w orks, GPS lo cation data, SMS messages, electronic mails, and telephone call listings. W e analyze how deletion is p erformed in Y AFFS and show that log-structured file systems pro vide no temporal guar- an tees on data deletion; deleted data p ersists for around 44 hours with av erage phone use (Nexus One [5]) and indefi- nitely if the phone is not used after the deletion. F urther- more, we show that mechanisms such as file ov erwriting or encryption of individual files, prop osed for data deletion on block-structured file systems [12, 6] do not ensure data dele- tion in log-structured file syst ems. Namely , ov erwriting a file in log-structured file systems simply writes a new version of a file, but do es not remo ve the original copy . Similarly , when a file is encrypt ed, the ciphertext will be written to a new lo- cation, but the plaintext will remain on the flash drive until storage space is needed and garbage collection is in vok ed. W e propose three mec hanisms for secure deletion in Y AFFS, t wo programs at user-level and one kernel-lev el file system c hange. The tw o user-level mech anisms are pur ging , which pro vides guaranteed rapid deletion of all data previously mark ed to be deleted, and b al lo oning , a contin uous op era- tion th at reduces the expected time th at an y piece of deleted data remains on the medium. The third mechanism is zer o overwriting , a ke rnel-level file system change that securely deletes any data the moment it is remov ed from the file sys- tem. W e implement these mechanisms for the Nexus One smart- phone and show that they neither prohibitively reduce the longevit y of the flash memory nor noticeably reduce the de- vice’s battery lifetime. The purging op eration o ccup ies the phone for half a min ute, but it can b e configu red to run dur- ing the phone’s idle time. Ballooning provides a trade off betw een the time until data is securely erased and the re- sulting wear on the flash memory . Zero ov erwriting securely deletes data immediately without imposing an y additional w ear on the device. Ho wev er, it has the drawbac k of requir- ing k ernel-level mo difications and may not b e suitable for all flash memories. Finally , w e discuss the conditions under which our mech- anisms can b e applied to other log-structured file systems suc h as JF FS, and propose a modification to UBI—a higher- lev el flash interface—that woul d implemen t ballooning on an y flash file system that makes use of it. The rest of this pap er is organized as follows. In Section 2 w e giv e bac kground on flash memory and file systems. In Section 3 we examine the current state of secure deletion in Y AFFS. In Sections 4 and 5 we presen t our three solutions, along with exp erimen tal results. In Section 6 w e discuss related work and in Section 7 we discuss generalizations of our approach and introduce future work. 2. SYSTEM MODEL AND B A CKGR OUND System Model. W e consider a scenario in which users hav e data on their mobile device that they wish to securely delete. This includes cache files that should b e c ontinual ly deleted, suc h as their lo cation histories as enco ded by the names of the wireless netw orks and cellular base stations with which their devices communicated. The adversary that w e consider in this paper is the c o er- cion attacker , the strongest attack er for the data deletion problem. The attac ker can—at any moment—both obtain the user’s device and compel the user to rev eal any secret k eys and passphrases [13]. The unpredictable nature of the attac k prev ents the user from p erforming an y phone sani- tization pro cedure b efore disclosure. This differen tiates the secure deletion problem from data deletion in the context of repurposed hardware [4]. This strong attack er mo del also means that simple solutions to preserving data confidentialit y under device compromise will fail. Encryption of all the data that is written onto the device would not work since the adversary will b e given all our encryption keys. The use of factory reset would not be practical as the unpredictable c ompromise time w ould re- quire erasing the en tire phone’s memory with such frequency that little useful data could reside on the device. W e therefore need nov el solutions to this problem. W e con- sider solutions at tw o levels of system integrat ion: user-lev el and kernel-lev el. User-level means that our application can only perform actions that a normal application installed from the marketplace can p erform. This mo de of access is greatly limited: an application’s interaction with the file system consists solely of the creation and deletion of its own local files. It cannot c hange the file system’s b eha viour in an y wa y to achiev e secure deletion. Kernel-lev el access is m uch less limited: it assumes that arbitrary c hanges can b e made to the file system and a new kernel can be installed on the device. Log-structur ed F ile Systems. A log-structured file system differs from a traditional blo c k-based file system (such as F A T or ext2) in that the entire file system is stored as a c hronological record of changes from the initial empty state. As files are written, new fixed-size chunks are app ended to the log indicating the resulting change; a ch unk can store either a file’s header or some data, and is alwa ys added to the log’s end. The file system mai ntains in RAM information on where the newest version of each header and data ch unk can b e found. Log-structured file systems complicate secure deletion b e- cause the traditional approac h of ov erwriting a file with new con tent simply appends a second version of the file, while the first still remains in the log’s history . Similarly , encrypting a file will also just app end a new encrypted version of that file, while the plaintext remains in the log. Data is only remov ed from a log-structured file system dur- ing garb age collec tion . The garbage collector op erates at the er ase blo ck level, which has a larger granularit y than t0 t2 t1 deletio n lat en c y blo c k r eall oc at i on pe riod Figure 1: A lifetime of stored data. a ch unk. The file system examines the w asted space in an erase bloc k and the total remaining free spac e when deciding whether to garbage collect the erase blo c k. Y AFFS. Y et Another Flash File System (Y AFFS) is a flash- based log-structured file system that is notably used for the in ternal memory of Android mobile phones. Y AFFS allo- cates memory by selecting an unused erase blo c k and al- locating sequentially the n umbered c hunks in that blo c k. When the block con tains no more empty c hunks, a new block is selected for allo cation by searc hing for an empty block. Y AFFS search es for empty blocks sequen tially , wrap- ping cyclically when necessary , by the erase block num b er as defined by the ph ysical lay out of memory on the storage medium. It b egins its search from the last allo cated blo c k and returns the first empty block it finds. When allo cating a block reduces the total n umber of empty blocks in the sys- tem b elo w the minim um threshold, then blo c ks containing w asted space are compacted to reclaim storage. If there is no block th at can be compacted, that is, there is not a single unneeded c hunk stored on th e medium, then Y AFFS reports the file system as full and fails to allo cate a blo c k. Garbage collection in Y AFFS is either initiated by a thread that p erforms system maintenance, or takes place during write op erations. Usually , only a few ch unks are copied at a time, whereby the work to copy a blo c k is amortized ov er man y write op erations. If the file system contains to o few free blo c ks then a more aggressive garbage collection is p er- formed. In this case, blo c ks with less deleted space are col- lected, and the pro cedure con tinues un til the entire block can b e reclaimed. Figure 1 shows the lifetime for stored data. At time t 0 the block is allocated and data is written on to it so on after. A t time t 1 the data is deleted. At time t 2 the block is re- allocated, th us remo ving the data from the medium. The difference t 2 − t 1 is called the deletion latency , and t 2 − t 0 is called the blo c k reallo cation p erio d. Flash Memory. Flash memory is a non-v olatile storage medium consisting of an array of electrical components that store information. The cont ents of flash memory cannot b e altered in place, but rather an erase procedure must b e p er- formed on a larger granularit y than reading or writing. Flash erasure is costly: its increased voltage requirement precipi- tate the wearing out of the medium. Erase blo c ks can only handle a finite n umber of erasure op erations—ro ughly 10 4 to 10 5 [15]—before b ecoming unusable. Flash file systems are typic ally log-structured for t w o rea- sons. First, the large erase granularit y of flash memory maps exactly to the garbage collector’s erase blocks in a lo g- structured file system. Second, log-structured file systems do not require in-place up dates for data; this is well-suited to flash memory’s inability to p erform in-place up dates. 3. D A T A DELETION GU ARANTEES IN EXISTING Y AFFS SYSTEMS In this section, we inv estigate data p ersistence on Android phones. W e examine the time that it takes for one erase block to b e reclaimed after b eing mark ed for deletion. In particular, w e measure the a verage and w orst-case data dele- tion latency for sp ecific devices, application configurations and usage patterns. T o measure the av erage time taken for block reallo cation, which implies the deletion of any data previously stored on the blo c k, w e instrument the file sys- tem at the kernel level to log blo c k allo cation information. Our results show the existence of a large deletion latency , where data that a user may b eliev e to b e deleted in reality remains accessible on the mobile phone. This motiv ates our secure deletion solutions in the next sections. 3.1 Instrumented Y AFFS W e bu ilt a mo dified version of the Y AFFS Linux kernel mod- ule that logs data ab out blo c k allo cations and ch unk writes. W e log when ever a new block is allo cated , which signals that the blo c k is now empty and that whatever data was previ- ously on the blo c k has b een erased (or mov ed). W e also log ev ery write operation: b oth of file headers and of file data. This allo ws us to d etermine ho w often writes occur, in whic h c hunks they o ccur, and when files are deleted. During blo c k allo cations, we log the system time in microsec- onds, the unique ph ysical block num ber (in our case, ranging from 1 to 1570), the blo c k’s sequence num b er, and the num- ber of free ch unks and erased blo c ks according to Y AFFS’s statistics. W e also log the file system’s partition name to dem ultiplex the data, as the Android phone has multiple Y AFFS partitions. Logging ev ery ch unk write gives us a fine-grained view of the system’s writing and deleting b eha viour. W e log the system time in microseconds, the ch unk’s physical lo cation, the op erating system’s owner of the file, the blo c k on which it is written, the type of data b eing written (i.e., a file, a directory , a header, etc.), the file id, and where in the file the data is b eing written. With the collected information, w e can determine ho w m uch data is written to the file system, and the timing and fre- quency of blo c k erasures. W e can also log the time when w e write a particular file to the file system, whic h we cross- reference in our logs t o determine the block num b er on whi ch it resides. Giv en this information, along with the time when eac h blo c k is erased and the time the data was mark ed for deletion by the user, we can compute the deletion latency (cf. Figure 1). By logging the ownership of ch unks, we can also determine the distinct writing patterns of different running applica- tions. W e will later use this to construct profiles that mo del Browser Maps Game Gallery Ov erall Running time (s) 504 395 300 240 1439 Allocated blocks 185 87 1 2 247 Never deleted 168 75 1 2 199 Mean reallo cation perio d (s) 54 75 N/A N/A 271 T able 1: Average reallo cation perio d for differen t commonly used applications. The test ran for 23 minutes and allo cated 304 blocks. differen t scenarios in our simulated environmen t. 3.2 Deletion Latency on Android T o understand the sev erity of th e existing problem with cur- ren t implementations, we examine in detail the deletion la- tency on an Android phone. First, we fo cus on a subset of applications that could b e used daily on a sma rt phone to de- termine deletion latency when using only such applications. W e then contin ue to use the phone throughout our daily rou- tine to find out, on av erage, how long data remains “aliv e” on the system b efore b eing erased. The data w e collected on the phone’s writing patterns was later used to sim ulate an Android mobile phone. The system under test is a Nexus One running the latest Android OS (2.2.1) under what can be considered normal daily use: bro wsing the web, sa ving images, listening to mu- sic, writing and receiving SMS messages, and making calls. T o understand the writing patterns of some commonly used applications, we let a user use the phone’s browser, maps and gallery applications plus a popular game found on the Android Market. The user used the phone unaw are of the test, thereb y eliminatin g an y bias which could be introduced b y knowing which system prop erties were examined. Writing P atterns. F or the br owser test, the user surfed the w eb for approximately 8 min utes, p erforming activities such as logging into a univ ersity w ebsite, getting weather fore- casts, and searching for images. F or the maps case, the user in teracted with the application for appro ximately 6 min utes, searc hing for a particular destination, looking at its “street view” and calculating a route to it. The game and gal lery examples ran for approximately 4-5 minutes each. Statistics for eac h test are summarized in T able 1 and exam - ple traces are plotted in Figure 2. The absence of lines after allocation of some blo c ks indicates that their conten t is still presen t on the system after their deletion time. This short usage scenario, which was executed for 23 minutes, gives an idea of how commonly used applications write to disk. Deletion Latency. T o get a b etter idea of deletion latency , w e used the instrumented phone daily . Th e experiment lasted 670 hours, roughly 27.9 da ys. In total, throughout the experiment, w e reco rded 20345 blo c k allocations initiated by 73 different writers . A writer could b e any application in- cluding the Android OS itself or one of its services (e.g., GPS, DHCP , compass, etc.). The exp erimen t’s logs show that blo c ks are reclaimed, on av erage, every 44.7 hours (the median b eing 44.5 hours). The worst case for blo c k reallo- cation time for the experiment is 327.7 hours. This is not 0 100 200 300 400 500 Time (s) 0 200 400 600 800 1000 1200 1400 1600 Block Number Browser (a) Bro wser application traces 0 100 200 300 400 Time (s) 0 200 400 600 800 1000 1200 1400 1600 Block Number Maps (b) Maps application traces Figure 2: Snapshot of blo c k allo cations for tw o different appli- cations. Dots represent blo c k allo cations. The only blo c ks that are reallocated are the ones between which a line is presen t. The line shows the time those blo c ks hav e b een “aliv e” in the system before b eing reallo cated. All other blo c ks are never reallo cated throughout the test. surprising given the Y AFFS implement ation, but it high- ligh ts the critical need for secure deletion solutions. 4. USER-SP A CE SECURE DELETION In this section, w e int ro duce tw o solutions for secure dele- tion: purging and ballo oning. Both solutions wo rk at user- lev el and are designed for the scenario where a security- conscious mobile phone user wan ts to install a secure dele- tion application from an application marketplace, but is un- willing to install a new phone op erating system. A user-level application has limited access to the flash de- vice. The application cannot force the file system to perform block erasures, prioritize garbage collection of particular ar- eas in memory , or even know where on the device the user’s data is stored. The interface to the file system for suc h ap- plications consists of the creation, modification, and deletion of the user’s own lo cal files. In the next section we show a simpler solution that requires kernel-lev el mo dification s to the Android mobile phone; here w e propose a solution for this highly-constrained environmen t. 4.1 Purging T o guaran tee the secure deletion of all sensitive data on a Y AFFS file system from user-space requires that we delete all the sensitive data and then completely fill the drive with new data. The fact that it must b e completely filled follows from the implementation of Y AFFS’s blo c k allo cation strat- egy . In the worst case, we must assume a deleted ch unk is the only deleted c h unk on an erase blo c k of otherwise live data. The blo c k allocation strategy first uses empty blocks, then compacts non-empty blo c ks by selecting the one with the fewest num b er of live ch unks. In the worst case, when all other erase blo c ks hav e at least tw o empty ch unks, then only by filling the drive to complete capacity are we assured that our deleted ch unk is securely erased. Purging is the op eration that completely fills the file sys- tem’s empt y space with a junk file, thereby ensuring that all previously deleted data is securely erased. After filling the drive, the junk file is deleted so that file system is again usable. It is a rapid op eration that must b e explicitly exe- cuted. This can take the form of automated triggers, which execute perio dically when the phone is idle, whenever the bro wser cache is cleared, when particular apps are closed, or upon receipt of SMS messages with self-destruction requests. It is particularly useful for employ ees who are contractually obligated to delete customer data b efore crossing a b order. Completely filling the drive is p ossib le provided the user is not sub jected to disk-quota limitations, but it typically requires garbage collecting (i.e., erasing) nearly every erase block on the storage medium. This is because d eleted ch unks can o ccur in any erase blo c k that sees active use, resulting in small data gaps throughout the file system—even ch unk- aligned app ends will still erase the previous file header. T o test our h yp oth esis, we p erformed the follo wing exper- imen t. W e first configured an Android phone to run with our instrumented Y AFFS implementation . W e to ok a pris- tine snapshot of the phone’s internal NAND memory b y log- ging in to the phone as root, unmounting the flash driv e, and cop ying the raw data using cat from /dev/mtd/mtd5 (the de- vice that corresp onds to the phone’s data partition) to the phone’s external memory (SD card). The resulting file was then copied to our PC and examined using grep and hex- dump . W e wrote an arbitrary secret pattern not yet written on the device, and obtained a memory snapshot to confirm it had b een written. W e then deleted the pattern, obtained a new snapshot of the memory , and confirmed that the pat- tern still remained in memory . Finally , we filled the drive to capacit y with a junk file, deleted it, and obtained another snapshot to confirm that the pattern w as no w irrecov erable. The time it took to execute the purge operation w as betw een thirt y seconds to a min ute. Figure 3 sho ws the resulting blo c k allo cations rep orted by the instrumented version of Y AFFS around the time of this experiment. The X-axis corresponds to time in hours, and the Y-axis sh ows t he n umbered erase blocks. A small square in the graph indicates when each erase blo c k was allo cated. A t the right side, w e see the near immediate allo cation of ev ery blo c k on the medium. This is the consequence of fill- ing the driv e to capacity; Y AFFS must effectively garbage collect every blo c k so as to reclaim every av ailable ch unk. 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 Time (hours) 0 2 0 0 4 0 0 6 0 0 8 0 0 1 0 0 0 1 2 0 0 1 4 0 0 Allocated block number Figure 3: Block allocation times on an Android device. The time betw een tw o points on the same horizon tal line is the block reallocation p eriod. The data is a sample of live data taken from a Nexus One phone. A t around 75 hours into the exp erimen t, the drive w as completely filled to guaran tee all previously deleted data was removed. 4.2 Ballooning In contrast to purging, which guarantees rapid secure dele- tion of data from user-space, we now present ballo oning, whic h a chiev es probabilistic contin uous secure deletion. Bal- looning reduces the exp ected time an y deleted data—regardless of when it is deleted—remains accessible on a mobile phone. W e b egin by lo oking at the time b et ween subsequent allo- cations of the same flash erase blo c k, which is the time that data written on that blo c k is accessible. The blo c k reallo cation p eriod in a log-structured file system is the expected time that will elapse betw een allo cations of a block in the file system (cf. Figure 1). This is based mainly on tw o factors: the write frequency on the medium, and the exp ected num ber of other blo c ks that will b e allo cated before the particular blo c k is reallo cated. W ere the stor- age medium’s size to increase tenfold, one w ould exp ect to observ e a similar increase in the blo c k reallo cation p eriod. The type of con tents on the blo c k also has an effect: long- term op erating system files tend not to b e deleted, and there- fore blo c ks containing only such files will not b e reallo cated as their con ten ts tend not to be deleted. Suc h blo c ks are clearly not a concern for secure deletion, and so their ex- istence only decreases the expected n um b er of blo c ks that will b e used for non-p ermanen t data storage. The blo c k re- allocation p eriod is prop ortional to the exp ected num b er of blocks used for active storage and inv ersely prop ortional to the num b er of blo c ks that are allo cated p er unit time. The cyclic b eha viour of blo c k allo cations in Y AFFS is evi- den t in Figure 4 (cf. Figure 3), which shows the sequence of block allo cations from our collected Android mobile phone data. While some noise exists, we see that blo c k allo cation n umbers generally increase o ver time and wrap cyclically , and so the blo c k reallocation perio d is dep enden t on both the n umber of blocks and the system-wide time b et ween block allo cations. Our prop osal is to fill the file system with junk conten t, 0 2 0 4 0 6 0 8 0 1 0 0 1 2 0 1 4 0 Time (hours) 0 2 0 0 4 0 0 6 0 0 8 0 0 1 0 0 0 1 2 0 0 1 4 0 0 1 6 0 0 Allocated block number Figure 4: Y AFFS’ block allo cations ov er time on an Android phone. k er n el s pac e u ser spa c e Y A F FS 2 jun k _s i z e ma x_th r esh ol d min _th r esh ol d Bal l o on A p p if n < m i n _t h r es h o ld if n > m ax_t h r es h o ld sleep fr ee_spa c e = n st at fr ee_s pac e delete ju n k wr ite j u n k Figure 5: Architecture of the ballo oning application. thereb y reducing the block reallo cation p eriod. This re- duction results from fewer blo c ks b eing av ailable for allo ca- tion, and will thus reduce the deletion latency . As a result, Y AFFS will b e forced to employ more frequent garbage col- lection, as the file system will p erp etua lly b eliev e it is in a state of reduced capacit y . Our application will delete the junk files when the drive requires more space, and will re- generate them whenever there is “to o muc h” free space. 4.3 Ballooning Application The op eration of our ballo oning application is illustrated in Figure 5. It runs p eriodically on the Android phone, exam- ining the file system (using stat ) to determine the num b er of free ch unks. It creates junk files if the free capacity ex- ceeds the upper threshold, and deletes junk files (if possible) when the free space drops below the minim um. The junk files’ exact size is also parameterizable, and defined in mul- tiples of erase blocks—deleting one junk file will free at lea st one erase blo c k for new data. The oldest junk file is alwa ys deleted b efore more recen t ones to load-balance the wear on the flash memory . Long- liv ed junk files can also b e erased, with new ones written, to ensure that their corresp onding erase blo c ks will b e used for more active data storage. The new ones should b e written before deleting the old ones to ensure they reside on different erase blo c ks. This system is illustrated in Figure 5. W e implemented our application and ran it successfully on the Android phone. The only p ermission it required was the abilit y to run while the phone was in a lo c ked state; the application also needs to specify that it will run as a service, meaning execution o ccurs even when the application is not in the foreground. The application can b e installed without an y elev ated privileges on the phone and op erates entirely in user-space. Ballo oning must mainta in a minimum of 5% of the block s free to a void perp etual w arnings about low free space. 4.4 Experimental Evaluation Besides running our application on the Android phone, we collected more statistics by simu lating its b eha viour on a sim ulated flash drive mounted as a Y AFFS file system. W e implemen ted this drive in RAM using the kernel mo dule nandsim. Nandsim creates a virtual flash device that can be moun ted as any flash-based file system. W e wrote a discrete ev ent simula tor that writes, ov erwrites, and deletes files on the phone’s storage, which is simply a moun ted directory on our simulation computer. Our real-life Android phone usage, describ ed in Section 3.2, w as used to generate all the probability distributions for file creation, mo difica tion, and deletion. After a w eek of logging all write activities on the phone, we computed the following t wo distributions for each Android writing application: the time betw een successive creations of tw o new files, and the t yp e of file to create. A file type is defined by its lifetime, a distribution o v er the perio d betw een opening a file for write, a distribution ov er the num b er of ch unks to write to a file eac h time it is opened, and a distribution ov er the ch unks of a file that indicates where the writes will o ccur. Additionally , we implemented a secret writer that op erated alongside the sim ulated writers. It infrequen tly wrote a one-c hunk secret message, waited until a new blo c k was al- located, and deleted the secret message. 1 W e logged the time b efore and after we op ened the file to write the secret message, and the time it was deleted. By cross-referencing this with our blo c k allo cati on information, we determined to which blo c ks the secret was written, and the time when these blo c ks were reclaimed thu s erasing the secret. In our Y AFFS implementation, w e measured the rate of block allo cations, which allo wed us to compute the addi- tional cost of Ballo oning as follows. The block allo cation rate tells us directly the rate that ch unks are written to the flash device. Data can b e written from t wo sources: the actual data written by the sim ulator, and data copied b y Y AFFS’s garbage collection mechanism. Since we are using fixed write distributions, the exp ected rate of writes from the sim ulator is identical b et w een exp erimen ts. Therefore, the observed disparity in blo c k allo cation rates reflects ex- actly the additional writes that are required by our space filling application to achiev e secure deletion. Figure 6 (cf. Figure 3) sho ws Y AFFS block allocations when using our ballo oning application. W e see that a s the range of possible blo c k allo cation s shrinks considerably , the sequen- 1 Non-immediate deletion was done to av oid having an erase header get collo cated with file data, since Y AFFS considers erase headers as live data until all other traces of the file are remo ved from the medium. 0 2 0 4 0 6 0 8 0 1 0 0 1 2 0 1 4 0 Time (hours) 0 2 0 0 4 0 0 6 0 0 8 0 0 1 0 0 0 1 2 0 0 1 4 0 0 Allocated block number Figure 6: Y AFFS’ block allo cations ov er time on a sim ulated Android phone running our ballooning application. 0 5 0 1 0 0 1 5 0 2 0 0 2 5 0 3 0 0 3 5 0 4 0 0 4 5 0 Block allocations per hour 0 5 1 0 1 5 2 0 2 5 Median time for secret erasure (hours) Figure 7: Scatter plot of av erage block allocations p er hour and median secret erasure time in hour different ballooning sim ulation with a v ariety of parameters. tial allocation strategy b ecomes mu ch more erratic, and the block reallo cation p eriod decreases. Ro ws in Figure 6 that con tain no allocation activit y corresp ond to erase blo c ks that ha ve now b een assigned junk files. T o quan tify the b enefit of our application—that is, how promptly the secure deletion of sensitive data o ccurs—w e measure the exp ected time sensitiv e data remains on the storage medium. W e calculate this measuremen t using our secret writer that p eriodically writes one block secrets on to the medium and then deletes them. W e then compute how long the written secrets remained on the device. Our application’s parameters are the size of the junk files, the lo wer threshold on the file system’s free space when junk files are deleted, and the upper threshold when junk files are created. These v ariables affect the total exp ected free space on the partition during execution, whic h will b e in the range defined by the thresholds. This is typica lly , though not al- w ays, b et ween the low er threshold and the size of one junk file. The amoun t of free space on the drive is what affects both deletion time and the block allo cation rate. T o get an idea of how these parameters are affected, we ran our sim- ulation for different parameters and computed the median F ree space Block allo cs Ratio (erase blo c ks) per hour No ballo oning 32 . 57 ± 1 . 13 1 250 52 . 54 ± 4 . 43 1 . 61 50 137 . 47 ± 26 . 92 4 . 22 25 196 . 00 ± 19 . 03 6 . 02 10 325 . 37 ± 36 . 84 9 . 99 T able 3: Blo c k allocations per hour for different configuration parameters. The ratio column is the prop ortion with regards to not using the ballooning application. erasure time and blo c k allo catio n rate. Figure 7 shows the result of this exp erimen t, which is a scatter plot with the median deletion time on the Y-axis and blo c k allo cations per hour on the X-axis; each p oin t on the plot sho ws the results from one of our sim ulations. W e see from the fig- ure that these tw o quantities are inv ersely prop ortional. As the blo c k allocations rate increases—due to less free space and thus more frequen t garbage collection—the time secrets remain on the device decreases. W e selected some represen tative configuration parameters and in v estigated them furth er. T able 2 sho ws measuremen ts of the deletion time distribution (measured in hours) includ- ing the minim um, median and maximum measures. Eac h ro w of the table corresponds to a different amoun t of free space (measured in the expected n umber of free erase blocks) as affected by using a sp ecific parameter set for our ballo on- ing application. F or each parameter set, the simulation was run eight times; the results were av eraged and the 95% con- fidence interv als were computed. W e observ e that by lea ving still 250 blo c ks free, corresp ond- ing to 15% of the drive’s capacit y , we get muc h b etter secret erasure times than if ballooning is not used, and in the ex- treme case of 10 free blo c ks, half the secrets are deleted in an hour and a quarter. Since each run of the simulation uses identical write proba- bilit y distributions, we hav e shown that limiting the driv e’s spare capacit y m ust result in more frequen t and less o ptimal garbage collections. This is measured as the rate of block al- locations, and in particular, the ratio b et ween the exp ected rate and the observed rate represents the scale of the addi- tional cost of our application. T able 3 shows the results for block allocations (abbreviated as allo cs) p er hour using the same selected parameters for our program as with T able 2. W e see from T able 3 that limiting the av ailable space signif- ican tly impacts the blo c k allo cation rate. The first step, at 250 blo c ks free, has only a 61% increase in blo c k allo cations and reasonably fast deletion. How ev er, achieving deletion in less than an hour requires muc h more frequent blo c k allo- cation. In the next section, we lo ok at how increased blo c k allocations affect the device wear in terms of flash memory and battery consumption. 4.5 W ear and T ear The primary drawbac k of our approach is the additional w ear that increased erasures put on the mobile phone, b oth in terms of damage to th e flash memory and pow er consump- F ree space P ercentile Measurements (erase blo c ks) 1st 50th 90th 95th 100th No ballo oning 40 . 18 ± 3 . 93 48 . 76 ± 1 . 32 55 . 88 ± 2 . 24 56 . 99 ± 2 . 37 58 . 93 ± 2 . 32 250 7 . 92 ± 1 . 62 15 . 06 ± 1 . 51 22 . 82 ± 1 . 68 23 . 77 ± 1 . 61 25 . 03 ± 1 . 29 50 0 . 08 ± 0 . 03 4 . 51 ± 0 . 57 8 . 37 ± 0 . 69 9 . 28 ± 1 . 03 10 . 54 ± 1 . 41 25 0 . 06 ± 0 . 05 2 . 36 ± 0 . 32 5 . 24 ± 0 . 81 6 . 25 ± 1 . 20 9 . 59 ± 1 . 79 10 0 . 02 ± 0 . 01 1 . 26 ± 0 . 18 3 . 14 ± 0 . 27 3 . 81 ± 0 . 43 17 . 42 ± 11 . 29 Purging 0 0 0 0 0 T able 2: Deletion time in hours for different configuration parameters. F ree space Expected minimum (erase blo c ks) lifetime (years) No ballo oning 55.1 250 34.1 50 11.7 25 9.1 10 5.5 T able 4: Exp ected minimum device lifetime at v arious blo c k allocation rates. tion. If this approach significantl y reduced the phone’s life- time or battery l ife, then it w ould be a concern for adoption. W e therefore p erformed exp erimen ts to inv estigate this. The additional w ear is directly prop ortional to the increase in the block allocation rate, and inv ersely prop ortional to the lifespan. W e con vert the blo c k allocation rate into an expected lifetime in years using 1571 erase blo c ks av ailable on the Android’s data partition a nd the very conserv ativ e es- timate of 10 4 erasures p er block. (Recall that a typical flash erase blo c k can handle b et ween 10 4 and 10 5 erasures [15]). T able 4 shows the plot of the exp ected minimum lifespan of an Android phone running contin uously at v arying blo c k allocation rates. W e see that device wear is not a concern ev en with our conserv ative estimate of blo c k lifetime. A device running without our applica tion can expect a lifespan of almost 6 decades—well b ey ond the replacemen t perio d of mobile phones. Even running our application with the most aggressiv e parameters still results in a lifetime of more than 5 years. W e observ e there exists a trade off betw een wear on the device and secure deletion, and so the user can select their desired device lifespan to tune their security parameter. T o test if ballo oning has acceptable p o wer requirements, we analyzed the p o wer consumption of write op erations. W e measured the battery level through the Android API, whic h giv es its current charge as a p ercen tage of its capacit y . The experiment consisted of contin uously writing data to the flash memory of the phone in a background service while monitoring the battery level in the foreground. W e mea- sured how muc h data must b e written to drain 10% of the total battery capacit y . W e ran the experiment four times and a veraged the result. The resulting mean is within the range of 11 . 01 ± 0 . 22 GB with a confidence of 95%, corre- sponding to 90483 full erase blo c ks w orth of data. Since this w ell exceeds the total of 1570 erase blo c ks on the Android’s data partition, w e are assured our exp erimen t must hav e erased the blocks as w ell as written to them, thus mea suring the cost of erasure. Ev en using the most aggressiv e bal- looning strategy , where 325 . 37 blo c ks are allocated an hour, it will still take 11.5 da ys for the ballo oning application to consume ten p ercen t of the battery . F urthermore, by lo ok- ing at the built-in battery use information, we learned that the testing application was resp onsible for only 3% of bat- tery usage , while the Android system accoun ted for 10% and the display for 87%. W e conclude that ballooning’s p o w er consumption is not a concern. 5. KERNEL-SP A CE SECURE DELETION Our second solution for secure deletion is at the k ernel lay er, where we mo dify the Y AFFS file system. This mo dels the scenario where a mobile phone user is willing to install a custom kernel for their mobile phone and has sup er-user ac- cess to the hardware. Our goal is to provide a simple, easily auditable, and small change to the file system to achiev e secure deletion of all deleted data without additional user action. The principle b ehind NAND flash programming is that an erasure sets all bits to the v alue of binary one, and program- ming simply selects some bit p ositions to instead hav e the v alue of binary zero. It is not p ossible to program a zero into a one, as this op eration requires erasing the corresponding erase blo c k. Programming a flash ch unk multiple times be- t ween erasures is kno wn as multiple pr o gr amming . The orig- inal version of Y AFFS (Y AFFS1) used multiple program- ming to set a deleted flag [3]. When a ch unk w as deleted, it w as reprogrammed so this flag w as set to zero, ob viating the need to p erform reverse lo okups in memory data structures to determine which c hunk s should b e copied during garbage collection. This techniqu e was remov ed in Y AFFS2 to be more p ortable for flash memory that do not p ermit m ultiple programming. Our solution is to use the Y AFFS1 tec hnique of multiple programming to instead rewrite the entire ch unk’s conten ts to zeros, thus remo ving the data from the system. Since the Android’s hardware supp orts multiple programming, p orta- bilit y is not a concern for the patc hed kernel. This solution requires sup er-user permissions to install a new Y AFFS ver- sion. It is attractive b ecause it requires only a tiny change to Y AFFS to enable guar ante e d imme diate secure deletion without causing an y additional w ear on the device. Figure 8 sho ws an example of how zero o verwriting remo ves sensitiv e information. This solution may still leak information through adv anced forensic techniques, p erhaps allowing an observer to deter- mine ho w recently a gate was set to zero, thus indicating t1 01 10 01 01 01 00 1 11 00 10 10 11 10 0 t0 11 11 11 11 11 11 1 11 11 11 11 11 11 1 t2 00 00 00 00 00 00 0 11 00 10 10 11 10 0 t3 11 11 11 11 11 11 1 11 11 11 11 11 11 1 er as e blo c k c h u n k c h u n k Figure 8: The state of an erase block at different times. t 0 is the initial state of the memory . t 1 is the state after some c hunks hav e b een written to the memory . t 2 shows how we can select one ch unk to b e written ov er with zeros, while the data remains on the other ch unk. t 3 shows the memory after erasing the entire erase block, returning it to the initial state. whic h bits were simultaneously reprogrammed. As analog forensics on flash memory are outside the scop e of this pa- per, we leav e this inv estigation as future work. The b enefit of this solution is that it requires no block era- sures to delet e information. All data is immediately remov ed when it is no longer needed, and the flash hardw are need not erase an y additional blo c ks to achiev e secure deletion. Therefore, there is no additional wear on the device itself— except for the minuscule voltage required to program the c hunk to contain only zeros. 5.1 Implementation Our change to Y AFFS is less than a dozen lines of C co de, and is contained mostly in the yaffs_chunk_del() function. This function handles the deletion of a ch unk from interna l memory structures, and is inv ok ed whenever a ch unk is no longer needed b y the file system, suc h as deleting a file, trun- cating it, or o verwriting a part of it. W e enhance the method to ov erwrite the entire deleted ch unk with zeros, using the same technique used to set the deleted flag in the tags— whic h is also implemen ted in the same function and used when the device is mounted as a Y AFFS1 drive. The other c hange is in the flash write function, where we remov ed a k ernel oops—the kernel equiv alent of a segmen tation fault— that prohibited empty ch unk tags. 5.2 Experimental Evaluation W e implemented our approach and tested its correctness by writing information, deleting it, and then searching the raw memory for the information using grep and hexdump . Ra w data was collected from the NAND simulator b y unmounting /dev/mtdblock0 (the device that cor resp onds to our sim ula- tor) and using the program dd to cop y the full con tents. Raw data was collected and examined from the Android phone using the technique describ ed in Section 4.1. Our deletion tests consisted of creating a file with some sen- sitiv e information and then erasing it different w ays. W e tested the following: a deleted file, a file completely o ver- written, a file partially ov erwritten, a file completely trun- cated, and a file partially truncated. The tests using partial truncation and o v erwriting alwa ys erased the entire sensi- tiv e part of the file. T ests were done using blo c k-aligned and blo c k-unaligned ov erwriting and truncation. W e first ran our tests using the standard version of Y AFFS, ensur- ing that the data was still recov erable. In each test, the sensitiv e data is completely erased from the file system, but remains accessible b y unmoun ting it and reading the raw data. Using our mo dified version of Y AFFS, we found that the information was irrecov erable from b oth the file system and the underlying flash medium immediately after running the deletion tests. A trade off with this solution is that deleting or truncating files is a linear operation in their siz e, as the zero o verwriting happens in the foreground. It is also w asteful when a c hunk is ov erwritten shortly b efore the en tire erase block is erased. It would b e p ossible to write a larger Y AFFS patch that main tains a list of blo c ks that need to b e zero ov erwritten, with a sanitization daemon running in the background; this approac h is used to provide secure deletion to the ext2 file system [1]. Care w ould be need ed to ensure that sanitization is not p erformed if the erased blo c k has b een erased (and new data added) since it was queued for sanitization. 6. RELA TED WORK Lee et al. [10] presen t a secure deletion approach for Y AFFS using encryption. They encrypt every file, and include the corresponding encryption k ey in every file header written to the file system. Secure deletion is th us a chiev ed whenev er all the headers for a file are deleted. They propose c hanging the deletion co de to force deletion of header blocks containing file keys. Their approac h is elegan t in that files are seam- lessly encrypted and decrypted b y their proposed c hanges to the Y AFFS file system, and it reduces the problem of rapid secure deletion to the problem of collocating headers for the same file. They collo cate headers using an in-memory prefix- tree based on the file id, where all file headers on a leaf no de will reside on the same blo c k. A leaf no de is split into tw o nodes when it is half full. It is difficult to compare their approach with ours in exp eri- men ts b ecause their approach was not implemented. More- o ver, despite detailed algorithms, they had not considered con tracting paired leaf no des when they are sparsely full; o ver time the file system space for header data might spra wl as tree growth is never curtailed. They simulated their al- gorithm by assuming files were mo dified at most twice; our examination of Android phone data found that a third of all ch unks were file headers, suggesting muc h more frequent modifications. Since their strategy is based on treating head- ers sp ecially , it is imp ortan t to mo del them realistically . They intend to delete file header blo c ks each time a file is remo ved; ho wev er our data indicates that Android phones delete nearly 10000 tin y cache files a da y—securely delet- ing each would result in the frequent creation of bad blo c ks. W e susp ect it would b e b etter to delay and batch deletions, and instead of collocating file headers based on arbitrary file id, use attributes that may predict similar lifetimes, such as creation time or file o wner. Finally , they add secure deletion b y changing an existing file system, but do not exa mine how their ch anges effect the original design decisions of the file system. Device wear concerns from header collocation and increased erasures were not discussed in their pap er. W ei et al. [16] hav e considered secure deletion on flash stor- age in the context of solid state drives (SDDs). An SSD mak es use of a Flash T ranslation Lay er (FTL). This la y er allo ws a regular blo c k-based file system (such as F A T) to be used on flash memory by handling the nuanc es of erase blocks opaquely through the FTL’s la yer of indirection. This la yer has the same effect as a log-structured file system, where the FTL writes new entries at empt y lo cat ions, so old en tries remain until the ent ire erase blo c k can b e reclaimed. They executed traditional blo c k-based approaches to secure deletion and determined that they do not prop erly sanitize data on flash storage. They also show ed alarmingly that some built-in sanitization methods do not function correctly either. They propose to address this concern b y having flash hardw are manufacturers mak e use of zero ov erwriting, and add it into the FTL hardw are. They state that circumv en t- ing the problem of a lack of secure deletion requires chang es in the FTL, but depending on how the FTL i s implemented, our user-lev el approac hes ma y als o succeed similarly without requiring hardware changes. 7. DISCUSSION AND FUTURE WORK W e presented three solutions for secure deletion on Y AFFS file systems: purging and ballooning at the user-level, and zero ov erwriting at the k ernel lev el. The kernel-lev el solution is the most effective, and suitable for an y user who is willing to apply a small patc h to their file system. B allo oning is useful for users who wish to guard their lo cation priv acy by not having their phones likely to record more than a user- specified time interv al of lo cation data. Purging is useful for users who wish to b e assured that some deleted data has been securely erased from their phone. Generalizing our Appr oach. Purging will work for any log-structured file system provided both the user’s disk quota is unlimited and the file system alw ays p erforms garbage collection to reclaim even a single ch unk of memory b efore declaring that the drive is unwritable. Ballooning’s utilit y v aries with the implemen tation details of the underlying file system. F or example, JFFS is another log-structured flash file system that uses a linear blo c k al- location sc heme. This assures “perfect” wear levelling; the erasure count of any tw o blocks on the medium will differ b y at most one. Consequen tly , filling the drive to near ca- pacit y will result in thrashing where all the stored data is con tinually b eing shuffl ed. Zero ov erwriting will work for any type of file system, pro- vided that b oth the underlying flash memory p ermits the second programming to o ccur, and the file system will never attempt to read memory that it has already deleted. Note that this is not the case in Y AFFS1, where deleted ch unks are re-read during garbage collection to determined if they had b een marked (through reprogramming) as deleted. The UBI Flash Interface. Recentl y , Nokia has developed a new flash interface, called Unsorted Blo c k Images (UBI), whic h allows in-place up dates and remov es the concerns of both w ear-levelling and bad blo c k detection. UBI exp oses the following in terface based on logical erase blo c ks (LEBs): read and write to a LEB, erase an ent ire LEB, and atom- ically update the con tents of an en tire LEB (i.e., in-place edits at the erase blo c k lev el). It also allows dynamic cre- ation of UBI partitions using unallocated LEBs. It is neither possible for an LEB to b ecome bad, nor is wear-lev elling a concern for LEBs. Underlying this inte rface is a simple mapping from LEBs to physical erase blo c ks (PEBs), where PEBs correspond to actual erase blo c ks on the flash medium. W ear monitoring is handled b y maintaining a tally of the erasures at the PEB lev el, and transparen tly remapping LEBs when necessary . Remapping also o ccurs when a bad blo c k is detected. De- spite remapping, a LEB’s numerical iden tifier will remain constan t regardless of c hanges to its corresp ond ing PEB. Ballooning achiev ed secure deletion by artificially reducing the size of the flash partition, thus reducing the p eriod b e- t ween a blo c k’s allo cations. UBI exp oses the ability to dy- namically create partitions from unused logical blo c ks in its block p o ol. It is theoretically p ossible for UBI to dynami- cally grow or shrink the size of a partition—were it to know whic h blo c ks are not currently b eing used b y the file system abov e it, and were the file system to know that its size is v olatile. As future work we plan to design and implemen t dynamic- resizing capabilities in UBI that would also require minimal c hanges to non-UBI-a wa re file systems like Y AFFS. These file systems view the medium as a contiguous range of n um- bered blo c ks, along with a mapping from blo c k num bers to states—either goo d or bad. A UBI-enhanced Y AFFS imple- men tation might allow for dynamic resizing of its partition size using the bad blo c ks map. UBI will manage how many erase blo c ks are giv en to each partition, p ermitting the op- timal size of each file system to b e controlled by UBI. The slac k space it c ho oses is based on the trade off b et ween device w ear and secure deletion. UBI would also b e able to intel- ligen tly monitor the drive, for example observing its write and erasure rate. It may also giv e some partitions fewer free erase blo c ks than others, when the former are b eing used explicitly to store sensitive files such as encryption k eys. 8. REFERENCES [1] Steven. Bauer and Nissank a. B. Priyan tha. Secure Data Deletion for Linux File Systems. Usenix Se curity Symp osium , 2001. [2] Remy Card, Tho dore Ts’o, and Stephen Tweedie. Design and implementation of the second extended filesystem. [3] Charles Manning. How Y AFFS W orks. 2010. [4] Simson L. Garfinkel and Abhi Shelat. Remem brance of Data Passed: A Study of Disk Sanitization Practices. IEEE Se curity and Privacy , 2003. [5] Go ogle, Inc. Go ogle Nexus Phone. [6] GNU Priv acy Guard. gpg(1) - Linux man page. [7] Adrian Hunter. A Brief Introduction to the Design of UBIFS. 2008. [8] Nikolai Jouko v, Harry Papaxenopoulos, and Erez Zadok. Secure Deletion Myths, Issues, and Solutions. AC M workshop on Stor age se curity and survivability , 2006. [9] Nikolai Jouko v and Erez Zadokstony . Adding Secure Deletion to Y our F av orite File System. pages 63–70, 2005. [10] Jaeheung Lee, Sangho Yi, Juny oung Heo, and Hyungbae Park. An Efficient Secure Deletion Scheme for Flash File Systems. Journal of Information Scienc e and Engine ering , pages 27–38, 2010. [11] Av antik a Mathur, Mingming Cao, Suparna Bhattac harya, Andreas Dilger, Alex T omas, and Lauren t Vivier. The new ext4 filesystem: current status and future plans. 2007. [12] Colin Plumb. shred(1) - linux man page. [13] Christina P ¨ opper, David Basin, Srdjan Capkun, and Cas Cremers. Keeping data secret under full compromise using p orter devices. In Computer Se curity Applic ations Confer enc e , pages 241–250, 2010. [14] Mendel Rosenblum and John K. Ousterhout. The Design and Implementation of a Log-Structured File System. ACM T r ansactions on Computer Systems , 10:1–15, 1992. [15] Radu Stoica, Manos Athanassouli s, Ryan Johnson, and Anastasia Ailamaki. Ev aluating and Repairing W rite Performance on Flash Devices. In Pr o c e e dings of the Fifth International Workshop on Data Management on New Har dwar e , DaMoN ’09, pages 9–14, New Y ork, NY, USA, 2009. ACM. [16] Michael W ei, Laura M. Grupp, F rederick M. Spada, and Steven Swanson. Reliably erasing data from flash-based solid state drives. In Pr o c e edi ngs of the 9th USENIX c onfer ence on File and Stor age T e chnolo gies , Berk eley , CA, USA, 2011. USENIX Asso ciation. [17] David W o odhouse. JFFS: The Journalling Flash File System. In Ottawa Linux Symp osium . RedHat Inc., 2001.