File System and Corruption

Raspbian DOES use a journaled FS, but it is not enough to solve the problem of wear leveling because blocks are affected that were not involved in the most recent updates.

Also the journalling is only for the filesystem metadata and not for the userdata, so any files with internal structure that is invalid for some time during an update (e.g. an indexed file with index elsewhere in the same or another file) will not be consistent when the power drops during an update, even with the journalling on. A recheck of the filesystem does not find those problems, there should be a repair specific for the application that maintains that file.

The "problem" at hand appears to be in that area, as my experience with Raspberry Pi running a plain command mode interface and not much activity on the FS is that it does not matter when the power is cycled unexpectedly.

The only complete solution would be a power-supply holdup circuit with a supercap big enough for the shutdown period, but there probably are ways to mitigate the problem without that. So no easy answer, but there was a post on the Raspberry Pi forums saying that you can offload the filesystem onto a USB stick, turning the SD card into a read-only device, and that USB sticks tend to be better at handling power loss. Seems a bit complex:

infact, on all raspian i use only ssh and i move in tmpfs all most-used file for minimize I/O impact. But this is insufficient and ofet i see error in easy and basic text file..

Just remembered: There's an OS called "picore" that loads into ram, which should avoid the problems of writing to the SD-card. Any data-logging from an application could be routed to a USB stick.

Il 06/08/2014 10.34, Dave Farrance ha scritto:

good, i deepen now this picore...

Some time ago I prepared a minimal boot SD card, and transferred my RASPBX system to an 8 GB USB stick, it worked well, but I came to the conclusion I was deluding myself that it would be any more immune to file corruption that way.

On the basis of your comments I have refreshed the thumb-drive image, (and created a second one as back up), and returned to this dual medium solution.

I suppose a USB SSD would be the way to go.

I think the way to go is simply a backup battery:

I use one on my CH controller

Ok, but this battery don't start automatically. OR charge OR deliver the power. when charge don't deliver the energy.

and the intervention time is more lower to poweroff the raspberry?

How do you connect this battery ?

If the Pi is connected via the Pis uUSB port to the batterys USB A port, what charges the battery ?

here:

It has a uusb in and a usb out. Just connect the battery in series with the pi psu and the pi, and it works as a UPS. Probably a good idea to replace it annually, or at least test it, before the LIPO dies.

good hint!

Raspbmc's installer has the option to install to a USB stick - is this what you did? I think I may try it in view of a statement in the above forum thread that overclocking core_freq corrupts SD cards but not USB sticks.

Raspbmc overclocks core_freq by default...

Another Dave

LIPOs good for several years albeit at reduced capacity

No, I migrated an existing system to the thumb drive. I created an image of the SD card with Win32DiskImager on a Windows laptop and wrote the image onto the thumb drive. Then I edited cmdline.txt on the SD card. This file is in a FAT32 partition so it appears as the root under Windows

originally (boot from SD run applications from SD)

Modified to (boot from SD run applications from USB)

My application, an IP PABX performs exceedingly well without over clocking, so I have never tried.

Likewise RISC OS will do that: you can pull out the SD card completely once it's booted. If it needs anything (which is unlikely in the usual course of events), it'll prompt you to put it back again.

If you need media for logging etc, move all the files to that and use the SD just for booting. In RISC OS it's a simple one-off

In Linux you need to tell it where to find the root FS: just put root=/dev/sda2 into cmdline.txt

and 'dd' the SD card image to your USB stick as well as the SD card.

Theo

It does. noatime also. the problem is FTL

this may be of interest:

If you choose a model that's resistant to power failure, then yes, but the same caveat applies to SD cards. We're using Transcend SD cards (4G and 8G) and aren't seeing power related faliures any more.

loose-card related failures are another matter, but B+ should help that.

That page is BS I have a Verbatium 512MB USB drive. Yes it is that old with ext3 filesystem that I use everyday to transfer files from one box to a laptop.

It has not failed yet.