File System and Corruption

Hi,
i have more raspberry that are switched off electrically without halt or
reboot. I can not do anything to resolve this situation, so i can only
adapt. I use raspian and I have already had many failures.
so:
- forcing with tune2fs to recheck /dev/root every reboot improve the
problem mitigation?
- why raspian don't use a journaled FS? Journaled FS is better in this case?
Any ideas are welcome! Thanks in advance.
Reply to
writethem
Loading thread data ...
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.
Reply to
Rob
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:
formatting link
Reply to
Dave Farrance
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..
Reply to
writethem
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.
Reply to
Dave Farrance
Il 06/08/2014 10.34, Dave Farrance ha scritto:
good, i deepen now this picore...
Reply to
writethem
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.
--
Graham. 

%Profound_observation%
 Click to see the full signature
Reply to
Graham.
I think the way to go is simply a backup battery:
formatting link

I use one on my CH controller
Reply to
tony van der Hoff
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?
Reply to
writethem
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 ?
Reply to
hamilton
here:
formatting link

Reply to
tony van der Hoff
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.
Reply to
tony van der Hoff
good hint!
Reply to
writethem
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
--
Change nospam to gmx in e-mail.
Reply to
Another Dave
LIPOs good for several years albeit at reduced capacity
--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher
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.
--
Graham. 

%Profound_observation%
 Click to see the full signature
Reply to
Graham.
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 *Configure Filesystem SCSIFS command.
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
Reply to
Theo Markettos
It does. noatime also. the problem is FTL
this may be of interest:
formatting link
--
umop apisdn
Reply to
Jasen Betts
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.
--
umop apisdn
Reply to
Jasen Betts
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.
Reply to
Baho Utot

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.