File systems for flash devices

Transcription

1 File systems for flash devices Christian Egger Institut für verteilte Systeme James-Franck-Ring 1 Ulm, Germany christian.egger@uni-ulm.de ABSTRACT File systems for flash devices have been in demand since this storage has become attractive for general purpose usage. The technology is now widespread. Flash based storage devices exist since the mid 80 s [15] and have long been known exclusively for their use in storing small data like PC BIOSes and the firmware of embedded devices. In these cases the flash chip s content has been memory mapped almost always into a processors adress space and treated as a read-only area during normal usage. Nowadays flash is also used for dedicated read-write operation since the maximum capacity of this technology has seen a huge increase in size and thus opened it to be used in many different areas like USB drives, a larger read-writeable area for embedded devices and eventually solid state disks (SSDs). However, pure flash storage behaves very different in comparison to normal rotating- disk block devices. Average seek times are several magnitudes better than with common hard disks. There are also a number of drawbacks, for which two approaches to solve them exist: A translation layer to make the memory behave like a normal block device and special file systems. Those file systems and also the changes to traditional file systems for use with flash based solid state disks (SSDs) shall be discussed in this paper. 1. INTRODUCTION TO FLASH Flash technology devices are a kind of electrically erasable programmable read only memory (EEPROM). Flash memory operates differently in comparison to well known block devices such as hard disks or floppies. Three basic operations exist: read, write and erase of memory regions. Flash regions need to be erased before writing to them. Additionally, the size for the memory regions for the three operations needn t be the same. Erase blocksize is usually 64, 128 or 256 KiB and write or read granularity depends on the technology and ranges from bit wise to 2 KiB or more. The most important fact is however that erase cycles are limited a certain number of usually around counts before an erase block finally becomes defective and can t be written to any further. After deleting an erase-block, all its containing data is set to logical ones (0xffff) and when writing to it, individual bits get cleared and set to zero accordingly. Bits can only be set (to one) by erasing the block again, successively clearing bits (for example configuration flags in a bit-mask) is possible with some types of flash. 2. COMMON FLASH TECHNOLOGIES Two basic flash technologies exist, NOR and NAND flash. 2.1 NOR flash NOR flash is very expensive and available in lower densities than NAND. Capacities are in the range of up to 512MBit [7] or even 2GBit. Erase and write times are much worse than that of NAND devices and range from 0.1 to 5 seconds for erasing blocks and seconds for writing data [6]. Data is random accessible byte- or word-wise via an address bus. Random access speed is very good, for example Intels flash line StrataFlash can be operated at up to 58MHz. The maximum addressable capacity is limited by the number of available address lines present on the device. This access scheme is the same as with EEPROM devices and makes it possible to connect NOR chips directly to a processor s bus to access data and even execute code in place. NOR devices allow multiple successive clearing (0x1 to 0x0) of individual bits in a given area without intermediate erasure of the surrounding block. This type is mostly used in embedded devices. 2.2 NAND flash In contrast to this NAND flash offers much higher densities at a better price. However, data is accessible through a command-driven interface which offers every command such as reading, writing or erasing blocks. Write and reads happen at a granularity of usually 2KiB. Successive writes without intermediate erase cycles are usually not possible. Two different subtypes of NAND exist: SLC (single-level-cell) and MLC (multi-level-cell) NAND. A cell is the basic storage unit of flash technology. SLC offers one bit of information and MLC offers commonly two bits (4 states) per such a unit. MLC thus has a higher storage desity at the expense of less endurance, lower speed and higher power consumption. SLC memories are typically found in expensive highend server-grade SSDs and high speed memory cards[17]. 2.3 Limitations and differences [12, 6] Different erase and read/write granularity

2 Erase blocksize is a power of 2 and typically 128 KiB whereas read/write operations happen with a granularity of usually 2KiB (NAND) or byte/word-wise (NOR). In case of NOR- Flash, even bit-wise clearing of data is possible Limited number of erase cycles and bad blocks Erase blocks on flash devices have a limited number of erase / write cycles, typically 10k-100k for NAND and 100k-1G for NOR flash. As soon as this number is exceeded blocks may become bad and must not be used any more Out-of-place writes Each block of usually 2KiB is embedded in a much bigger erase-block of usually 128 or 256 KiB. If data should be written in-place the contents of the surrounding erase block would need to be saved temporarily before it s erased. After updating the changed page the whole data would be written back. However this is not an optimal strategy as an intermittent power failure would cause a data loss in the whole erase block Overwriting Some NAND and all NOR devices support overwriting. This allows memory areas to be programmed more than once. This is to be seen as an assertion about a guaranteed result of such an operation by the vendor. Overwriting is always a one-way operation, because only a transition from high to low (1->0) is possible between erase cycles. NOR chips are guaranteed to be programmable completely bitwise. The situation with NAND is more complex: Older NAND devices supported overwriting (for the sake of updating the spare area) and with current SLC technology that uses 2KiB pages usually 4 overwrites to the same page are guaranteed to be safe. This has applications with FTLs because 4 512Byte sectors can be written to a single 2KiB page consecutively. Since the transition from 512 byte pages to bigger sizes of 2KiB+, MLC NAND which strongly focus on speed, density and price does not allow overwrites any more NAND: spare areas NAND flash technology offers a spare area of typically 16 bytes per 512 byte page or 64 bytes per 2KiB page so that a block is typically 128KiB + 4KiB (64 pages * ( )). These regions are not different to the normal memory area and also get cleared when their surrounding block is erased. Spare areas are intended for storing information like page based ECC and deletion markers or bad region markers for whole erase blocks. Spare areas are not assured to be visible as newer NAND chips may hide these additional regions for implementing error correction within the flash controller already NAND: sequential writes within erase blocks NAND technology that uses a page size of 2KiB also restricts that pages within erase block boundaries are written in strict sequential order between each erase cycle. 2.4 Approaches to using flash Two approaches to circumvent the drawbacks of flash devices exist: Common file systems on top of a flash translation layer (FTL) and file systems specifically designed for flash devices Flash translation layer A flash translation layer (FTL) tries to hide all differences of flash to the upper layer and implements handling of bad blocks, wear-leveling, erase cycling and allows read/write operations 512-byte wise again. On top of such an FTL every common file system that is intended for normal hard disks can be used. A simple flash translation layer would emulate a block device by mapping each block 1:1 to the flash and therefore updating data in place. A procedure to accomplish this would be read, modify, erase, write back. This means reading a whole erase block into memory and updating the page to be written, erasing the block and finally writing the data back to the block. However, especially for NOR flash, both erasing and programming is very time-consuming and most importantly not atomic and therefore unsafe. An intermittent power failure would cause data loss. Also by this simple approach bad blocks are not handled, wear is not distributed equally and write performance is low. More sophisticated FTLs such as TrueFFS, ExtremeFFS or UBI 1 implement a number of techniques to sustain performance, endurance and reliability Flash file systems Instead of combining common non-optimized file systems with FTLs file systems designed specifically for flash can be much more efficient. Implementations exist since the early 1990s, such as Microsoft s FFS2 [13] and since 1999 for the Linux kernel with Axis Journaling Flash File System (JFFS). 3. CONCEPTS OF FLASH FILE SYSTEMS All flash file systems share at least some of the following concepts. 3.1 Nodes A Node is a contiguous structure on the file system that contains at least metadata and maybe also data. This structure fits the needs for flash as it makes writes happen at a single place. 3.2 Log structure Wear distribution and erase-modify-write cycles are challenges that can generally be solved by writing data logstructured [14] or more generally out of place. A truly log structured file system such as JFFS treats the device as a strict circular log where writes always go to the end of the log. Nodes contain both data and metadata such as version and node number. If nodes are replaced the now invalid node is not altered by the operation. This results in multiple versions of a node that co-exist with different version numbers in the log. This implies that file system structures are kept in RAM as well as the list of empty pages and pages with invalid data. It is clear that the mount process needs to rebuild all those structures by reading the log from start to end to determine the current state of such a file system. 3.3 Compression Some of these flash file systems support compression. Most often zlib is used but other compression algorithms may also be supported. This includes for example LZMA for better 1 UBI shares some features but is not a flash translation layer

3 compression ratios or LZO which focuses mainly on decompression speed [2]. Read only file systems have an advantage because their structure is fixed and write granularity is not a matter. This makes it possible to use a much larger block size than writeable file systems to achieve a better average compression ratio. 3.4 Garbage Collection: reclaim free space On a pure log structured file system where garbage collection never ran, the head of the log is at the device s start and its tail keeps growing towards the end of the device. After that has happened, no space is left and the log can t grow any further. All pages on the device now contain either valid data or data that has been superseded by nodes later in the log. The latter pages can be reclaimed and transformed into empty space again by performing garbage collection [GC]. The goal of garbage collection is to obsolete all pages within an erase block where it s intended to be written to next so that the whole block can be reclaimed. In case the FS is truly log-structured this is the log s head. The erase block containing the head is examined. If all containing pages have been invalidated by later nodes it can be erased and reclaimed. If the erase block still contains valid nodes, they must be invalidated by copying them over to the end of the log. If no space at all is left this wouldn t be possible. This is why a log structured file system needs to retain a minimum number of free blocks and garbage collection needs to run when a certain treshold is reached. 3.5 Wandering trees Wandering trees are used to represent an index directly on flash [3]. This concept is very similar to the tree structure of ext2 except that writes happen out-of-place. If a new inode is written out- of-place, all inodes formerly pointing to it need also be written to correctly point to the copy-on-write inode at the end of the log again. This happens recursively until the root inode has also been updated. If node X was on level n in the hierarchy the chain from root-node to the last node which points to X needs to be updated. After that operation is complete the complete chain of nodes starting from the root node down to the leaf node wandered to a new position. 3.6 Write back instead of write-through Write back is a strategy most suitable for NAND that does not allow overwriting. This strategy accumulates dirty data (i.e. non-written cached flash pages) until a time or size treshold is reached after which everything is written to the flash in a single operation. This decreases the frequency of updates and reduces fragmentation. It must be assured that enough space is left to synchronize all dirty pages successfully which is complicated if the file system uses compression. 3.7 Mount scanning All log-based file systems suffer from a certain amount of scanning when mounting is performed. This is due to copyon-write which every flash file system uses. This is the reason why some locations cannot be fixed and their location may not be known at mount time. In the worst case these structures have to be built by sequentially scanning the whole device and building a representation of the file systems state in RAM. For efficiency and wear leveling trade offs, even file systems that implement an on-flash index have to rely at least to some extent on information, that needs to be gathered by scanning a certain area of the device. 3.8 Snapshots A log-structured file system may easily implement snapshotting or sometimes called checkpointing. A snapshot can contain both data and metadata which is obvious because both are continually written to the log. Checkpointing allows for a faster startup of the file system when it is implemented in a way that allows to read less data on mount to obtain all information about the file systems state. 3.9 Execute in place Execute in place [XIP] functionality can only be used with NOR flash and is interesting for embedded devices to lower RAM usage by mapping executables located on the flash directly into the address space without loading them into RAM. The mapped area can then be executed directly. However compression is not possible for obvious reasons and executable areas might need proper alignment on flash which may also waste flash space. Approaches exist for read-only file systems, that omit compression for single pages only to allow XIP Error correction Flash devices, especially NAND chips, may contain bad blocks and also infrequent bit errors may occur. Software has to deal with this. 4. OVERVIEW OF FLASH FILE SYSTEMS FOR LINUX Linux already includes a number of flash file systems and with UBIFS and LogFS two new flash file systems have found their way into the kernel since JFFS The journaling flash file system was the very first flash file system for Linux and has been developed for Linux-2.0 in 1999 by Axis Communications AB for use in their embedded systems[1]. It has also been supported and ported to Linux-2.2 by RedHat. JFFS is a strict log structured file system, i.e. writes always are appended to the end of the log. JFFS knows only one single type of structure, which is called jffs inode. This record contains headers for the metadata and may also contain data as a payload. A node may span an erase block boundary. JFFS has perfect wear leveling because its garbage collection strictly operates at the head of the log. Therefore it does also copy over the nodes in a complete erase block at the beginning of the head to the end of the log even if all of its containing nodes are valid. Especially when the file system becomes almost full, writes may always result in a GC run, that moves a big portion of all valid nodes around to free blocks after the end of the log. The simple GC implementation and its lack of support for hardlinks and compression in favour of simplicity were serious drawbacks for some use cases.

4 Table 1: True flash file systems in the Linux kernel Date Name Comment mainline? 1999 JFFS First flash file system for the Linux kernel discontinued 2001 JFFS2 Complete Redesign of JFFS by RedHat Linux YAFFS Yet Another Flash File System, optimized for NAND patch only 2005 YAFFS2 Optimized for new NAND type with 2 KiB pages patch only 2007 LogFS Directory index on media, focus on scalability Linux UBIFS Successor of JFFS2, works on top of UBI subsystem Linux Table 2: Comparison of flash file systems Name JFFS JFFS2 Yaffs Yaffs2 UBIFS LogFS RomFS CramFS SquashFS AXFS Application MTD 1 MTD 1 MTD 2 MTD 2 UBI both 3 both 3 BLOCK BLOCK NOR 4 Write support yes yes yes yes yes yes no no no no Mount time O(n) O(n) O(n) O(n) O(n) 5 O(1) O(1) O(1) O(1) O(1) RAM requirement O(n) O(n) O(n) O(n) O(1) O(1) O(1) O(1) O(1) O(1) Max file size?? 512MiB???? 16 MiB 2 TiB? Max page size 6 n/a n/a 512B >2KiB??? 4 KiB 1 MiB n/a Data compression no yes no no yes yes no yes yes a Directory indices 7 no no no no yes yes no no yes a Hard link support no yes yes yes yes yes yes no yes a 4.2 JFFS2 JFFS2 was developed as a complete redesign of JFFS by RedHat in 2001 to address all of the above mentioned drawbacks of JFFS[18]. It has initially been adopted in Linux and is probably still the most common flash file system for embedded devices that use a Linux kernel today. JFFS2 is mainly used with NOR-flash Log-structure and Garbage collection JFFS2 has a more advanced garbage collection than JFFS1 that does not implement the very strict log-structured approach of JFFS1. To prevent moving around pages unnecessarily, each block is treated on its own. However a block is continually written to in a log-structured manner until it is full. After that a new block is chosen based on dirtiness, usage and number of free blocks. To implement wear leveling a block gets selected from the clean list with a probability of each time garbage collection runs Mounting On mount a JFFS2 volume needs to be completely scanned once. When this is done CRCs of every node are checked and structures are built that hold all necessary metadata of the file system such as references to nodes and version numbers. After the scan is complete, the structures are further refined by discarding unreferenced inodes and invalid nodes. This process is repeated until no further inodes are discarded. A last run discards temporary information that can be retrieved again quickly such as version numbers in RAM which is not necessary for normal operation. 1 best suited for NOR devices 2 suited for NAND devices 3 both: MTD and block modes are supported 4 AXFS does not use Linux MTD layer 5 UBIFS has 0(n) and works on top of UBI which has O(n) 6 not applicable to NOR flash 7 Is the main file system index on media? 4.3 YAFFS Yet another flash file system has been developed to satisfy the need for a file system specifically suitable for NAND flash [9]. Two implementations exist often referred to as YAFFS1 and YAFFS2. The latter is compatible with newer 2KiBpage NAND chips and uses a stricter log- structured approach. YAFFS is very portable and can be used with Linux, uclinux and Windows CE and a mode named YAFFS direct interface exists to use it with other platforms Mount scanning YAFFS1 uses overwrites to spare areas to implement deletion markers which make the scan algorithm very easy: Every page contains information if it is valid. The situation where two valid versions exist is solved by a 2-bit serial number also recorded in spare areas. YAFFS2 is designed whith the most restrictive devices in mind and thus does not use overwriting to update spare areas Checkpointing YAFFS allows checkpoints to be written to flash that allow quick mounting. Checkpoints occupy complete erase blocks that contain the state of the file system which is normally represented in RAM. However unnecessary information, that can be obtained by lazy-loading later on during operation, such as file names, is omitted. The integrity of a checkpoint is ensured amongst others by two checksums. A checkpoint is only valid as long as the state of the file system does not change, i.e. it is best created just before shutdown. The next startup benefits from a quick mount. The medium must only sparsely be scanned then, because only every erase block s first page must be searched for a checkpoint marker which is quite fast compared to a full scan (For example, a 2GBit device has only 131k such blocks). Every operation that changes the file systems state checks if a checkpoint is present and erases that block. This is easy as checkpoints occupy only entire blocks.

5 4.4 LogFS LogFS focuses on file system size scalability and is suitable for mtd and block devices as well. To achieve scalability, it uses an on disk index almost identical to that of ext2 which differs as it is implemented as a wandering tree to be usable with flash. LogFS treats the directory index like normal file data and stores it as a special inode file on disk. Two anchor areas exist, where the location of the wandering root node is stored. This permits the root node to be locatable in O(1) when starting up without a need to scan the whole device like with indexless file systems[3]. 4.5 UBIFS and UBI UBIFS stands for UBI file system which works on top of UBI, a volume management layer for raw flash devices[5]. It s goal is to supersede JFFS2 in the long run. It shares some ideas with LogFS, such as an on-flash index and fixed locations which store the position of floating structures like journal and the index root node The UBI layer The unsorted block images layer is responsible for wear distribution, bad block management and scrubbing. UBI abstracts logical erase blocks [LEBs] from physical ones [PEB]. UBI allows only sequential writing to LEBs and does not use spare areas. The strictness of wear, i.e. the maximum allowed difference in the number of erases between erase blocks defaults to 4096 (suitable for NOR) but can be configured to a lower treshold for NAND (e.g. 256). Scrubbing is a technique that reads memory asynchronously and automatically detects and corrects bit errors in affected regions and refreshes them. At the moment, UBI volumes start up in O(n) which may improve in the future with UBI UBIFS Most importantly, UBIFS implements write back strategy and an on-flash index. The index is implemented as a wandering B+ tree that stores data only in its leaves. A smaller journal gathers updates until a commit writes all changes to the index at once. This reduces the frequency of updates to the index. Especially the higher nodes would be written with every change. UBIFS stores a non- changing superblock in the first LEB and every non-fixed position, e.g. of the index root-node and of the journal in the second and third LEB. This allows to mount UBIFS volumes in 0(1), because the index position is known and only a limited region must be scanned to replay the journal. 4.6 Read-only file systems ROMFS, CRAMFS, SquashFS and AXFS are read-only file systems of which the first three come included with the kernel. These file systems can be used on flash devices without problems even for implementations that support only block devices because Linux MTD ( memory technology device ) implementation offers a very simple flash translation layer that is very suitable for read-only operation in block mode. Nevertheless, some of these implementations cover MTD support specifically so that they are independent of the block support which may be missing in embedded devices. AXFS, the advanced execute-in-place file system is available as a patch and is different in that it does neither use the kernel s MTD nor block subsystem. Table 3: Read-only file systems in the Linux kernel Date Name Comment mainline? 1997 Romfs Tiny codebase CramFS Compressed ROM FS SquashFS Also with compression AXFS Focuses on XIP patch only Table 4: Comparison of CRAMFS & SquashFS [8] Feature Squashfs Cramfs Adressable file system space Max file size 2 TiB 16 MiB Max block size 1 MiB 4 KiB Metadata compression yes no Sparse file support yes no Exportable (NFS etc.) yes no dentries. and.. yes no uids/gids 32-bit 8-bit File ctime yes no ROMFS ROMFS was created in 1997 as the first read-only file system for Linux by Janos Farkas and supports both block and MTD devices. It is optimized for a very small footprint of both object code and file system size. It has been intended for use as an initial RAM disk for example on rescue floppies back in the time when space was very limited compared to today. ROMFS has only basic features but supports hard and soft links and fifo s. ROMFS has no support for compression CRAMFS CRAMFS most important improvement over ROMFS is compression. However it has still some limitations. Files must be less than 16MiB and the whole file system is restricted to < 256MiB + 16MiB (files need to start within the adressable space of 28 bits but can reach beyond that limit). The optional compression feature uses zlib which can be applied to file data 4KiB-page wise. The meta data structure is very terse and does not store time stamps. Endianness matters with CRAMFS file systems. Additionally, patches to add XIP support to CRAMFS have been available from Montavista for several years SquashFS SquashFS has been in development since 2002 and adresses most of the shortcomings of CRAMFS [Table 3: comparison with CRAMFS]. It comes included in Linux since version and uses zlib as default when compression is enabled but patches to enable LZMA, LZO, deflate and bzip2 support have also been available. SquashFS is widely used for two purposes where size matters most: Embedded devices and Linux live CDs. It is also suitable for archiving data instead of tar balls as squashfs volumes can be loop-mounted easily later on [8] AXFS AXFS has been developed since 2006 and focuses on execute in place [XIP]. XIP functionality in Linux prior to AXFS

6 Table 5: FS tuned for SSDs (ATA Trim) Name Comment in Linux since Ext4 Fourth extended FS VFAT FAT-12/16/ NILFS2 Log-structured FS BtrFS Copy-on-write FS GFS2 Global file system had been available only for CRAMFS until then. The maximum size of available NOR chips have already surpassed CRAMFS limit of 256MiB as well as growing needs demanded for bigger files than CRAMFS rather limiting maximum of 16MiB. AXFS allows individual pages to be XIP or not (and compressed). Before creating a XIP enabled volume, a user collects information about which pages need XIP by creating a normal volume and obtaining mmap() information from /proc/axfs at runtime. These results are then used to create an image that fits the usage s need best and offers a good trade off between fast application launches and good compression ratio[4]. 5. STANDARD FILE SYSTEMS Common file systems work with block devices and thus can only operate on top of a flash translation layer that is implemented for example in every solid state disk [SSDs]. File systems do not need to know if they work on top of an FTL. However, in 2009 a new ATA command was specified: ATA trim(). This makes it possible to notify the underlying FTL which memory regions are obsolete and may be recycled. Without this information, the FTL must assume that those blocks are valid and may needlessly copy and map them to other regions for wear distribution purposes. To benefit from a more efficient FTL, this notification has to be implemented in common file systems. This is of course only possible if a file system works directly on top of a device with a FTL. If there are other subsystem layers in between, a notification may be not possible any more. Most importantly this is the case for RAID where blocks of a RAID volume are independent of those of the individual devices. Up to now, at least Windows 7 and Linux supports ATA trim(). 5.1 Linux and ATA trim() Btrfs, vfat, ext4, gfs2 and nilfs2 support ATA trim() since October and November 2009 and the SCSI subsystem since December All other file systems do not currently support trim notifications, for example LogFS when running in block based mode. This functionality is implemented in the Linux kernel via the functions sb issue discard() and blkdev issue discard(). Autodetection for SSDs is possible but by default all SSD optimizations are currently disabled due to bugs in various firmware revisions of SSD disks. This has to be switched on by passing a parameter at mount (-o ssd). Using ATA trim on these devices is known to result in a performance drop. 5.2 NILFS2 NILFS2 is a new implementation of a log-structured file system which makes it a novelty as a Linux file system that is not intended specifically for MTD devices. 5.3 BtrFS BtrFS is a snapshotting, copy-on-write file system developed by Oracle. In addition to ATA Trim support it includes two special block allocator modes that are suitable for SSDs: ssd [10] and ssd spread [11]. The ssd block allocation scheme does not care about fragmentation and searches for a new contiguous block to be allocated. The ssd spread option tries harder to spread out allocations wider across the disk to find a memory region with no previously allocated blocks mixed in. Experience proved that some implementations don t handle allocation schemes with blocks that had previously been in use (and probably need an erase cycle) well. It has been observed that some of the lower end SSDs perform better when blocks are allocated this way. 6. WINDOWS SUPPORT Since Windows 7, ATA trim() is supported for FAT and NTFS file systems. Windows XP and Vista are neither supported nor does Microsoft intend to add it to these operations systems and users have to rely on 3rd party products. 6.1 ExFAT ExFAT is Microsoft s replacement for its aging FAT file system and depends on a flash translation layer. Until recently, it wasn t much widespread but this is subject to change since it hass been chosen as the designated successor of FAT by the SD Card Association for SDXC cards as the standard file system. The exfat specification is proprietary and Microsoft holds patents on it. FAT32 main limitations are its maximum file size of 4GiB and a maximum volume size of 2TiB. ExFATS releases these limitations and supports variable sector sizes between bytes and offers a (recommended) maximum file system and file size of both up to 512TiB[16]. 7. REFERENCES [1] Axis Communications AB. JFFS. [2] W. Bergmans. Summary of the multiple compression benchmark. data/summary_mf4.php, April [3] J. Engel. LogFS - finally a scalable flash file system. September [4] J. Hulbert. Introducing the Advanced XIP File System. Reprints-2008/hulbert-reprint.pdf, July [5] A. Hunter. A brief introduction to UBIFS. whitepaper.pdf, March [6] Intel. 2/4/8-Mbit SmartVoltage Boot Block Flash Memory Family Overview. com/design/archives/flash/docs/ pdf, September [7] Intel. NOR flash product line. developers.net/intelisdshowcase/view/2600, February [8] P. Lougher. SquashFS 4.0 documentation in Linux. linux tar.bz2, March [9] C. Manning. How YAFFS works.

7 HowYaffsWorks.pdf, May [10] C. Mason. Btrfs ssd allocation scheme: optimizations for seek free storage. mason/btrfs-unstable.git;a=commitdiff;h= e18e4809b10e6c9efb5fe10c1ddcb4ebb690d517, February [11] C. Mason. Btrfs ssd spread allocation scheme. mason/btrfs-unstable.git;a=commitdiff;h= 451d7585a8bb1b9bec0d676ce3dece e55, June [12] Micron. An introduction to [SLC-]NAND flash and how to design it in to your next product. tn2919.pdf, July [13] Microsoft. System for updating data stored on a flash EPROM based upon predetermined bit value of indicating pointers (patent). gov/netacgi/nph-parser?sect1=pto2&sect2= HITOFF&p=1&u=\/netahtml\/PTO\/search-bool. html&r=1&f=g&l=50&d=ptxt&s1= pn., October [14] M. Rosenblum and J. K. Ousterhout. The design and implementation of a log-structured file system. http: //citeseer.ist.psu.edu/rosenblum91design.html, July [15] Toshiba. Nand flash applications design guide. NandDesignGuide.pdf.pdf, April [16] Wikipedia. exfat. June [17] Wikipedia. Single-level-cell flash. June [18] D. Woodhouse. JFFS - The Journaling Flash File System. October 2001.