This is not a complete solution, but a good practice would be to create a separate partition on the uSD for the sole purpose of storing your data, and to use one of the journalling filesystem types on that partition, e.g. ext3 or 4. 

The automated way of repairing the partition would be to create a script initiated by the init system which runs fsck on that parition and responds appropriately given the output of fsck.   This script could cull the last line of your data file as a last step.

This won't fix problems regarding cases where the actual OS filesystem partition gets corrupted, but it should minimize risk. 

There are other practices for going to extreme reliability, but I haven't seen them used much on Yocto/Angstrom type setups.


From: Juan Osuna <>
Sent: Monday, March 18, 2013 12:18 PM
Subject: [Gumstix-users] uSD ReadOnly File System.

I have a sensor monitoring application using the VERDEX XL6P.    Basically,
sensors are sampled every second and the data string is written to the uSD

We have experienced that when the VERDEX suddenly turns off by electricity
blackouts, the uSD memory turns to the read-only state after restarting the
VERDEX and in some cases the memory gets damaged and become unusable.

We have managed to repair the memory by first, unmounting and remounting the
uSD, and second, by removing the last lines of the last file.
For our final application, this is not practical since due to installation
at remote sites, the entire operation should be automatic.

- Has anyone had any similar problem?
- Any recommendations for automatically repairing the memory after a
read-only state?

Thank you in advance for your help.
Best regards!!

View this message in context:
Sent from the Gumstix mailing list archive at

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
gumstix-users mailing list