Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. COVER STORY LogFS sandra zuerlein, Fotolia Flash memory and the LogFS filesystem FRIEND OF FLASH Flash is now an everyday part of the Linux environment. The new LogFS filesystem will help you contend with the problems of flash memory. BY JAN KLEINERT AND ACHIM LEITNER F lash memory was once reserved nary filesystem. Responsibility for com- ent, the Linux kernel supports five FTL for embedded applications. Over municating with the device is placed variants in the memory subsystem. the course of the past few years, firmly in the hands of the hardware or Because filesystem blocks are far however, prices have fallen drastically the kernel. A Flash Translation Layer, or smaller than flash blocks, FTL optimizes for flash in the form of USB sticks, as FTL for short, was introduced to the ker- write access by collating changes to save well as the memory cards used in cam- nel around the year 2000. The layer han- deletion and write cycles, thereby im- eras, PDAs, cellphones, solid state dles the special quirks of addressing proving the longevity and throughput of drives, and MP3 players. Users increas- flash memory. the chip. This technique requires man- ingly need to access flash memory de- FTL is designed to let the filesystem agement structures (such as block map- vices with ordinary Linux systems, and read and write sectors without knowing ping) that collaborate with garbage col- the Linux community is responding with how the memory is organized, and with- lection. The controller handles this in better tools for addressing the challenges out bothering to delete before writing the case of, for example, a compact flash of flash. (see "Flash Technology" box). At pres- card (CF) or a USB memory stick, serv- LogFS is a recent entry into the race a b c d for a flash-ready Linux filesystem. Flash Translation Layer On today’s systems, a normal applica- tion may not even Figure 1: LogFS writes changes out of place. In the tree structure (a) it creates a modified block at a new position (b) be aware of whether and leaves the old block unchanged. The change is not yet linked, and Log-FS thus needs to create the parent node it is using flash (c). The new structure does not apply until the root node has been processed (d). This keeps the filesystem in a memory or an ordi- consistent state. 40 ISSUE 86 JANUARY 2008
  2. 2. LogFS COVER STORY ing a normal ATA interface to the sys- in place, but deposits the Floating Gate tem. Filesystems such as ext2 or FAT are contents at the end of the not optimized for use with flash mem- used memory area. Thus, Control Gate Oxide Layer ory. The FTL does not even know if a it collates changes that block has been deleted because the file- cover the segments of Source Drain system does not pass this information to several erase blocks – like the block layer. This makes garbage col- the garbage collection lection far more difficult. methods in FTD. n n To update the tree Introducing LogFS structure, LogFS rewrites p Special systems such as JFFS2 (Journal- all the branches from the ing Flash File System 2 [1], a develop- modified block down to Figure 2: The oxide layer surrounding the floating gate pre- ment based on the original JFFS [2]), the root at the end of the vents the electrons from escaping. (Fig. source: Wikipedia). UBIFS [3], or YAFFS [4] step in to ad- flash memory in use, thus dress the complications posed by flash implicitly declaring all previously used updates the tree too often [5] and thus memory. The name “Journaling Flash blocks as free memory (Figure 1). On gives away performance. We can only Filesystem” is unfortunate because JFFS mounting a LogFS device, the driver wish him good luck with LogFS. really uses a log-based structure. A new searches for the last root node. The data shooting star in this part of the Linux structure will be consistent below this Alternative Solutions sky is LogFS [5], which should not be node. This approach saves delete and Developers use several approaches to ad- confused with the now-defunct Log write actions. dress the complications of the Flash ar- Structured File System (LFS ) project [6]. chitecture. This article showed how to Using LogFS cope with these flash technical issues at LogFS vs. JFFS2 To use LogFS, you need to patch the va- the block layer (with FTL) and through Jörn Engel, the LogFS maintainer, is po- nilla kernel source. The LogFS site [5] the filesystem (with LogFS). sitioning LogFS against JFFS2. Engel ex- has patches for Linux 2.6.18, 2.6.20, Other options are to address flash is- pects to score points against JFFS2 on is- 2.6.21, and 2.6.23. The mklogfs tool is sues at the device level or to build sup- sues such as performance. For example, available from the same source. port directly into the application, a tech- Engel claims it takes up to 15 minutes to After configuring, building, and boot- nique often used with highly specialized mount a 1GB USB stick in JFFS. ing, you can create a Memory Technol- embedded applications. I ogy Device (MTD [7]) mklogfs /dev/ Moving Trees mtd0 and mount the device on the file- NAND Flashes The clever thing about LogFS is its tree- system: mount mtd0 /mnt -t logfs. Advantages: style management structure. LogFS LogFS is currently under development. • Short access times doesn’t delete and write modified blocks Jörn Engel says that his filesystem still • Low energy consumption Flash Technology • Data retention without a power Flash EEPROMs are memory chips with time, the number of deletion cycles (en- • Resistance to shocks and magnetic non-volatile content; that is, they retain durance) is limited. Manufacturers will fields data without a power supply. Because of not guarantee more than 100,000 to a Disadvantages: the small footprint of the chips and the million cycles for each block. • Slow write operations low manufacturing prices, NAND flash The reason for wear and tear is that • Deletions by sector only chips that connect a certain number of electrons in the floating gates tunnel flash transistors (floating gates) in series • Limited number of write cycles through the oxide layer of the transistor are typically used. Because selective on deletion (a phenomenon known • More expensive than alternatives write operations only toggle the logical as the Fowler-Nordheim tunnel effect). state from false to true, a logical opera- The high voltage required for this tion is required prior to each write to in- quantum mechanical effect damages INFO troduce a delete cycle. the oxide layer surrounding the floating [1] JFFS 2: Blockwise Deletion gate slightly each time a delete occurs In contrast to normal EEPROM memory, (see Figure 2). Once the degeneration [2] JFFS: a Flash EEPROM cannot delete a single process has reached a certain threshold, software/jffs/index.html word, the smallest addressable memory the electrons trapped in the transistor unit (8 to 64 bits) individually, but only a start to escape; the bit stored at this [3] UBIFS: http://www.linux-mtd. block. A block is typically a quarter, location is lost, and the memory cell eighth, sixteenth, and so on of the total is defective. Flash device vendors [4] YAFFS: memory capacity of the chip. These attempt to counteract this effect by [5] LogFS: EEPROM blocks (also known as erase including reserve cells and defect [6] LFS: blocks) are far bigger than the blocks management to map out defective that legacy filesystems use. At the same blocks. [7] MTD: JANUARY 2008 ISSUE 86 41