Autor: Thom Denholm, Datalight Inc.<\/p>\n
From dropped batteries to system failures, embedded designs require solid power interruption testing. Durability demands for embedded products have increased as the expected lifetime of high reliability products has grown. Faced with these conditions, developers must expand their testing toolkit. To achieve the most comprehensive reliability testing in the least amount of time, stress testing\u00a0must\u00a0utilize I\/O at the point of power interruption.<\/strong><\/p>\n When your team is responsible for validating the reliability of a design for the embedded marketplace, you need to do more than just tick a box or read a marketing document. Real testing of reliability involves getting into the guts of the embedded design, and covers everything between the application and the hardware. This whitepaper is focused on testing the file system and its interactions. Catching a vulnerability in design or testing is far more efficient (and far less expensive) than handling problems in the field.<\/p>\n Reliability can be defined as: whatever a given customer thinks it is. Powering up and starting the OS are a requirement for nearly all devices, and being able to start the primary device application is very important. Without those, the user must wait for a system restore. Many customers expect their favorite settings or programmed routes to be available and reflected in their next use of the device. Elite customers (and some certifications) require an even higher definition of reliability. They need to start up with settings changed immediately before the power was lost.<\/p>\n (see\u00a0PDF\u00a0<\/a>image 1)<\/p>\n It is safe to say that even though the needs of the individual customer vary, the testing bar must be set quite high. Likely higher than the average developer expects.<\/p>\n Examining the previous cases from the computer point of view, the first is related directly to the system files. Sudden power loss could corrupt other files, as long as it doesn\u2019t touch the system files. One trick used by developers is to put the system files on a separate partition or even separate media to achieve this goal. Files can be marked read only, though that only keeps the file system from touching them.<\/p>\n To save the end user settings, those changes have to make it to the media. On embedded Linux, for instance, those changes must make it through the write-back cache and any buffers. The data also needs to clear any hardware block cache. In time, all the data will eventually be flushed \u2013 if the user waits long enough, their settings will be saved.[1]<\/a><\/p>\n In addition to user data, the file system metadata also must be in the appropriate place. For most file systems, Linux flush and fsync commands are used to achieve complete control of the file system, which is the only way to ensure data is committed to the media.<\/p>\n That control over the file system and block device are the key to the final use case, where the data must be committed immediately \u2013 waiting for the block cache to time out is not an option.<\/p>\n The next step is to refine the granularity even more \u2013 what happens when the power is interrupted?<\/p>\n Writes can be interrupted at any point, primarily when power is lost. This results in two options \u2013 the system could be in the middle of writing a block or in between writing blocks.<\/p>\n On older magnetic media, an interruption in the middle of writing a block would leave a partial write. The block being written is corrupted \u2013 it likely contains fragments of new data and old data. If this was the only copy of that data, it is lost \u2013 and the file that contained it is probably useless.<\/p>\n New NAND based media, from SSD and eMMC to SD and CF, have an even larger problem with interrupted writes. It is so big that vendors specifically recommend maintaining power during block writes just to avoid it. Assuming that media power is maintained with a capacitor or other technique, an interrupted write becomes instead write interruption between blocks.<\/p>\n From the user perspective, each write consists of one or more blocks of data, along with any metadata that must be written. If a given write is a small amount of data, up to one block, with no metadata changes, then power interruption won\u2019t be a problem. For larger writes, an interruption between write blocks will interrupt what is known as an atomic operation.<\/p>\n [1]\u00a0https:\/\/www.datalight.com\/resources\/whitepapers\/reliably-committing-data-in-linux<\/a><\/p>\n File systems such as FAT don\u2019t do anything special for an atomic operation, so interrupting one of those is not much better than a mid-block interruption on magnetic media. The file being written to has some updated blocks and some not yet updated. For most user data, this is enough to render the file useless.<\/p>\n Metadata should also be part of an atomic write. If it isn\u2019t, one of two situations can occur. If the data is written but the metadata has not been, the data would be lost as the system recovered from power interruption. A potentially worse case is if the metadata is written but the data has not yet been. A system recovering in this situation would then try to open this updated file and find either garbage or, worse, other data from the media \u2013 a potential security risk.[2]<\/a><\/p>\n Testing to make sure longer writes are committed the way a system designer expects is another requirement for comprehensive testing.<\/p>\n At this point, the developer has an expectation of how data will be written and\/or recovered as part of a power interruption. This is all assuming the writes happen in the order they were initiated, which is not always the case. Complete testing should validate the expected state of the media after interrupted writes.<\/p>\n On Linux file systems, there is a particularly persistent myth that opening a file with O_DIRECT is all that is required for data to be reliability stored on the media, and the fsync() command would not be necessary in this case.<\/p>\n We measured the performance of sequential writes using fsync, O_DIRECT, and neither. The orange bar represents the maximum speed of the media, 225 MB\/sec. This demonstrates that O_DIRECT is writing only to the DRAM cache, and is not sufficient to guarantee reliability.<\/p>\n 2\u00a0https:\/\/www.linux-magazine.com\/Online\/News\/Linus-Torvalds-Upset-over-Ext3-and-Ext4<\/a><\/p>\n (see\u00a0PDF\u00a0<\/a>image 2)<\/p>\n Flushes, user and metadata writes, and handling interruptions during and between block writes covers the basic reliability testing for normal system use. The next thing to focus on is system stress \u2013 unusual cases that will likely occur in the field.<\/p>\n The first of these that most developers don\u2019t examine is what happens when the disk is full. Besides the potential performance implications, a disk full situation can generate more writes as garbage is collected. Related to that are extreme situations in the number of files \u2013 does the system latency increase noticeably beyond the first 100 or so files? Both of these situations lead to a larger write error window \u2013 and a larger potential for failure.<\/p>\n Another stressor is a system update. This is a situation that is especially important to test thoroughly, especially when power interruption may occur. Atomic writes here can be a major factor which allows the device to recover from a failed update.<\/p>\n Extreme use cases also hit the media especially hard. In the case of NAND flash media, thousands of reads from a given file can cause read disturb, adding bit errors to the media. If these bit errors are not taken care of (a process called scrubbing), the correctible errors can grow to uncorrectable errors.<\/p>\n Other potential media failures include some of these items:<\/p>\n Another storage related item is discards \u2013 using the trim command to inform the media that data is no longer in use. On devices where discards are not used (or under-utilized), latency can increase noticeably once all the blocks on the media have been written once. This increase latency causes a noticeable drop in performance; when writes take longer, the potential error window grows.<\/p>\n For that matter, the firmware on most NAND based solutions is a black box. What is happening when the media is busy discarding data or wear leveling or garbage collecting? What happens when the power is interrupted during those operations? Using the file system to generate these sorts of failures can be very hit or miss, and a custom media test should be developed to validate its operation during a variety of power interruptions.<\/p>\n We have examined a number of methods that can be used to generate more effective power interruption testing, so now we must put them all together.<\/p>\n First of all, interrupting an embedded device while quiescent or while reading will result in nothing being lost, unless it is updating something in the background. So power interruption testing needs to trigger those background writes where possible and, most importantly, focus on the writes. Random power interruptions during writes are most likely to exercise the safety routines of the file system and application.<\/p>\n The next step is validating the data written, not just the structure. Make sure that what is most important to your customer is being confirmed here \u2013 overwrites and completely atomic operations. If data is overwritten in place, then an entire operation must be atomic to prevent a corrupt state \u2013 half old data, half new data, all useless.<\/p>\n While the user data is important, the system files can be even more important. If corruption of other files affects system files, the entire device can be rendered unusable. The same could happen if power interrupts an unprotected system update.<\/p>\n Most file systems provide a utility based on chkdsk to detect these sorts of failures, though they can\u2019t usually correct them very well.<\/p>\n The original MS DOS chkdsk found data that was on the media but not represented in the file allocation table (FAT) and also could find a number of errors within the FAT. It was not able to connect that data to file names, so files full of lost chains and other errors resulted in nearly useless files such as FILE0001.CHK \u2013 taking up space but not useful for most applications.<\/p>\n The best testing meets both the needs of the strictest users and the goals of stressing the system in the best way. Interruptions during writes will demonstrate the most failures and accurately reflect field stress. Other factors to consider include validation of data, atomic operations and cases that also stress the media. Real testing of reliability is more than just a requirement, it also leads to long term success of the embedded design.<\/p>\n Thom Denholm is an experienced embedded software engineer, combining a strong focus on operating system and file system internals with a knowledge of modern flash devices. He has a degree in Mathematics and Computer Science from Gonzaga University. His love for solving difficult technical problems has served him well in his seventeen years with Datalight. In his spare time, he works as a professional baseball umpire.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Test, Qualit\u00e4t & Debug.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Test, Qualit\u00e4t & Debug steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nDefinition of Reliability<\/h2>\n
System reliability vs Data on the media<\/h2>\n
Write interrupted mid-block<\/h2>\n
Write interrupted between blocks<\/h2>\n
Validate the written data<\/h2>\n
All I need is O_DIRECT<\/h2>\n
Stress!<\/h2>\n
\n
Discards (the Trim statement)<\/h2>\n
Tactics for effective testing<\/h2>\n
Check the disk<\/h2>\n
Conclusion<\/h2>\n
Author<\/h2>\n
\nTest, Qualit\u00e4t & Debug – unsere Trainings & Coachings<\/h2>\n
\nTest, Qualit\u00e4t & Debug – Fachwissen<\/h2>\n