Recently, we’ve focused considerable development effort on improving database performance for embedded devices, specifically for Android. This is because Android is a particularly database-centric environment.

On an Android platform, each application is equipped with its own SQLite database. Data stored here is accessible by any class in the application, but not by outside applications. The database is entirely self-contained and server-less, while still being transactional and still using the standard SQL language for executing queries. With this approach, a crash in one application (the dreaded “force close” message) will not affect the data store of any other application. While fantastic for protection, this method is quite often implemented on flash media, which was designed for large sequential reads and writes.

For years, benchmarks have touted the pure performance of a drive through large sequential reads and writes. On managed flash media, the firmware programmers have responded by optimizing for this use case – at the expense of the random I/O used by most databases, including SQLite. Another challenge is the very high ratio of flushes performed by the database (sometimes 1:1). The majority of database writes are not done on sector boundaries – especially problematic for flash media which must write an entire block.

While there are a few unified “flash file systems” for Linux such as YAFFS and JFFS2, designed specifically for flash memory, they have fallen out of favor because they do not plug neatly into the standard software stack, and therefore cannot take advantage of standard Linux features such as the system cache. While traditional file systems such as VFAT and Ext2/3/4 can work with flash, they are not designed with that purpose in mind, and therefore their performance and reliability suffers. For example, discard support has largely been tacked onto Linux file systems, and is still considered to be somewhat experimental. To quote the Linux v3.5 Ext4 documentation, discard support is “off by default until sufficient testing has been done.” Another example: file systems on flash memory typically benefit from using a copy-on-write design, which ext4 does not use. The reality is that most file systems are designed for desktop (and often server) environments, where high resource usage is OK, and power-loss is infrequent.

Our solution to improving database performance on flash memory is to provide a more unified solution where the various pieces of the stack work in a cohesive fashion. Furthermore, the solution is specifically designed for embedded systems using flash memory, where power-loss is a common event. Datalight’s Reliance Nitro file system is a transactional, copy-on-write file system, designed from the ground up to support flash memory discards and power-loss safe operations.

The result of our work in this area is FlashFXe, a new Datalight product built on our many years of experience managing raw NAND, but designed for eMMC. When used together with Reliance Nitro, almost all write operations become sequential and aligned on sector boundaries for the highest performance. Internal operations are more efficiently organized for the copy-on-write nature of flash media. A multi-tiered approach allows small random writes with very frequent flushes to be efficiently handled while maintaining power-loss safe operations.

This month at Embedded World, we will be demonstrating the results of our efforts to improve database performance on embedded devices using Android. Prepare to be impressed!

Learn more about FlashFXe

Datalight’s Reliance Nitro and journaling file systems such as ext4 are designed to recover from unexpected power interruption. These kinds of “post mortem” recoveries typically consists of determining which files are in which states, and restoring them to the proper working state. Methods like these are fine for recovering from a power failure, but what about a media failure?

When a media block fails, it is either in the empty space, the user data, or the file system data. A block from the empty space can be detected on the next write, which will either cause failure at the application, or will be marked bad internally and the system will move on to another block. When a media block in the user space fails, it cannot be reliably read. Often, the media driver will detect and report an unreadable sector, resulting in an error status (and probably no data) to the user application. When a media block containing file system data or metadata fails, it is the responsibility of the file system to detect and (if possible) repair that damage. Often the best thing that can be done is to stop writing to the media immediately.

In some ways, blocks lost due to media corruption present a problem similar to recovering deleted files. If it is detected quickly enough, user analysis can be done on the cyclical journal file, and this might help determine the previous state of the file system metadata. Information about the previous state can then be used to create a replacement for that block, effectively restoring a file.

Metadata checksums have been added to several file system data blocks for ext4 in the 3.5 kernel release. Noticeably absent from this list are the indirect and double indirect point blocks, used to allocate trees of blocks for a very large file. The latest release of Datalight’s Reliance Nitro file system (version 3.0) adds CRCs to all file system metadata and internal blocks, allowing for rapid and thorough detection of media failures.

Optional within this new version of Reliance Nitro is using CRCs on user data blocks, for individual files or entire volumes. This failsafe can be configured to write protect the volume or halt system operations. Diagnostic messages are also available to indicate the specific logical block number of the corrupted block.

The combination of full CRC protection on every metadata block and optional protection of user file data blocks is one of the key attributes of this release of Reliance Nitro. Embedded system designers can detect more media failures in testing, and can diagnose failed units more quickly, leading to greater success in the marketplace.

Learn more about Reliance Nitro

We’re constantly on the lookout for ways to help our customers boost performance and improve power efficiency, and often our inspiration comes by way of the conversations we have with them. Recently, several of these discussions highlighted user scenarios where the complexity of the application would benefit from an enhancement to the classic Dynamic Transaction Point™ technology found in our Reliance Nitro file system. Here are a couple examples of the user scenarios I’m talking about, specifically for multi-threaded environments:

In a multi-threaded system, the activity among threads can be unpredictable, sometimes requiring multiple writes by the file system to the media within milliseconds. Each write requiring its own transaction commit or flush by the file system takes a toll on performance with no real reliability benefit.

Another challenge in a multi-threaded system is power efficient utilization of the processor when the file system is configured to commit data after specific time intervals. These transactions “wake up” the processor just to generate a request, even though no actual commits or flushes occur if there was no disk activity since the last transaction point. This unnecessary activation of an inactive processor is a waste of valuable power. By suspending thread activity until new disk activity occurs, battery life could be extended significantly.

Understanding how customers use the configurable transaction points of our Reliance Nitro file system was instrumental in improving Reliance Nitro. Below is a little background on Reliance Nitro and Dynamic Transaction Point technology:

The Reliance Nitro file system is a highly reliable, power interrupt-safe transactional file system. Keeping the reliability intact without risking loss or corruption of data means that customers have the flexibility to configure when a “transaction” (i.e. a set of operations that constitute a change as a whole), is to be written to the storage media from cache. This can even be done during operation of the device (run time), and includes the following options:

(a) Timed: Transacts or commits to storage media after a specified time interval (e.g., commit data to storage media every 10 milliseconds).

 (b) Automatic: Transacts every time a file system event happens (e.g., handheld scanner commits every time the database file is written to (file_close)).

(c) Application-controlled: Transacts every time all conditions are met (e.g., several files that are dependent on each other and need to be updated together have been all changed.)

Using these options in combination gives customers the flexibility to choose under exactly which conditions they want to transact and protect important data, precision that enables total control over the balance between performance and protection for any use case.

Our efforts to address the needs of our multi-threaded customers described at the beginning of this blog post have led us to the next big breakthrough in embedded file system design, and the next big feature for Reliance Nitro. I will be blogging more about this feature soon!

Also coming soon, keep an eye out for our 2012 Customer Survey, another way we seek to continuously improve our understanding of what our customers need. We sincerely hope to get your feedback on the survey, but don’t hesitate to contact us anytime if you have suggestions for improvement.

Learn More About Dynamic Transaction Point technology

It’s always gratifying when you run benchmarks and discover your product actually does outperform the competition. Months and months of development effort went in to making Reliance Nitro and FlashFX Tera run flawlessly in an open source environment. We were pretty sure our transactional architecture beat the pants off YAFFS2, JFFS2, and UBIFS, but until you run the final benchmarks, you really don’t know for certain. Recently we ran tests on two platforms, a ConnectCore Wi-i.MX51 (Cortex-A8) and an NVidia Tegra 2 (Cortex ARM9). The Flash part used for all tests was a Samsung 512 MB part. The specific test used was IOZone, with a specified file size sufficient to be larger than the Linux cache, in order to better reflect the raw throughput. The results speak for themselves:

Also see an article weighing the pros and cons of JFFS2

If you’ve noticed the numerous posts lately on the Datalight blog regarding JEDEC and eMMC, you might be wondering why we’re so excited about this particular standard. There are many features that this “smarter” memory will enable for OEMs; In this post I’ll focus on one of those features in the eMMC specification –secure delete.

Securely deleting information on flash memory is more complicated than it seems. For one thing, files are constantly being moved around to ensure even wear of the flash, resulting in multiple copies of file data on the media. Furthermore, when a file is marked for delete, it is typically not physically deleted, rather the space is only marked as available to be overwritten. Until that happens, the “deleted” data is still present and recoverable on the media. In fact, the University of California San Diego Non-volatile systems lab has produced an in depth study of file deletion on flash memory, where they found significant data still present on the media even after deleting the files. A copy of the report can be found at: http://cseweb.ucsd.edu/users/swanson/papers/Fast2011SecErase.pdf

In order to securely delete a file on raw flash, you must use a controller that will either track every block where the file has been stored, or will overwrite the space the file was stored in each time it is moved. The latter describes exactly the secure erase and secure trim features found in the eMMC 4.41 standard. This means that the hardware will finally be capable of securely deleting files –brilliant! There is just one problem: Who has software to support this functionality? As of this writing, there is no file system which supports the feature. While an application can make a call to the media to delete a file securely, the file system may have a backup copy stored somewhere. Fact is, the file system must support the secure delete capabilities of the hardware in order for these features to function correctly.

If an OEM wants to take advantage of the secure erase and secure trim features, their application will need to communicate with the eMMC driver, which may differ from part to part. As the only software company that is an active member of JEDEC, we are excited offer support for quite a few eMMC features. File system support for secure erase and secure trim will be coming later this summer!

Learn more about Datalight Embedded File Systems

Today we released our newest version of RWD (Reliance Windows Driver) with support for Windows 7. This is very good news for manufacturers and users of devices that need exchangeability with a Windows desktop, but can’t or won’t compromise performance and reliability to get it. As Windows 7 is enjoying much stronger adoption than Vista, we anticipate strong demand for RWD as well (it also supports XP and Vista). Check out the official press release for more details on this new version of RWD.

Earlier this month (June 4th) SpaceX sent the Falcon 9 rocket on its maiden voyage from Cape Canaveral Air Force Station with a successful orbital insertion. Falcon 9 is a reusable spacecraft which will be used to resupply the International Space Station under the Commercial Orbital Transportation Services (COTS) program. We are delighted that SpaceX selected Datalight Reliance and FlashFX Pro to protect mission-critical data from the rigors of space travel, such as shock, vibration, temperature extremes and radiation. Emily Shanklin,Director, Marketing and Communications for SpaceX had this to say: “Datalight software enables reliable flash-based embedded computing for SpaceX’s upcoming Falcon 9 and Dragon spacecraft missions in the data-hostile conditions of space.”

Earlier this week we announced XCFiles, a design-ready exFAT-compatible file system for next-generation extended capacity SD (SDXC) cards. Visit Datalight.com to read the full announcement or learn more about our exFAT implementation

We just announced support for Linux Kernel Version 2.6.34. Read the full announcement here:  http://bit.ly/c3UqXk

Blackboard is the standard-bearer for student ID systems around the world. Their contactless cards serve as campus ID, building access, and point-of-sale accounts for meals and other services, and are rapidly replacing the old magnetic stripe systems. The cards and readers use a Windows Embedded CE-based platform. When Blackboard’s BSP provider learned that the systems would be responsible for keeping track of sensitive financial transactions, they recommended Datalight software to make certain that the system will function with bullet-proof reliability. To read more about our work with Blackboard, check out the full success story.