Bureaucrats, dave_user, Administrators
737
edits
Changes
→Power failures
(*) Roughly speaking, this means that these file systems are able to keep their consistency across such events. They can not avoid data loss if a power failure occurs in the middle of a write operation, however. For this reason, further countermeasures, such as data redundancy and/or the use of error-detecting/correcting codes, should be implemented at the application level for particularly important data. At the hardware level, DAVE Embedded Systems products usually leverage the "write protect" feature of flash memories in order to prevent erase/program operations during power transitions.
=== Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system over UBI partition ===
Even if both UBI and UBIFS [http://www.linux-mtd.infradead.org/doc/ubi.html#L_powercut are designed with power-cut tolerance in mind] without having support from additional hardware (e.g. supercap, battery power supply and so on) some data might be lost and some ''weird'' effect happens when not performing a clean shutdown of the system.
E.g.:
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_empty_file zero-file length corruption]
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_end_hole trailing zeros on files]
Additional failure like [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_sudden_ro UBIFS mounted as read-only] at boot time usually do not depend only on power-cut but are symptom of major failure (buggy MTD device driver, storage device hardware failure, device wear-out, major EMI and so on)
When designing application to be as safer as possible w.r.t. power-cut, please also take care of:
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_atomic_change information of how to change a file atomically]
* [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writeback notes about UBIFS write-writeback support]
== Memory health monitoring ==
