UFFS usage guidline

UFFS is not a generic file system for every day use like FAT32 or Ext3, or generic flash file system like JFFS2 or YAFFS2 for NAND.

The fact that UFFS consumes one block for each directory and one or more blocks for each file makes it not suitable for large numbers of directories or files.

Not using separate thread for GC makes UFFS very predictable (good for read-time system), but it may also beat performance badly if you randomly moving file pointer across block boundary and modifying the file content.

What UFFS best suit for:

* Not many directories.
Too many directories will cause in low space efficiency but no performance penalty. In fact, many embedded system don't use directory. (UFFS2 will fix this by allowing multiple directories on one block)

* Not many small files.
Full of small files will also cause low space efficiency. (UFFS2 will fix this by allowing multiple files on one block)

* Large file size.
UFFS performs well when reading/seeking/writing/appending in large size file.

* Appending a file.
UFFS has the best performence if you are appending a file, or doing the modifies within the last block boundary.

* Random reading.
Seeking file pointer is very fast in UFFS.

What should you minimize or avoid:

* Creating and deleting files frequently.
Create a file then delete it results in erasing 2 blocks, which is not a good practice for NAND flash if doing that frequently.

* Moving file pointer across block boundary and modifying the file content.
UFFS won't cache the data across block boundary when writing to a file, so it need to do the block recover immeditly (which will erase one block). This may beat the performance badly.

For example, if you have a size 1MB file, seek the file pointer to 0, write 1 byte, then seek the pointer to 1MB(the end of file), write 1 byte, then close file. The whole process will cause 2 block recoveries, as result, 2 blocks will be erased.

* Opening multiple files for write.
The fact that UFFS can't cache the data across block baundary and files are in different blocks, opening multiple files and writing to them will make UFFS frequetly flush out the cache and cause bock recovery.

* Truncating/Deleting large size file.
When deleting a file, UFFS will erase all blocks belong to the file, which may take quite a long time for large file on slow NAND flash. Truncating a file will also cause erasing the discarded blocks.