| Specification |
|
The current file system used on the XO ([JFFS2]) was developed in the days of 32/64MiB NOR flash devices and does not scale well to the 1GiB NAND devices we are using today and certainly will not deal well with larger devices in gen 1.5 and gen 2 systems. The main issues are that JFFS2 needs to scan all blocks at mount time and that the garbage collection algorithm increasingly consumes CPU cycles as the system fills up. The first issue manifests itself as large delays at boot up to mount the file system as it is full (need to quantify this), and the second issue simply means less CPU cycles can be dedicated to user task processing. Paging executables in from JFFFS seems to result in large CPU time usage as memory becomes scarce: read-only code pages are thrown out (because they're the only pages that can be discarded on demand) and re-read numerous times; the system seems to become much more sluggish than an ext3 disk-based Linux system.
In the last few years, there has been much activity in the embedded Linux world on alternatives to JFFS2 and we need to investigate these to determine which one best fits our needs:
- YAFFS2 : Has been around for several years and in active use in the embedded space. It does not provide compression out of the box as the devices that use it often carry already compressed data such as MP3 and MPG files.
- UBIFS: A new file system recently merged into the kernel designed for use on large flash devices. Supports compression out of the box and supports disabling compression on a per-inode basis, which is something we desire.
- LogFS : Another JFFS2 replacement designed for fast operation and scalability. Still fairly new and not in very active use AFAIK.
- Btrfs : A very new file system that is primarily targeted for large storage systems with features such as snapshotting, RAID support, and online fsck. David Woodhouse has expressed that he will look into getting this to work on NAND, but it is too new of a code base to consider for 9.1
- Managed NAND : (Not an option for existing XO machines, but might be a direction for future hardware) The industry seems to be moving away from raw NAND in favor of a NAND-chip plus microcontroller solution. The microcontroller implements a Flash Translation Layer that hides the low level NAND details, presenting a higher level interface that looks like an ordinary hard disk, so an ordinary filesystem layout like ext3 could be used. The driving force behind managed NAND is rapid hardware evolution toward multi-level-cell NAND chips and smaller process geometries, which change important NAND parameters like page sizes and ECC. The situation is similar to what happened with hard disks in the 80's, where raw-disk interfaces gave way to SCSI and IDE, which hide the ugly low-level details that changed every technology generation. Managed NAND options include LBA-NAND from Toshiba (pin-compatible with NAND chips), eMMC from multiple vendors (with an SD/MMC-compatible hardware interface), and various "disk on chip" products (IDE-compatible interface).
Development process
- Analyze and quantify the use patterns that trigger issues with JFFS2.
- Gather requirements for a new file system that go beyond solving above issues.
- Develop/integrate a set of tests for FS performance and reliability that take into account our use patterns, the above issues, and any other features we wish to validate.
- Study the three main alternatives (YAFFS, UbiFS, LogFS) to determine what requirements they meet
- Run our FS test suite on above alternatives
- Analyze test results and requirements study and make a decision on which alternative to use.
Deployment process
Once a file system is chosen from the above process, we will have to:
- Integrate the file system into our kernel if it is not upstream (YAFFS2 or Logfs)
- Integrate the file system support packages into our build system and file system images
- Update our build scripts to generate the proper image type for
Activity impact
This change should not have any impact on activity developers as it is at a very low level of the stack.
End-user impact
End users will see faster boot up time and will not see (as much) performance degradation as the file system and/or RAM fill up.
|
