?? yaffs-0.3.html
字號:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD> <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1"> <TITLE></TITLE> <META NAME="GENERATOR" CONTENT="StarOffice/5.2 (Linux)"> <META NAME="AUTHOR" CONTENT=" "> <META NAME="CREATED" CONTENT="20011219;22024300"> <META NAME="CHANGEDBY" CONTENT=" "> <META NAME="CHANGED" CONTENT="20020128;21063000"></HEAD><BODY><H1 ALIGN=CENTER>YAFFS (yet another Flash File System)</H1><H4 ALIGN=LEFT>Version 0.3<BR>Charles Manning (and Wookey), December 2001</H4><P ALIGN=LEFT><BR><BR></P><H2>Revision History</H2><TABLE WIDTH=548 BORDER=1 CELLPADDING=4 CELLSPACING=3> <COL WIDTH=88> <COL WIDTH=72> <COL WIDTH=350> <THEAD> <TR> <TH WIDTH=88 VALIGN=TOP> <P ALIGN=LEFT STYLE="font-style: normal">V0.0</P> </TH> <TH WIDTH=72 VALIGN=BOTTOM SDVAL="37245" SDNUM="5129;0;D/MM/YY"> <P ALIGN=LEFT STYLE="font-style: normal">20/12/01</P> </TH> <TH WIDTH=350 VALIGN=TOP> <P ALIGN=LEFT STYLE="font-style: normal">First draft</P> </TH> </TR> </THEAD> <TBODY> <TR> <TD WIDTH=88 VALIGN=TOP> <P ALIGN=LEFT STYLE="font-style: normal">V0.1</P> </TD> <TD WIDTH=72 VALIGN=BOTTOM SDVAL="37267" SDNUM="5129;0;D/MM/YY"> <P ALIGN=LEFT STYLE="font-style: normal">11/01/02</P> </TD> <TD WIDTH=350 VALIGN=TOP> <P ALIGN=LEFT STYLE="font-style: normal">Minor corrections & cosmetics.<BR>Change use of data status byte.</P> </TD> </TR> <TR> <TD WIDTH=88 VALIGN=TOP> <P ALIGN=LEFT STYLE="font-style: normal">V0.2</P> </TD> <TD WIDTH=72 VALIGN=BOTTOM SDVAL="37284" SDNUM="5129;0;D/MM/YY"> <P ALIGN=RIGHT STYLE="font-style: normal">28/01/02</P> </TD> <TD WIDTH=350 VALIGN=TOP> <P ALIGN=LEFT STYLE="font-style: normal">Added observations about inodes, file headers and hard links.</P> </TD> </TR> <TR> <TD WIDTH=88 VALIGN=TOP> <P ALIGN=LEFT STYLE="font-style: normal">V0.3</P> </TD> <TD WIDTH=72 VALIGN=BOTTOM SDVAL="37285" SDNUM="5129;0;D/MM/YY"> <P ALIGN=RIGHT STYLE="font-style: normal">26/02/02</P> </TD> <TD WIDTH=350 VALIGN=TOP> <P ALIGN=LEFT STYLE="font-style: normal">W:Added some general observations on compatibility, partitions and bootloading.</P> </TD> </TR> </TBODY></TABLE><P ALIGN=LEFT><BR><BR></P><H2>Scope</H2><P>The purpose of this document is to outline a potentialNAND-friendly file system for Linux.</P><H2>Background</H2><P>There are already various flash-file systems (FFSs) or blockdrivers for flash (on top of which a regular FS runs). There are prosand cons with all of these. </P><P>Flash memory has quite a few constraints which will not beaddressed here. Various approaches are available to work around theseconstraints to provide a file system. It is important to recognisethat "flash" includes both NOR and NAND flash which havedifferent sets of constraints. It is easy to be mislead by thegeneric term "flash" into thinking that approachesappropriate for NOR flash are immediately suitable for NAND flash.</P><P>The NAND block drivers (eg. SmartMedia [currently not availablefor Linux] and DiskOnChip NFTL) typically use FAT16 as the filesystem. This isn't too robust and nor is it that flash-friendly.These block drivers provide a logical to physical mapping layer toemulate rewritable blocks that look like disk sectors. When used withFAT16, these file systems work reasonably well. They have a lowmemory footprint and scale well. Like all FAT based systems they areprone to corruption ("lost clusters etc").</P><P>The other approach is to design an entire file system which doesnot work through a block driver layer and is flash-friendly. Thisallows more scope to work around issues.</P><P>Currently, two Linux file systems that support NOR flash very wellare JFFS and its derivative JFFS2. Both of these are based on theprinciples of journaling (hence the leading J) which significantlyincreases robustness - a particularly important feature in embeddedsystems. Unfortunately neither of these file systems scaleparticularly well in both boot time and RAM usage. Scaling isparticularly relevant when one considers that a 16MB NOR array wouldbe considered large while a 128MB NAND is available as a single chip.</P><P>JFFS requires a RAM-based jffs_node structure for each journallingnode in the flash. Each of these nodes is 48 bytes. JFFS2 makes asignificant improvement here by reducing the equivalent structure(jffs2_raw_node_ref) to 16 bytes. Still, at say an average node-sizeof 512 bytes, a 128MB NAND might need 250000 of these ... 4MB!</P><P>Both JFFS and JFFS2 require scanning the flash array at boot timeto find the journaling nodes and determine the file structures. SinceNAND is large, slow, serially accessed and needs ECC this does notscale well and will take an unacceptably long boot time for thetarget systems. As a thumb-suck, the scanning of a 128MB NAND arraymight take approx 25 seconds.</P><P>The intentions of the design sketched here are:</P><UL> <LI><P>Be NAND-flash friendly.</P> <LI><P>Robustness through journaling strategies.</P> <LI><P>Significantly reduce the RAM overheads and boot times associated with JFFSx.</P></UL><p>This FS is intended primarily for internal NAND rather than removable NAND(SM cards). On removable SM cards Smartmedia compatibility is likely to beimportant so SM/FAT will normally be used, although of course YAFFS makes alot of sense if reliability is more important than compatibility.</p><H2>Overview</H2><P>Here follows a simplified overview of YAFFS.</P><P>YAFFS uses a physical flash format similar to SmartMedia. This isdone for various reasons:</P><UL> <LI><P>Some of the formatting, eg placement of bad block markers is determined by the NAND manufacturers and can't be changed.</P> <LI><P>Potential to reuse code.</P> <LI><P>If it ain't broke don't fix.</P></UL><P>Some of the fields are obviously different to reflect thedifferent usage. Despite the similarities YAFFS is not actually compatiblewith SM/FAT. SM cards need to be reformatted to switch from using SM/FAT toYAFFS or vice versa.</P><P>File data is stored in fixed size "chunks" consistentwith the size of a page (ie. 512 bytes). Each page is marked with afile id and chunk number. These tags are stored in the "sparedata" region of the flash. The chunk number is determined bydividing the file position by the chunk size.</P><P>When data in a file is overwritten, the relevant chunks arereplaced by writing new pages to flash containing the new data butthe same tags. The overwritten data is marked as "discarded".</P><P>File "headers" are stored as a single page, marked so asto be differentiated from data pages.</P><P>Pages are also marked with a short (2 bit) serial number thatincrements each time the page at this position is incremented. Thereason for this is that if power loss/crash/other act of demonicforces happens before the replaced page is marked as discarded, it ispossible to have two pages with the same tags. The serial number isused to arbitrate.</P><P>A block containing only discarded pages (termed a <I>dirty block</I>)is an obvious candidate for garbage collection. Otherwise valid pagescan be copied off a block thus rendering the whole block discardedand ready for garbage collection.</P><P>In theory you don't need to hold the file structure in RAM... youcould just scan the whole flash looking for pages when you need them.In practice though you'd want better file access times than that! Themechanism proposed here is to have a list of __u16 page addressesassociated with each file. Since there are 2<SUP>18</SUP> pages in a128MB NAND, a __u16 is insufficient to uniquely identify a page butis does identify a group of 4 pages - a small enough region to searchexhaustively. This mechanism is clearly expandable to larger NANDdevices - within reason. The RAM overhead with this approach isapprox 2 bytes per page - 512kB of RAM for a whole 128MB NAND.</P><P>Boot-time scanning to build the file structure lists shouldrequire just one pass reading NAND. Since only the the spare dataneeds to be read, this should be relatively fast ( approx 3 secondsfor 128MB). Improvements can be achieved by partitioning the NAND.ie. mount the critical partition first then mount the data partitionafterwards.</P><P>Various runtime improvements can be achieved by changing the"chunk size" to 1024 bytes or more. However this wouldlikely reduce flash efficiency. As always, life is a compromise....</P><P><BR><BR></P><H3>Spare area details</H3><P>The following table summarizes the layout of the spare area ofeach page.</P><TABLE WIDTH=674 BORDER=1 CELLPADDING=4 CELLSPACING=3> <COL WIDTH=96> <COL WIDTH=249> <COL WIDTH=291> <THEAD> <TR VALIGN=TOP> <TH WIDTH=96> <P>Byte #</P> </TH> <TH WIDTH=249> <P>SmartMedia usage</P> </TH> <TH WIDTH=291> <P>YAFFS usage</P> </TH> </TR> </THEAD> <TBODY> <TR VALIGN=TOP> <TD WIDTH=96> <P>0..511</P> </TD> <TD WIDTH=249> <P>Data</P> </TD> <TD WIDTH=291> <P>Data. either file data or file header depending on tags</P> </TD> </TR> <TR VALIGN=TOP> <TD WIDTH=96> <P>512..515</P> </TD> <TD WIDTH=249> <P>Reserved</P> </TD> <TD WIDTH=291> <P>Tags</P> </TD> </TR> <TR> <TD WIDTH=96 VALIGN=BOTTOM SDVAL="516" SDNUM="5129;"> <P ALIGN=RIGHT>516</P> </TD> <TD WIDTH=249 VALIGN=TOP> <P>Data status byte. Not used in SM code from Samsung</P> </TD> <TD WIDTH=291 VALIGN=TOP> <P>Data status byte. If more than 4 bits are zero, then this page is discarded.</P> </TD> </TR> <TR> <TD WIDTH=96 VALIGN=BOTTOM SDVAL="517" SDNUM="5129;"> <P ALIGN=RIGHT>517</P> </TD> <TD WIDTH=249 VALIGN=TOP> <P>Block status byte</P> </TD> <TD WIDTH=291 VALIGN=TOP> <P>Block status byte</P>?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -