Demonstrating how system software work in a visual manner is an interesting problem, especially in embedded space. There is no UI or visual effects to WOW the audience. To evaluate the value system software components bring to an embedded design, the customer usually needs to configure our software on his embedded development board. This provides for comprehensive evaluation but can be a significant effort. . We run into this very often at Datalight since our primary products (FlashFX Pro and Reliance) are system level embedded software. One way we have attempted to demonstrate our software is to make a full-functional version of our software run on user’s desktop PC. This allows the customer to run the software without any special hardware in matter of minutes and understand the core working of our software. Once they believe there is value, the can request source code access and try it on the actual embedded hardware.

The first demonstration that we have built is for Datalight Reliance. This demo is available to all users who are registered for MyDatalight account. The video below shows how you can use this software on any Windows PC and understand how Reliance unique transactional design allows for 100% reliability against data corruption and how Dynamic Transaction Point technology allows developers to tune their file system even while the device is running.

Bothell, Wash., – August 12, 2008 – Datalight announced today that it has released new versions of Reliance™ and FlashFX® Pro, with pre-configured support for  MontaVista® Linux®. The new install experience includes simplified integration within MontaVista DevRocket, an Eclipse-based IDE that streamlines common embedded  development tasks. Dropped into DevRocket, Datalight products build as kernel loadable modules that work with a project’s OS image. Sample bootstrap code is also  supplied for developers who need to integrate the products into a boot loader.

“Developers choose MontaVista Linux for faster time-to-market, integration, and stable, fully tested code. We are pleased that Datalight has extended these benefits at  the flash memory file system level, and to provide embedded Linux developers with added performance and reliability,” said Dan Cauchy, Senior Director of Market Development, MontaVista Software.

Other upgrades include a read-only version of Reliance inside the Datalight Loader. This small footprint version permits a bootloader to load an OS image directly from a reliance partition. Devices benefit from risk-free “in-place OS upgrades” enabled by the application-controlled transaction point feature of Reliance. The new versions also feature enhancements in reliability, as well as support for a wide range of new flash parts. FlashFX Pro now supports Spansion NS-P, Samsung FlexOneNAND, Micron 55nm flash parts, and all CFI-compliant NOR parts. The Datalight flash file system solution is comprised of the Reliance file system and FlashFX Pro intelligent flash media manager. Reliance was designed from the ground up for high reliability applications. Dynamic Transaction Point™ technology provides 100% immunity from file corruption, even after unexpected system interruption. Embedded applications can benefit from faster boot times that remain consistent for the life of the product, regardless of disk size.

FlashFX Pro features pre-written support for over 200 flash parts, works with virtually any NAND controller, and features wear leveling, bad block management, and garbage compaction for unrivaled performance. Datalight flash file system products are also available on other operating systems and integrated development environments.

Being in the flash memory management space for 15+ years, a very high number of our customers use our products on flash memory (NAND, NOR, NAND controllers, Fusion flash like Samsung OneNAND, etc). Now FlashFX Pro is designed only for flash memory but Datalight Reliance is a file system that works on all block devices. This includes hard drives, USB flash drives, removable cards like SD, CF, solid state drives (SSD), etc. The advantage Reliance brings to these devices is of reliability against data corruption, fast mount times and fast I/O throughput. It also mandates certain requirements on the physical media to ensure reliability against data corruption. We have had customers use Reliance on hard drives before and I want to share some requirements for Reliance to provide high reliability on rotating media. This post is specific to Linux but the general concepts should be applicable to all OSes.

Reliance is a transactional file system and at each transaction point it flushes all its internal caches and commits the data to disk in atomic operations. Primary requirement for Reliance to function on hard drives is that the hardware and the ATA driver must support the “FLUSH CACHE” command. The Linux IDE disk driver checks bits 12 and 13 of word 83 in the IDENTIFY DEVICE information to determine whether FLUSH CACHE is supported.  These bits are defined by the ATA-6 specification, and are not set in earlier drives.  The IDE disk driver will report whether it has detected this capability in a drive.  This is available in the system log.  A typical message will look like:

Jun  9 09:49:23 billr-qa kernel: [   18.621740] hda: cache flushes supported

Since there are a vast number of hard disks on the market and new ones are constantly being introduced (and old ones discontinued), it is a little difficult for Datalight to qualify all hard drives and recommend a specific one. Generally any disk that conforms to the ATA-6 specification and reports that it supports FLUSH CACHE should work correctly with Reliance.  Reliance reports whether it is able to use flush to ensure correct operation, the system log typically looks like this:

Jun  9 09:52:44 billr-qa kernel: [  240.283463] relfs: block device supports flush.

If this message appears in the log, Reliance should operate correctly when power is interrupted unexpectedly.

Datalight’s power interruption testing has been performed on a Western Digital AC29100D using kernel version 2.6.21.1

If you have any questions on the FLUSH CACHE on an OS other than Linux, please leave a comment.

Continuing the conversation started in Flash File Systems and JFFS2 blog posts, this post talks about a YAFFS, another Linux flash file system alternative. YAFFS (Yet Another Flash File System) was designed to solve some of the performance issues suffered by JFFS2 on NAND flash. Later, YAFFS was upgraded (to YAFFS2) to work with modern, high-density NAND flash. Like JFFS2, YAFFS2 is a log-structured flash file system. YAFFS2 is licensed under the GPL for use with Linux; it also can be ported to and licensed for non-GPL environments, if needed

Interesting facts about YAFFS

1. Reliability against data corruption – As a log-structured file system, YAFFS2 is intended to be power-fail safe, though there have been reports of data corruption during the garbage collection process and cases where YAFFS2 has lost directories.

2. Wear Leveling – YAFFS2 only implements dynamic wear leveling. Wear leveling is not performed for static data. This may cause a higher number of blocks to be rendered useless at a faster rate than if both static and dynamic wear-leveling scheme were available. [For more information on static and dynamic wear-leveling, see our whitepaper on the topic at www.Datalight.com/whitepapers].

3. Performance: According to the YAFFS development team, YAFFS2 will perform best on disks that are greater than 64MB, while JFFS2 is still preferred for smaller disks.

For a detailed look at YAFFS, there is a great presentation on YAFFS by Wookey at Embedded Linux Conference 2007.

Image via Wikipedia

Linux has been slowly but surely establishing itself as the predominant OS in the embedded industry. ABI research report suggested that 23% of Smartphones will be based on Linux by 2013. High-profile industry support from Android and the LiMo foundation has put the spotlight back on embedded Linux.

In a previous post, we talked about flash memory and the various layers of flash management. In this post, I will talk about JFFS2, the most popular flash file systems available on the Linux platform

JFFS2

The Journaling Flash File System version 2 (JFFS2) is a log-structured file system that was originally designed in 1999. The original JFFS was developed by Axis Communications (and later enhanced by Red Hat) to provide support for NOR flash devices. The current version has been updated to include support for NAND flash. JFFS2 is open-source software, distributed under the terms of GPL license.

 

JFFS2 Strengths

 

1. Portability to Development Environments: Included with the Linux kernel since version 2.4.10, JFFS2 has become a de facto standard flash file system for Linux developers. Today, it is included in most commercial Linux distributions (such as MontaVista and Wind River Linux). Because of this wide distribution and use, it has been integrated into many varying environments and is known to be relatively easy to build.

2. Reliability: As changes are made to the file system, a “log” is built; this log provides information about where a file and its associated metadata are located on the flash chip.^[1] As the log is consistently maintained, it will be read back in the event of an unexpected power loss to determine the location of a missing file. Although the log structure provides a level of data reliability, this is accomplished at a cost to performance

3. Support for disk-wide compression: The benefit, or cost, of using compression depends on each specific use case. Compression will be useful in making efficient use of disk space when several text-only or code data (OS, etc.) files are being stored. Media files are already compressed (in *.jpg, *.mpg, or other formats), so the time used to attempt data compression is wasted. It is even possible that media files may take up more space after an unnecessary compression than originally needed. Disk usage and performance for the type and number of files to be maintained must be considered by the device designer in order to determine whether compression will yield a benefit or not

JFFS2 Shortcomings

1. Resource usage: RAM usage by JFFS2 increases in linear proportion to the number of nodes. Hence on large flash volumes, the system resources required by JFFS2 can be very significant

2. System performance: For devices that primarily use the file system for read operations, JFFS2 performance may be acceptable. However, for multi-functional devices whose applications perform a continuous mix of read and write operations, it is likely that the performance of a system using JFFS2 will not pass a rigorous standard. In addition to slow writes, the flash disk mount times of JFFS2 are exceptionally slow and worsen as the amount of data stored increases. Upon start-up after an unexpected power failure, JFFS2 must reconstruct the file system structure from the log. This is a costly operation that requires several seconds – more for volumes that are large or near-capacity. The device will be halted during this check operation, as any data that is stored on the disk will not be ready for use until the start-up completes

Informative links on JFFS2

1. JFFS2 Technical paper [PDF]

2. JFFS2 RAM usage [ppt] – Presentation at Embedded Linux Conf 2007

In the next post in this series, we will look at another popular Linux flash file system – YAFFS.

---

[1] Details on JFFS2 log structure can be found here http://sourceware.org/jffs2/jffs2-slides-transformed.pdf

Flash memory has established itself as the technology of choice for device data storage on embedded devices. The advantages it brings in terms of storage capacity, I/O throughput, power consumption and board space savings are significant. In 2007, flash memory was a $7.7 billion industry. Analysts predict a 23% growth of the flash memory market between 2007 and 20111; surpassing the history-making growth of DRAM ten times over.

One of the barriers to flash memory adoption is its perceived complexity of integration into a product design. With the flash memory market branching to multiple product lines beyond traditional NAND and NOR devices, this perception, along with a concern about the reliability of flash, is becoming magnified. Basic flash management software can lessen the complexity of integration, and sophisticated flash software can ensure the optimum lifetime and reliability of a flash device.

The challenges of integrating flash memory are broad, including operations from the seemingly simple – like reading, writing, and overwriting data – to the exceedingly complex – such as bad block management and wear-leveling. When flash memory is not accompanied by an intelligent software manager, the system will suffer from slow reads and writes, data corruption, and a short usable life.

There has been a lot of interpretations for the term “Flash File System”. Some consider it as the combination of flash management software and a block file system. For some it is just the flash management piece. The following diagram shows the different layers involved in managing data on flash memory and the corresponding terminologies for software components

· Flash Driver: Basic software that provides rudimentary read/write access to flash; this software is often acquired from the chip provider, and is usually part-specific.

· Flash Manager: In addition to the functionality of a flash driver, a flash manager also intelligently determines which part is being used, and handles it accordingly – whether it is NAND, NOR, or a fusion of the two (i.e. Samsung OneNAND, or Spansion ORNAND). Bad block management, wear-leveling, garbage collection, and error detection and correction are features that a flash manager provides. A flash manager may also be designed to take advantage of unique performance or technical characteristics a specific part provides. Flash managers are sometimes referred to as FTL (flash translation layers).

· Flash File System: Contains the flash driver and the flash manager aspects, but also incorporates a file system that is designed for use with flash memory. In the way of performance optimizations, a flash file system includes a discard interface which ensures that erased blocks are immediately available for use by both the file system and the flash manager without additional queries to those blocks.

The following diagram shows the flash file system in perspective of an embedded device

Hope this post was useful in understanding the layers of flash management. In the next post in the series, we will look at various flash file systems for one of the most talked-about embedded OS – Linux.