An ultra low cost flash file system for embedded system
Chinese Version


* 2010-4-5: UFFS v1.3.2 released !
  Link: http://all-about-uffs.blogspot.com/2010/04/uffs-v132-released.html
* 2010-3-2: UFFS v1.3.1 released !
  Link: http://all-about-uffs.blogspot.com/2010/03/uffs-v131-released.html
* 2010-2-23: UFFS v1.3.0 released !
  Link: http://all-about-uffs.blogspot.com/2010/02/uffs-v130-released.html

* 2009-5-17: UFFS v1.2.1 released and Licence changed !
UFFS 1.2.1 is just released (download). This version fixes a directory listing bug, improves bad block management and most important, the Licence changed to a modified GNU GPLv2, the same as eCos Licence.
As the author of YAFFS pointed out, LGPL is not practical for most embedded system. The new Licence will allow a close-source application staticly link to UFFS lib.

* 2009-4-23: A new blog is created for UFFS.
As google will not continue to serve the googlepage service soon, I've created a blog for UFFS. All further dynamic will be released at the blog. The blog address: http://all-about-uffs.blogspot.com

* 2009-04-01: UFFS v1.2.0 released !

  - Eliminate 'current path' and relatives. Now you should use absolute path in all uffs APIs.
    For directory, the full name should end with '/'. e.g. uffs_OpenFindObject(&info, "/mydir/");
  - Allow using static memory allocation (uncomment USE_STATIC_MEMORY_ALLOCATOR in uffs_config.h),
    'malloc' is no longer needed when using static memory allocation.
  - Using cmake for building simulator, please read the README file in the source package.
  - Bug fixes & minor changes.

* 2008-03-01: UFFS v1.1.2 released !
-  Add a new ECC-don't-care 'Simram' Flash Class, which is used for simulate NAND flash on RAM
    or supporting NOR Flash (boosting speed and better space efficiency)
License changed from GNU GPLv2 to GNU LGPLv2

*2007-12-05: UFFS v1.1.1 released !
- Numbers of bugs are fixed.
- Enhanced large-page NAND flash support.
- An example of direct flash interface added.
- A tool added for making UFFS disk image, usage example:
# uffs --file uffs.img --page-size 512 --spare-size 16 --block-pages 32 --total-block 128 \
--mount /sys/,0,63 --mount /,64,-1 --exec script.ufs
# cat script.ufs
format /
format /sys/
cp ::my_sys_file.txt /sys/my_sys_file.txt
cp ::myfile.txt /myfile.txt

*2007-8-07: UFFS v1.1.0 released !
Support large page size, e.g. 1K, 2K, support all Samsung NAND flash chips.

UFFS introduction

UFFS is a NAND flash file system designed for embedded system which has limited memory, it performs some unique and advanced features:

* Low cost:

For page size = 512:
  [VARY] Tree nodes: 16 * total_blocks
  [CONST] Page Bufs: MAX_CACHED_BUFFERS(10) * (40 + pageSize(512)) = 5.4K
  [CONST] Block Info caches: (24 + 14 * pages_per_block (32)) * MAX_CACHED_BLOCK_INFO (10) = 4.6K

  Example a.  128M bytes NAND, 8192 blocks, total memory cost:
      (16 * 8192)128K + 5.4K + 4.6K = 138K bytes.
  Example b.   32M Bytes NAND, 2048 blocks, total memory cost:
      (16 * 2048)32K + 5.4K + 4.6K = 42K bytes.
  Example c.   16M bytes NAND, 1024 blocks, total memory cost:
            (16 * 1024)16K + 5.4K + 4.6K = 26K bytes.

For page size = 2048:
  [VARY] Tree nodes: 16 * total_blocks
  [CONST] Page Bufs: MAX_CACHED_BUFFERS(10) * (40 + pageSize(2048)) = 20.4K
  [CONST] Block Info caches: (24 + 14 * pages_per_block (32)) * MAX_CACHED_BLOCK_INFO (10) = 4.6K

  Example a.  512M bytes NAND, 8192 blocks, total memory cost:
      (16 * 8192)128K + 20.4K + 4.6K = 153K bytes.
  Example b.  128M Bytes NAND, 2048 blocks, total memory cost:
      (16 * 2048)32K + 20.4K + 4.6K = 57K bytes.
  Example c.   64M bytes NAND, 1024 blocks, total memory cost:
      (16 * 1024)16K + 20.4K + 4.6K = 41K bytes.

* Fast booting

UFFS read only one spare area for each NAND flash block to build up the in-memory nodes tree. Typically, UFFS needs less then half second to mount a full loaded 128 MB(page size 512)/512MB(page size 2K) NAND flash.

* Static Memory Consumption
UFFS will allocate all necessary memory (see the table above) when it start up(mounted) and will not require more memory when you create new files/directories. It's very important for some real time system.

* Superb Reliability
Guaranteed integrity across unexpected power losses.

* Bad-block tolerant, ECC enable and wear-leveling
Nothing new for a flash file system, but UFFS implements these in a simple yet effective way.

* No garbage collection needed for UFFS
UFFS collect the 'dirty blocks' on the fly, no garbage collection needed.

* Support direct flash interface, no operating system needed
UFFS can be build on top of direct flash interface,easy to be ported to any embedded system without OS required.

* Fully tested
UFFS is fully tested on PC (via UFFS PC emulator). Moreover, UFFS is not just 'proof-of-concept' but has been successfully used in real world product for tens of thousands of copies.

What UFFS "IS", "IS NOT" ?

  • UFFS is not a Linux kernel module.
  • UFFS is not running in a separated thread rather than application.
  • UFFS is a library to be linked with your embedded application.
  • UFFS is ideal for real time system which has limited memory.
  • UFFS is not the substitute of JFFS or YAFFS.

Why UFFS ?

  •  Hardware resource is limited (typically 64~512K RAM), but need a reliable flash file system
  • JFFS/JFFS2 is slow and a memory monster
  • YAFFS/YAFFS2 is excellent, but still consumes too much memory
  •  Others ? ... not available... (open source of course)

Where to get it ?

UFFS is currently hosted on sourceforge.net (http://www.sourceforge.net/projects/uffs), you can download UFFS source code from sourceforge.

Support This Project

How it works ?

Check out my presentation :

Try out UFFS on PC emulator

Compile and run UFFS test shell:

Writing NAND flash driver for UFFS

How you can help

Try it out, report me a bug or improve the code even batter :-)

Having questions about UFFS ?


Q: Can I use UFFS with RTOS like uC/OS, eCos ... ect ?
A: Yes.

Q: Can I use UFFS without OS ?
A: Yes.

Q: What types of NAND Flash are supported ?
A: Most SLC NAND flash include small page(512) and large page(2048) are supported.

Q: Does UFFS support NOR Flash ?
A: Yes, but you may result in low space efficiency as NOR flash normally has big block(e.g. 128K?) and UFFS require at least one block for each file or directory.

Q: Can I use UFFS to build up USB memory stick firmware ?
A: No. USB memory stick is a 'USB Mass storage' device which use transparent block mapping --- you don't need any file system for your firmware actually. The host system (Windows/Linux) will format the USB memory stick with their favorite format (usually FAT system).

Q: Can I use UFFS to build up MP3 Player firmware ?
A: Yes and No. If your MP3 Player use customized communication protocol exchange the MP3 data files with host (PC) system, you can use UFFS as the file system to store MP3 music files and play back with no problem. But if you use 'USB Mass storage' as the 'protocol' to exchange MP3 data files with host (PC) system, then you can't use UFFS, probably FAT is the only choice in this case.

Q: Why I can't use FAT on NAND flash, anyway ?
A: Yes, you can, in fact FAT works well in 'read-only' situation. But if your application needs to write plenty of data and the system may lost power at any time ... then FAT file system will bring you the big troubles: lost data, missing files or even worse (try to unplug the power cable of the PC running Windows ... repeat 10 times ?). You shouldn't expect people select 'shut down' menu before turn off TV. A true flash file system like UFFS will guarantee integrity across unexpected power losses.

Q: Can I use UFFS in embedded Linux ?
A: Yes and No. You can use UFFS as a lib and use uffs's API access the storage, you can't use Linux's file system API access the storage managed by UFFS. By the way, if your platform has plenty of memory to run embedded Linux, I'd like suggest YAFFS.

The next: UFFS2

The main improvement on UFFS2 will be:

  • The smaller memory footprint: reduce 25%-50% memory usage as a result.
  • One or more files/directories reside on one block, will significantly improve space efficiency for small files.
  • Symbol link or other special files.
  • Static wear-leveling.
  • Support more NAND flash chips ...

Locations of visitors to this page