Print

[apemberton]

I am running 4 Rpi's but I have had cases of the 8GB SDHC cards being corrupted though this does not become apparent until the Rpi's are rebooted. This has happened on both original 256MB and newer 512MB units and both Integral CL10 SLC and Kingston CL 4 cards. I don't know why this happens yet and I do not believe it is flash wear as it isn't the swap section giving probs but the Linux partition. I have the feeling that the use of an EXT4 partition might be a contributory cause as I read ext4 is a bit buggy but I cannot be sure. But ext4 is the Rpi default. I think I will make a SDHC Rpi card with an ext3 partition.

My Rpi's are not toys. I NEED reliability! Parts of the home automation system will rely on them.

Anyone else had SDHC reliabilty problems and any thoughts on causes.

[Confusticated]

the use of an EXT4 partition might be a contributory cause

Ensure you disable journalling, it is not recommended to use a journalling filesystem on flash.
The location of the journal is fixed at time of format, and multiple writes per second can easily occur (that is after all, the whole point of using a journal).
How well the SDHC card copes with wear levelling under these conditions is only known by the manufacturer as we are not privy to the algorithms used (in the SDHC).

I NEED reliability!

Use an UPS and always shut the Pi down properly before turning off the power.
Use flashybrid (I always do as most of my systems are experimental and very dynamic), or some other rootfs in RAM mechanism. If your rootfs is less than 16MB compressed (easily achievable using uCLibc and busybox, not so easy with bloatware distributions), compile it into the kernel as an Initramfs and you will not even need to mount the SDHC. Spend a week browsing https://openwrt.org/ for tips how to make embedded systems that last.

[apemberton]

I AM using a UPS where appropriate - the whole house cannot be UPS and thus if the leccie company gives out (which it does probably twice a year due - usually - to electrical storms) then the boiler cannot function. All the core networking kit is protected so I'm not dead in the water. However, the Rpi's software seems to be flaky. I suspect that it is a bit of 'work in progress' and is fine for experimentation. I use the Raspbian repository and the only third party item is Webmin.

I have noticed that the system clock (there is no RTC in a Rpi) can get adrift from the actual time which might well be causing journalling errors.

I will look at the openwrt site soon - isn't that a Linux designed for Linksys Routers?

I wish I knew of a simple way to periodically and dynamically check mounted 'drives'.

[Confusticated]

the whole house cannot be UPS

In the past I have successfully implemented the following for a number of different low power systems (probably will for the Pi too when I need one up 24/7)
Mains Automatic charger (one that switches between charge & float itself) -> Battery -> Voltage Regulator -> target system.
For a Pi I am thinking a 7.2V NiCad (something around 2000mAh, very common for radio controlled vehicles) and a 7805 voltage regulator.

'work in progress'

The kernel file systems are the same as those for the mainline vanilla kernel.

the system clock (there is no RTC in a Rpi) can get adrift from the actual time

Highly unlikely to be related to journalling errors, install ntpdate to get your time over the network

a Linux designed for Linksys Routers?

Aimed at embedded systems (of which some are made by Linksys).
It was very remiss of me not to also mention http://www.dd-wrt.com
Seems since going commercial, this site is now not much use to us.

simple way to periodically and dynamically check mounted 'drives'

You can provided you are not attempting to write to them at the time you perform the check...

to check the root filesystem (a bad idea on a running system)

Code: [Select]

mount -o remount,ro /
fsck -y -C /
mount -o remount,rw /

For example, if you have to check the root file system, you could write a script to be run from cron.
Switch to single user mode (terminating all running processes except the script), perform the check, and then switch to multi-user mode (starting all the daemons) on completion.

Alternatively, and far safer for the less-experienced, mark the file system as due a check (e.g tune2fs) and simply reboot.
NB I have not tried this on a Pi running Raspbian, I am assuming that they have not knobbled the standard start-up script that performs the file system check.