OLinuXino - Prevent SD Card or NAND corruption - Power Loss

[cspurr]

I have been reading a lot about how FS become corrupt if Linux is not properly shutdown and power is pulled, etc. Most embedded systems normally need to survive such an event and reliably, without intervention, just work. I have read about different methods for preventing FS corruption in embedded Linux applications. These include using read only FSs, Battery backup detection circuits, different partitions, etc. I would like to use the OLinuXino line of cheap open HW/SW SBCs as a platform for commercial products, but I would obviously need them to be reliable in the field. I was just wondering if anyone else has done this and what may be the cheapest reliable solution to prevent OS/FS corruption during a loss of power, even if a battery backup is used to trigger a proper shutdown? Even backup batteries fail, in which case there is still the potential of having to field service a unit, which is not feasible with the different applications I have in mind.

Any information is always greatly appreciated.

Thanks.

Chris

[Chax]

Depending on your application you could use AUFS. I tried something like this a couple of years ago on an Alix PC (http://code.google.com/p/debian-for-alix/). AUFS basically mounts the partition read only and all files that are written are not really written to disk but kept in RAM. This way the filesystem would not corrupt because on a reboot you get the old image again. When you want to write files to the system you run some command to reflect changes to the actual disk.

In my application the complete Debian system was running on this filesystem but the files I needed to write were written to a separate partition on the disk. In case of a power failure the system would reboot, format that partition again to make sure there is no corruption (but obviously loosing all files) and just start everything from scratch.

I see some messages about AUFS not being in the mainline kernel anymore or plans about removing it. It worked fine when I tested it though.

[lambda]

Hi Chris,

I think OpenWRT already goes a long way of what you need.
There is no official imx23 support in openwrt yet, but
the necessary patches are already posted for review and
in my experience work great - I only enabled additional
modules to have usb-storage and asix support (USB-Ethernet)
available. Perhaps also enable GPIO sysfs support if you
want to control gpios from userspace.

HTH,
Harald

[cspurr]

Thanks for the responses! I look into those options.

Thanks again.

[Stinde]

Using read only FS and tmpfs directory could be solution in some cases.

tmpfs is also useful if you try to avoid SD Card wearing. Of course all data in the tmpfs directory is lost after power down. As the name says it is for temporary data.

I think Debian has /media/ram as tmpfs as default.

EDIT:
Here is an article about preventing file system corruption in embedded linux:
http://www.embeddedarm.com/about/resource.php?item=459

Timo

[jeroends]

I' doing an experiment with ramlog (http://www.tremende.com/ramlog/ unfortunatly the site isn't always working). This is simply a scipt that creates a virtual log dir (or another) and syncs it using rsync once a day and by shutdown. This will be used in combination with a backup battery and detects when it is on battery to sync the ram dir to the sd. This way the data will not be lost and the system will properly shutdown.
For a normal board, I 'll be using a ltc441 (ideal diode) to switch from mains power to battery and this in combination with a stepup convertor (I'm waiting for the schemtics of the new nano board since they are doing somehow the same thing  ). Now it's just waiting for the samples of linear technology to arrive to see if I can get it all working. Maybe interresting for Olimex to design a simple board including the lipo charger and stepup convertor. I'll put my findings here somewhere if I got it working since I got some minor issues (what to do when the powers comes back up, shutdown power completly or not to reset the device, etc etc)

[cspurr]

Here is an email thread I had with someone from Olimex, looks like safe shutdown is built in when using the LiPo as a backup battery. I am going to test it out to see if it really works. Still not a perfect solution since you still have the failure mode of when the LiPo fails you could still corrupt your file system. See below:

------ From: SUPPORT OLIMEX Ltd [mailto:support@olimex.com]
Subject: Re: OLinuXino - Safe Shutdown?

Hi
yes, this is the battery which could be used, but the software should take
care for power down when the main supply is cut
Tsvetan

------ From: Me
Subject: RE: OLinuXino - Safe Shutdown?

So this LiPo battery offered from your site:

https://www.olimex.com/Products/Power/BATTERY-LIPO1400mAh/

will allow for automatic safe shutdown in the event that main power is
lost? Is it automatic in the code or is it something that has to be
configured?

------ From: SUPPORT OLIMEX Ltd [mailto:support@olimex.com]
Subject: Re: OLinuXino - Safe Shutdown?

Hi
Linux operating system *always* require proper shutdown, you do not cut your
power supply on your desktop Linux or Windows machine OLinuXino,
RaspberryPI etc have same operating system and require same precautions when
shutdown.
A13-OLinuXino have build in Power Managment Unit, you can connect
LiPo-battery and the board will have UPS so if the power supply is cut by
accedent the data will not be lost or the SD card corrupted.
Thanks
Tsvetan

------ From: Me
Subject: Re: OLinuXino - Safe Shutdown?

As you already know, the Raspberry Pi requires manual shutdown of the OS in
order to prevent possible corruption of a non-read-only file system, which
is stored on the SD card. Since your boards also boot and run the OS and FS
from an SD card, if and how do you prevent the possibility of a corrupt SD
card FS? Recommendations include a supervisory type circuit which will
detect loss of power and cause and interrupt which will issue the proper OS
shutdown command, or making the multiple partitions on the SD card, and make
the critical OS files Read only, and leave the HOME directory per se as
writable, meaning you could possibly corrupt user files but the OS will boot
and possibly be able to recover. Can you let me know how and if this is done
for the
OLinuXino<http://cp.mcafee.com/d/k-Kr6h8i4x8SyOejphhovsdTdLCzBNMQsCzCXNJYQsKe6zAQsCzB4Sesupd7bXWpIKyrdCTjhOXoxp5_HY-qenT4QNTnKnjjjsVVxZB6X7bnjIyCHtNzBgY-F6lK1FJ4SCrLOrb0VVdOXMUTsS02gAhAlYJO-bhGwTqpuDX6Nffwi5MOsWXZDzhOOCqfzt6RBGNC2GDOlYfVsSOYYUr1vF6y0c1mk6M6B2FEwbCy0oRTPh0c4SVElcg96XCOsuTE5KAaEt-
line of open SW/HW SBCs? This is a great product and I commend you on your
hard work and time to release these SBC designs to the public!