Update Since publishing, EECatalog is no longer. We’ve moved the original article to our own blog: SLC NAND Secrets Exposed.
This whitepaper is the result of many months of effort, working together with our customers in the field, in troubleshooting and coming up with an “smoking gun” explanation and solution for a decrease in SLC NAND flash endurance. It’s valuable information for any embedded system users who rely on their data and filesystem to be free of corruption. Be sure to read the full whitepaper at SLC NAND: Secrets Exposed at EECatalog.com (WayBack Machine Archived Link).
While you’re at it, you may want to take a look at our related articles, featuring the solution we came up with for the decreased flash endurance, XNAND2: NAND Device Driver for Todays Lower Endurance SLC NAND, and how to further prevent data loss, Whitepaper: Preventing Filesystem Corruption in Embedded Linux.
From the Archives: This article was resurrected from our white paper archives from back in December of 2004. Principles presented should be long-enduring, but there may have been some changes in the NetBSD/Linux/Unix marketplace since.
NetBSD is very similar to Linux (and actually can run Linux binaries), so you may be asking yourself why one would choose to run NetBSD instead of Linux? I will list the most common general reasons cited that apply to specifically to embedded systems designers. Wasabi Systems also has a very well written write-up describing Linux vs. NetBSD and even a guide for OEMs migrating from Linux to NetBSD.
Continue reading “NetBSD/evbarm Support on the TS-7200”
If you’ve ever been concerned with or experienced disk and filesystem corruption in an embedded Linux environment, you’ll want to take a look at this whitepaper to help you understand and prevent it.
Preventing Filesystem Corruption in Embedded Linux
Almost any computer system is subject to unexpected power failures. For some embedded systems, this only occurs when the power grid goes down. For others, it may happen when a user decides to pull the plug instead of using a documented shutdown procedure. Automotive and remote systems need to anticipate that power will stop and start several times a day. If an embedded system is implemented without thinking about what happens when the power goes down it could lead to catastrophic failures down the road. Due to the nature of failures caused by unexpected power loss an embedded system may run for weeks, months, or years before users experience an unexpected and catastrophic failure. From the user’s perspective, their device worked fine yesterday and today it doesn’t even turn on, and they don’t tie it back to the unexpected power failure event.
One collection of failure types caused by unexpected power loss are those related to issues with the boot medium. Investigating the boot medium failure as a result of power loss may show an unclean filesystem, missing files, or more commonly a filesystem that only mounts as read only. The latter happens when the filesystem detects a serious problem with filesystem metadata during runtime that it cannot fix automatically causing it to remount read only to avoid writing to prevent further corruption on the disk. Many people turn to common journaled filesystems like ext3/ext4 to attempt to address these failures. While journaled filesystems like ext3/ext4 are less prone to corruption, they are far from immune.
Read the rest on Technologic System’s offical website, Preventing Filesystem Corruption in Embedded Linux