Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am developing an application on a Linux embedded board (runs Debian) e.g. Raspberry Pi, Beagle Board/Bone, or olimex. The boards works on an environment that the electricity is cut unexpectedly (it is far complicated to place PSU, etc.) and it would happen every day couple times. I wonder if the unexpected power cuts would cause crash/problem on the Linux Operation System? If it is something that I should worry, what would you suggest to prevent the damages on OS against the unexpected power cuts?

PS. The application needs to writes some data to the storage medium (SD card), I think it would not be suitable to mount it as read-only.

share|improve this question
1  
Stay away from ext2 (use ext3 or higher) on filesystems you modify a lot, and you should be OK for the most part. –  ultrasawblade Jun 25 '13 at 16:14
    
Unless you are very careful in spec'ing your SD cards, the cards do not guarantee anything if you cut power unexpectedly. The card could be in the middle of a wear-leveling move, leading to weird, unexpected corruption—which could even be in a different partition! –  derobert Jun 26 '13 at 20:25
    
I don't know exactly how to do it, but you may want to consider making your key applications transaction based. That way, you can have your current file and a backup. You apply the transactions to your current file and if that fails, you can restore the current file from the backup and reapply the transactions. If you switch between current and backup using symlinks or swapping file names, then that can happen very quickly with much less chance of error than with copying. After a successful update, your current file becomes your backup and the backup becomes the current. –  Joe Jul 1 '13 at 21:07
    
Continued. This almost works. The new current file would also need the transactions applied to it necessitating processing the transactions twice, so I'm sure there's a better way. In any case, it may still be a lot faster and safer than copying the whole file if it's big. –  Joe Jul 1 '13 at 21:14

4 Answers 4

up vote 13 down vote accepted

Unexpected power cuts may cause corruption of file system data - e.g. if a process has started writing to a file, but not yet finished writing it, the file may end up only half written. Now imagine if the power cut happens when you're half way through a kernel upgrade...

As l0b0 wrote, using a journaling file system will help, since it will be able to keep track of what has actually gotten done. In addition to the wikipedia info that l0b0 linked, you may be interested in http://unix.stackexchange.com/questions/12699/do-journaling-filesystems-guarantee-against-corruption-after-a-power-failure as well.

You as a programmer obviously need to consider carefully how to handle writing to files so that it becomes an atomic process (i.e. it's either fully done or not done at all, but never ever half done). It's a fairly complex issue.

share|improve this answer
9  
The general process in code for protecting against write interruptions corrupting a file is that instead of modifying file.name directly, you instead write an entirely new file file.name.newversion, and then use delete/rename commands to replace the old version with the new one. You need to add cleanup code to recover from an interruption at each step; but this approach always leaves a good copy of the file on disk. This can impact your design since it performs poorly updating single huge files or making frequent changes to a single file. –  Dan Neely Jun 25 '13 at 15:07

To help minimise the possibility of OS corruption, it's probably best to have separate "system" and "data" partitions on the SD card. That way you can mount the "system" partition read-only and use a highly-resilient FS on the "data" partition.

Additionally, most of those boards have very low power requirements, so a battery backup is possible. The "LiPo rider" board for the Raspberry Pi can be used as a basic UPS to provide a clean shutdown on power loss.

share|improve this answer

This would depend on

  1. whether you're using a journaling file system and
  2. how well the applications are able to handle aborted processing.

Consider for example an application which processes a file and writes the results as they are computed (one output line per input line) to another file. If the power is cut during processing, and the same application is run after restarting, it can't just restart processing from the start of the input file - that would mean the output file would contain duplicate information.

It could be very difficult to say anything definite about a hypothetical complex system, but most stable Linux software seems to be able to handle crashes quite nicely.

share|improve this answer

Since no one mentioned any specific filesystems: more modern filesystems (ext3, ext4, ntfs) are able to handle crashes much better than older filesystems (ext2, ext, fat32) due to journaling.

Assuming the hard-drive does not crash and does not lie, a complete power failure should not corrupt the filesystem. Individual files that were being written may still be corrupted, though, so if you were in the middle of updating the OS when the power failure occurred, it is still possible to bring down the OS.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.