Pis are great. But when the power drops.the filesystem on the SDcard is corrupt. Then the Pi is dead with no hope of doing anything unless you brought a spare SDcard or something to mount/fsck/correct it with.
If I was going into space I'd take a Droid or an iPhone. That way I can play Angry Birds In Space in space.
This has nothing to do with a RPi. It is a common file system problem. RPi has 2 file systems. 1. Fat32 for the bootloader, proprietary firmware and kernel
2. Linux rootfs that can use many different kinds of file systems.
ext2 wasn't very good at handling unclean shutdowns. ext3/4 are a little better. fat32 is terrible.
Fortunately the fat32 partition doesn't need to be written very often, so you're good. Reads aren't dangerous.
No, I'm afraid not. (And these are name-brand Class-10 cards).
When the corruption hits the Pi won't boot at all. No grub no kernel no initrd no monitor sync. A fresh card fixes things. Restoring the image to the old card fixes it too.
We have near 100 of these in the field and while I've bench-powerfailed them to no avail, out in the real world they die due to fs corruption.
We have near 100 of these in the field and while I've bench-powerfailed them to no avail, out in the real world they die due to fs corruption.
Hang on, let's get that straight : if you pull the power when they're on the bench, then they don't fail, but if they suffer a power fail in the field they do suffer corruption and freeze/ hang/ fail to boot?
Obviously you've tried this, but are you sure that you're pulling the power on the bench while they're in mid-write? Because if you're doing ostensibly the same thing in two circumstances, but with different results, then I'd have to wonder if you're actually doing THE SAME THING both on the bench and in the field.
The way you've described it, it shouldn't do that.
Are the field and lab conditions - e.g. temperature - also the same. I could see temperature having a significant effect on write speeds on (flash) memory. It sounds perplexing. And quite worrying if your troubleshooting isn't replicating something that seems so simple. I know that troubleshooting can be a real time-sink, but if you're getting lots of these fails then the time to service the fialed field modules must add up too.
Are the Pis also under the same load conditions - data-logging, streaming, whatever - on the bench as in the field?
Hope he doesn't lose power (Score:3)
Pis are great.
But when the power drops.the filesystem on the SDcard is corrupt.
Then the Pi is dead with no hope of doing anything unless you brought a spare SDcard or something to mount/fsck/correct it with.
If I was going into space I'd take a Droid or an iPhone. That way I can play
Angry Birds In Space in space.
E
Re: (Score:2)
This has nothing to do with a RPi. It is a common file system problem.
RPi has 2 file systems.
1. Fat32 for the bootloader, proprietary firmware and kernel
2. Linux rootfs that can use many different kinds of file systems.
ext2 wasn't very good at handling unclean shutdowns.
ext3/4 are a little better.
fat32 is terrible.
Fortunately the fat32 partition doesn't need to be written very often, so you're good. Reads aren't dangerous.
What you really want to do is make sure yo
Re: (Score:2)
No, I'm afraid not. (And these are name-brand Class-10 cards).
When the corruption hits the Pi won't boot at all. No grub no kernel no initrd no monitor sync.
A fresh card fixes things. Restoring the image to the old card fixes it too.
We have near 100 of these in the field and while I've bench-powerfailed them to no avail,
out in the real world they die due to fs corruption.
E
Re:Hope he doesn't lose power (Score:2)
Hang on, let's get that straight : if you pull the power when they're on the bench, then they don't fail, but if they suffer a power fail in the field they do suffer corruption and freeze/ hang/ fail to boot?
Obviously you've tried this, but are you sure that you're pulling the power on the bench while they're in mid-write? Because if you're doing ostensibly the same thing in two circumstances, but with different results, then I'd have to wonder if you're actually doing THE SAME THING both on the bench and in the field.
The way you've described it, it shouldn't do that.
Are the field and lab conditions - e.g. temperature - also the same. I could see temperature having a significant effect on write speeds on (flash) memory. It sounds perplexing. And quite worrying if your troubleshooting isn't replicating something that seems so simple. I know that troubleshooting can be a real time-sink, but if you're getting lots of these fails then the time to service the fialed field modules must add up too.
Are the Pis also under the same load conditions - data-logging, streaming, whatever - on the bench as in the field?