Although it is neither seen nor touched by a user, flash file system software is integral to the basic functionality of a mobile phone. This important embedded software component ensures that data can be written to the storage media, accessed by the user, and read on demand.

The process of bringing a new mobile phone to the market involves design decisions from each member of the value chain, all working toward a common goal: the users' satisfaction with their purchase.

Cellphone users make purchase decisions based on ease of use, speed of operation (they don't want to wait for images to load, or contacts to be accessed), and reliability, among other factors. Reliability and performance are therefore the critical elements of the flash file system.

Reliability

Among the many features of a flash file system that can affect the overall reliability of a system, the main ones are described below:

• Type of file system — The typical file system types are FAT, journaling and transactional.

  • FAT is the traditional file system, originally developed for use in desktop systems or servers, using a file allocation table which tracks how files and directories are stored throughout the storage media. FAT file systems lack a means of synchronizing data in case of system failure and are therefore susceptible to corruption.
  • Journaling file systems keep a log of all file system activities. Although more robust than a FAT file system, journaling file systems offer improved reliability and the expense of heavy system resource use.
  • Transactional file systems were developed specifically for embedded systems; they preserve both user and metadata through committing the known good state of the file system to memory with an atomic transaction point event. Through system crash tests at Datalight, FAT file system tests show data corruption nearly 20 percent of the time, while transactional file system testing (on Datalight Reliance) returned a 0 percent rate of corruption.

• Atomic sector writes — To guarantee device data integrity, regardless of whether it is being used in optimum or adverse conditions, data must be either fully written to sectors on the storage media or not touched at all. The mechanism in the flash file system that preserves data structures should be automatic and invisible to the developer. Additionally, it should ensure data integrity in the file system as well as the block device driver.
• Flash management — wear-leveling and bad block management — Flash memory requires strict software management in order to ensure that the life of the chip is maximized and write errors do not occur. One of the complexities of flash is that it must be erased before data can be changed. Wear-leveling algorithms ensure that erase zones are used evenly across the entire flash array. Wear leveling is especially useful when large portions of the flash array are used for long-term data storage; for example, a single picture may be written to a handset once and stored (and accessed) over an extended period of time. In addition to wear-leveling, NAND flash requires a bad block management scheme that efficiently detects blocks that cannot be written to and reserves replacement blocks on the flash array. When properly implemented, bad block management will extend the life of a flash chip.

Performance

OEMs and ODMs (original equipment/design manufacturers) are pressured by consumers to produce devices that perform complex tasks quickly. The flash file system in a consumer mobile device must support this demand with the following features:

• Multi-threaded — In systems that support multithreaded operations, read requests are allowed to interrupt the more time-consuming write and erase operations. Support for multi-threaded operations is ideal in systems that stream media applications, such as high-end wireless devices with mobile TV applications.
• Background compaction — As mentioned above, flash memory requires intelligent software to conduct write and erase operations. In order to keep valid data while throwing away unwanted data, a process of compaction (also called “garbage collection”) must take place. Compaction sometimes occurs during write operations, in order to properly complete a write. However, write speeds can be optimized when compaction takes place during flash file system idle time in preparation for a future write. This is referred to as background compaction, and results in a significant write performance improvement.
• Quick boot times — The boot process of a flash file system involves mounting the flash disk followed by mounting the file system. Mounting the flash disk requires a scan of the entire disk to ensure the integrity; the length of the scan process is directly proportional to the size of the disk. The file system mount varies greatly depending upon the type of file system. The fastest and most reliable option is a transactional file system, which completes by reading only two data blocks (the committed state and the known good state) and finishes in less than one second. Other file systems such as FAT and Journaling use a lengthy CHKDSK utility to scan the file system integrity and perform repair operations if necessary. These file systems can take up to several minutes to mount.

Other factors

The device designer (i.e. the OEM or ODM), the wireless carrier, or other software and hardware vendors contributing to device design have interests beyond performance and reliability; the concerns of these groups are often deeply technical. A key driver is delivering products to market faster than their competitors, within an already constricting development schedule and budget. Therefore, flash file system solutions that are easy to integrate into the overall system design are key considerations.

Because handset design involves a number of different vendors who must tweak their products to operate as one, setbacks during integration are common, but costly. A software solution that is easy to integrate with other system components can reduce the risk of delivering a handset to the market on time. An integration that can be replicated on future device designs with minimal tweaks has even further benefit in reducing delivery risk.

Some flash file system features that may speed integration are:

• Broad hardware support — A flash file system solution that is limited to supporting one type of flash (i.e. NAND only) or parts from only one vendor may be a development burden in the high-volume wireless handset market. During production, it is likely that flash parts from multiple vendors will be used. The ideal software will auto-detect and support any flash technology (NAND and NOR as well as advanced flash technologies such as NAND controllers on processors and hybrid flash). Single devices that use more than one type of flash (i.e. NOR to store system code, NAND to store user data) will also benefit from a flash file system that allows for writes to varying block sizes with a single instance of the software.
• Portability to various operating systems — Similar to integration with a variety of hardware, the flash file system should not be tied to a single operating system environment or application interface. Flash file systems that offer highly abstracted interfaces to 1) the operating system, 2) the flash hardware, 3) the platform specific �project� code, and 4) the build environment and tools have the highest potential for quick integration. Flash file systems that can coexist with an operating system�s native file system offer further flexibility to designers that wish to take advantage of the selected operating system. Support for Unicode file names, and support for POSIX are other factors which enhance the ease of portability of a flash file system.
• Source code and documentation provided — With full source code, customization of the flash file system into a wide range of environments is possible.

Standardization

The above characteristics are especially important in flash file systems that are being integrated into the system for the first time. To take full advantage of the chosen solution, the initial integration efforts should have provided a head-start for future OEM designs.

In selecting a flash file system that can be used as a standard across multiple platforms, the solution must be scalable. A flash file system with multiple parameters that can be tuned to each other for tradeoffs in performance and system resources (code size and memory usage) offers the flexibility that is necessary to accommodate a low-end phone, as well as a high-end multimedia PDA. Additional parameters that provide flexibility across platforms include support for multiple disk partitions and multiple file system volumes.

Vendor issues

In an evaluation of flash file systems, the product functionality is important, but the software vendor must also be chosen carefully, as each partner within a project as complex as wireless handset development contributes to product market success or failure. Not all flash file system vendors are alike — after all, not all devices have the same needs. Experience with similar design projects is critical.

A vendor with flash file system knowledge on its own is simply not going to cut it in the bleeding edge mobile phone market. Mobile phones are extremely unique devices — among the most complex environments in the embedded industry — in which all design challenges intersect and few can be compromised. For example, cellphones must be:

• Feature-rich, multi-function
• Accommodate many data types
• Have a small physical size
• Consume very little power
• Be low cost
• Reach market quickly, and on time

Conclusion

As OEMs, ODMs, and wireless carriers set out to evaluate a flash file system, it is important to consider the needs of the consumer as well as the needs of the design team. Key considerations include:

• Reliable file system type -� transactional, not FAT
• Data integrity mechanisms
• Intelligent flash management algorithms, including wear-leveling and bad block management
• High performance reads and writes, enabled through multi-threaded support and background compaction
• Quick boot times
• Broad hardware and operating system support
• Source code and documentation provided
• Able to be tuned and scaled for varying environments

Copyright (c) 2006 Datalight Inc. All rights reserved. Reproduced by WindowsForDevices.com with permission

---

About the author: As Product Manager for Datalight, Cortney Jacobsen oversees the product marketing strategy and programs for the company's product lines, including Reliance, FlashFX Pro, and 4GR, and provides critical customer advocacy for the development teams. Jacobsen has six years of experience in product management, business analysis, and project management for a variety of industries, ranging from audio/video systems to embedded software. She holds a BS in Audio Engineering and Classical Piano, with a minor in Electrical Engineering.

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.