JFFS:

1

• JFFS
• The Journaling Flash File System
• Ioannis Papadopoulos
• ipapadop_at_cse.tamu.edu

2
Motivation for JFFS

• Typical approach for using flash memory
• Implement a block-device emulation layer
• Makes the flash memory look like a magnetic disk
  drive
• Then use a regular filesystem
• Problems
• Suboptimal writing
• A block in flash memory is 128KiB (NOR) or 8KiB
  (NAND)
• A block device has 512byte sectors thus a
  filesystem for the latter is optimized for these
  sectors
• Potential data loss
• Keeping data in memory while writing the block
• Wear-leveling is either inexistant or requires a
  Translation Layer
• Have the same amount or erasures for every block
• Flash Translation Layer (FLT) and NAND FLT (NFLT)
• Covered by patents (M-Systems)

3
JFFS

• Log-structured filesystem
• Data/metadata are written sequentially to the log
• It is a continuous stream of data
• The log is the filesystem
• Inode
• Data structure in Unix filesystems that keeps
  information for a file, directory or other object
• Unique and non-reusable 32bit identifier
• An inode has many nodes
• Node
• Metadata
• uid, gid, mtime, atime etc.
• Variable amount of data
• Total ordering between nodes in inode
• Unique and non-reusable 32bit identifier called
  version
• Running out of identifiers not an issue
• Limited lifetime of flash memory

4
Log details

• Obsolete nodes are nodes that are not used
• Called Dirty Space
• A deleted inode has only obsolete nodes
• Nodes whose range is covered by later nodes
• Later nodes have higher version number
• Head of log first non-obsolete node
• Tail of log last non-obsolete node
• At mount time, all the nodes are scanned
• Rebuild directory structure
• Do the inode-to-node mapping
• Mapping and directory structure kept in memory
• Changes in metadata or file writes
• Writes new node at the end of the log
• So nodes of the same range become obsolete!

5
Garbage Collection (GC)

• Write needs to be done but no space for a new
  node
• Reclaim dirty space
• Head is moved after the tail of the log
• The head becomes obsolete
• New head is the next non-obsolete node
• May merge many nodes to improve storage
  efficiency
• Nodes move happens until a full block has been
  erased
• It becomes available for use by the tail of the
  log
• At least 4 blocks are needed at the tail to do GC
• Empirically proven
• Maximum node size half flash block
• JFSS is a circular log

6
JFFS Limitations

• No hard links allowed
• Suboptimal GC
• Provides perfect wear leveling
• But moving data unnecessarily
• On every pass of the GC, it was moving static
  data
• No compression support

7
JFFS2

• Three node types
• No more circular log
• Each erase block is treated individually
• Nodes do not span over different blocks
• Some information only about inodes cached at
  memory
• New mounting procedure
• Four stages
• Scan all nodes and check them, from inode-to-node
  mapping
• Find obsolete nodes
• Find deleted inodes
• Flush inode information cache

8
JFFS2 Nodes

• Common header
• Full node length, node type, CRC
• Support for well-defined behavior if kernel does
  not support the node type
• Backwards compatibility
• JFFS-like node of inode
• Support for compression
• Dirent node
• Directory entry of link-to-inode
• Clean node
• Indicates an erased node
• Solves problem of partially erased nodes in block
  appearing as used in JFFS

9
JFFS2 Compression Support

• Major feature since JFFS
• That's why JFFS2 was created
• Zlib, rubin, rtime compression algorithms
• For data in nodes
• Special compression mode signals empty node
• Truncation leads to holes in files
• Old GC didn't care about holes in files
• Linear so later nodes took care of holes
• New GC has problems
• Mark nodes that are holes with compression
  special header

10
JFFS2 GC

• Instead of head-tail a free_list of nodes
• Heurestic starts GC
• Obtains full inode information
• Tries to compress some of the non-obsolete nodes
  of the inode
• Writes it in a new block
• Erases the old one and puts it in the free_list
• Formal proof of correctness of GC crucial
• But compression complicates things
• Single byte changes entropy
• Solution allow partial ordering of nodes
• Same version number if same data
• Formal proof pending

11
Future

• Improved Fault Tolerance
• Error Detection Yes (CRC)
• Error Correction NO!!!
• Currently mark bad blocks and check them upon
  remounting
• Essential for NAND
• Higher error rates
• Garbage Collection Space Requirements
• 5 full erase blocks needed currently before any
  write happens
• Can probably be reduced to
• 1 block for NOR flash
• 3 blocks for NAND flash
• Formal upper bound for number of erase blocks
• No provable upper bound for JFFS1, possibly
  exists for JFFS2
• Transaction Support
• Expose transactions to user-space
• Not as another layer, but in the filesystem
  itself
• Take advantage of the journalling capabilities

12
Conclusion

• XIP (eXecute-In-Place)
• Don't move program to RAM for execution
• Execute it in the flash
• Can't work with compression
• Developers do not consider implementing it
• Or maybe support a read-only XIP-capable JFFS2
• JFFS and JFFS2 are stable
• No major bugs, small number of new ones
• Used in Familiar, a GNU/Linux distribution and
  by RedHat's contract customers
• In Linux Kernel versions 2.4 and up
• Available under GNU/GPL and eCoS MPL licences