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

If you’ve been following this blog, you’ve probably noticed a lot of discussion and analysis around eMMC. We’ve written about the reasons we are so excited about eMMC, but also why the Write Amplification issues caused by eMMC parts are a problem that needs more attention by the industry.

As more and more device manufacturers use eMMC in their devices, product reviews are beginning to highlight some of the limitations of eMMC that we have been discussing. A case in point is this recent review of Google Nexus 7 by Anand Lal Shimpi and Brian Klurg.

As the review points out, the performance downside of using eMMC parts is that they are “optimized for reading and writing large images as if they were used in a camera.” Also, eMMC was never designed to be used by a “full blown multitasking OS,” and therefore can cause major problems with device responsiveness. This is mainly because multi-tasking (i.e. any other action performed while download is in progress) effectively “turns the IO stream from purely sequential to pseudo-random.” This corroborates with our view that many eMMC parts are not equipped for optimal performance for random reads and writes. The authors’ benchmark results (below) underscore the severity of the problem:

So, how can device manufacturers get better performance from their eMMC parts, and continue to leverage the simplicity of programming and consistency of design parameters that eMMC offers?

Simplistically put, the eMMC driver is responsible for flash-aware allocation of data to flash memory. The combined layers of the driver and the file system, sometimes known as the flash file system, is the level at which hardware behavior can be translated to software behavior in a way that enhances performance without compromising the endurance and data integrity.  Also, the complementary interaction between the driver and the file system layer can bring further benefits to the device performance, endurance and reliability. Getting this part of the system right goes a long way to solving eMMC’s write amplification problem.

Here at Datalight, we have been researching the most efficient way of doing this, drawing on our decades of experience of developing driver and file system software for a wide array of flash parts. Stay tuned for more in-depth explanations on how we’re doing it, but for now we are very excited about the early test results we’re seeing in our lab, especially enhancements combining an optimized file system with our new eMMC driver.

Learn more about Datalight's eMMC solutions

Embedded device designers have to come up with systems that handle variations in network traffic, resource constrained environments, and battery limitations. All that pales in comparison with challenges at system start and power down times.

In powering down a multi-threaded device, each application will want to get state information committed to the media. The operating system will have its own set of files or registries to update before the power goes off. At the low end, the MLC NAND flash or eMMC media requires power to be maintained while writing a block, in order to prevent corruption of that or other blocks on the media. Therefore a large group of block writes arrive at the media level simultaneously, all with the requirement to finish up before the power drops.

The only thing worse than having to perform several writes in a short time frame is when those writes display the worst performance characteristics of eMMC media. These block writes are often located in different locations, essentially defining Random I/O.

When restoring power, the same situation occurs in reverse, with each thread requesting state information. For some file systems, the interrupted writes will need to be validated, the file system checked, or the journal replayed. Here the time pressure is not with actual loss of power, but with frustrated users, who want the device to be on, now!

This is a very important use case to consider for designers of file systems and block device drivers. While shutdown consists of primarily writes, a multithreaded file system should not block reads. The same applies at startup time, where a write from one thread should not block the other read threads. Where possible, the block device driver should sequence the reads and writes to match the high performance characteristics of the media, allowing the most blocks to be accessed in the least amount of time.

We are currently working on an eMMC-specific driver that will manage the sequencing of writes. It promises to improve write performance by many times the rate of standard drivers. Check back with us for more on this topic next month!

If possible, applications should also be written to minimize the startup and shutdown impact. With more applications being written by outside developers, this is getting harder to control. The system designer must focus on what they can control – choice of hardware, device drivers and file system to mitigate these problems.

Learn more about eMMC

Today’s embedded applications such as digital cameras, smartphones, and tablets almost always store their content on flash memory. In the past, this has required a dedicated controller to manage the reading and writing of data, driven by the application CPU. However, as semiconductor technology has evolved to allow vastly increased storage density, it has become inefficient for the controller to manage these functions from outside the flash memory die. Hence, eMMC was developed as a standardized method for bundling the controller into the flash die. As eMMC has improved, the standard has also provisioned for features such as secure erase and trim and high-priority interrupt to meet the demand for high performance and security. So while the eMMC standard was created to improve data rates and throughputs for high-density chips designed to store high-resolution video, newer generations are doing more for more applications, and each generation of the standard will include additional new features for a richer end-user experience.

Read more about eMMC

We here at Datalight are seeing a lot of interest in this weeks “Software Perspective on eMMC” presentation, across a broad spectrum. This is apparently a pretty hot topic!

If you are interested in joining us, seats are still available – http://www.datalight.com/welcome/web-seminar-switching-to-emmc

A recent article by Doug Wong compared performance characteristics of eMMC and ONFI specification EZ-NAND, specifically Toshiba’s SmartNAND here: http://www.eetimes.com/design/memory-design/4218886

One consideration I would add to this quite excellent summary is about the availability of drivers. Raw NAND has been around for quite a while and the market supplies a large range of drivers. Many of these will utilize the basic functionality of SmartNAND and other EZ NAND chips with only small modifications. Drivers for eMMC, on the other hand, are much harder to find. Only Linux has a freely available driver, which Google’s Android has taken advantage of in recent releases.

At Datalight, we continue to be excited by both of these new technologies. From the JEDEC eMMC parts, the cool features such as Secure Delete and Replay Protected Memory Block are very exciting. On the other hand, the sheer performance of Toshiba’s SmartNAND and other EZ NAND solutions is very much in demand.

Lately you may have noticed a lot of talk about eMMC on our blog and website. If so you may be thinking, “Why is Datalight so excited about eMMC?” Here are 5 top reasons we’re jumping on the eMMC bandwagon:

#5) Standards: Having a standard specification for hardware like eMMC enables our customers to spend less time integrating new hardware and more time focusing on their core competencies.

#4) ECC: As NAND flash lithography shrinks and density increases, error correction has become exponentially more complex and therefore difficult to do in software. Performing ECC in the hardware, like eMMC (or OnFI EZ-NAND parts like Micron’s ClearNAND), overcomes this problem and offers much simpler integration.

#3) Performance: In combining an accepted standard with on-board ECC, eMMC offers excellent performance and flexibility for customers.

#2) Advanced features like secure delete: With more critical data being stored, data security is becoming a much bigger issue. We’re happy to see a standards body like JEDEC focus on tackling this problem. And since customers will need a file system capable of enabling this feature, we’re delighted to be the first to offer support for eMMC 4.41 features like secure erase and secure trim.

#1) Customers: More and more of our customers are either evaluating or using eMMC. Whenever we see our customers using a new technology we ask ourselves how we can help enable them to take full advantage of it. Exploiting the features of eMMC at the file system level is a win for all of us.

Learn more about Datalight flash management solutions

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

The topic of storage technology seemed to be everywhere at last week’s Embedded Systems Conference in San Jose, appearing in numerous key note speeches, presentations and exhibit booths.  It appears the industry is waking up to the difficulties of storing and managing a torrent of data being produced by new mobile applications.

Micron’s presence both on the show floor and conference sessions highlighted their philosophy of creating application-specific storage technologies. In particular, Tom Eby’s keynote address considered both ends of the device and storage spectrum, dividing the market into devices that run applications and those that don’t, that is, devices that demand LOTS of Storage and those that run on meager memory systems (i.e., feature phones).  An interesting side note for Micron customers, Tom announced Micron’s Product Longevity Program (also referred to as PLP) which assures developers availability of Micron flash parts for a 10 year period – especially helpful for makers of long-life-cycle embedded products. Also from Micron, Wanmo Wong gave an excellent presentation on flash file system options for Linux and Android in which he expounded a laundry list of questions that must be answered when making that selection. It was just the right amount of detail for a Linux and flash memory newbie, highlighting the sheer number of issues that must be addressed when selecting the right flash file system for a particular application.

The Woz’ (Steve Wozniak, chief scientist at Fusion-IO) gave a lively fireside chat on the challenges and roadblocks for passionate engineers, from societal problems like our school systems’ failure to nurture brilliant engineering minds, to the difficult balance between getting a (sometimes tedious) job done and following your engineering passion.

Virtually every storage technology was on display from the embedded storage vendors around the globe, from PCM (Phase Change Memory) chips, to eMMC 4.41 parts, to on-board storage, USB and 2-1/2 inch HDD form factor solutions.  Flash storage solutions were presented by Apacer, Innodisk, Viking, STEC and others.  In a sea of slick memory packaging, the Viking example below really screamed embedded to me…

On the Android front, Datalight demonstrated how open source and great proprietary solutions can come together and give developers the best of both worlds. Our temporary home in booth 2320 featured this sneak preview of our upcoming Android support on a TI Beagle board. The tiny-but-slick Android demo is shown at Jimm’s right elbow.

Learn more about Datalight products for Linux/Android

The hot topics in the consumer electronics segments today are Android, installable applications, sexy user interfaces, sensors like GPS receivers, gyroscopes and accelerometers and larger capacity/smaller size storage. Ever since I read Roy’s blog post on CES, I’ve been asking myself when we’ll start seeing the impact of trends in consumer electronics on the more general embedded market. Just as buying a car causes you to see that model everywhere, it seems like asking the question has made it so. In the past few weeks we’ve seen a dramatic increase in the number of customers considering a move from traditional RTOS’s to Linux – more specifically, Android. Many are in the “tire kicking” stage and may never make the switch, but the tide has clearly turned in that direction. The appeal seems to be a combination of user interface – which becomes more important as data use, which has also taken a leap skyward on embedded devices, increases – and ease of application development, perhaps even leveraging the burgeoning application marketplaces that have developed around smartphones. Then again, much of what’s happening in the consumer electronics space is old hat in embedded systems: working in resource constrained environments, power efficiency and dealing with ruggedness requirements.

I guess the real migration is that consumer electronics are combining technologies proven in embedded into multifunction devices, smaller packages with slicker form factors to meet the trendy demands of consumers.

Learn more about Datalight for Linux