SDCard failures

[pleriche]

I have a couple of SDCards that have failed. One was a cheapo from eBay, of unknown provenance and had seen (probably) several hundred hours of service doing timelapse photography (a few exposures per hour), but the other was almost new, from Maplin (Class 10 8GB - unfortunately I don't think I still have the receipt).

The cheapo one won't boot at all, and Win32DiskImager gives an error if you try and reimage it.

The Maplin one works fine until half way through an apt-get upgrade, when it starts giving errors, e.g.

Code: Select all

[ 1178.620036] EXT4-fs (mmcblk0p2): delayed block allocation failed for inode 70
92 at logical offset 121 with max blocks 2 with error -30
[ 1178.633401] EXT4-fs (mmcblk0p2): This should not happen!! Data will be lost
[ 1178.640860] EXT4-fs error (device mmcblk0p2) in ext4_da_writepages:2576: Jour
nal has aborted

... and it gets worse!

Am I just unlucky? How long would you expect an SDCard to last?

Regards - Philip

[gkreidl]

Do you run a rather new Raspbian version or some old image from two years ago? There have been quite a few updates regarding SD card access.

[pleriche]

I'm using Raspbian 2014-01-07. I see there's a later version out in June that I might try.

[cpc464]

That is a bit unlucky. Do you have access to a Linux PC ? If so, put the SD card into the PC and try an "fsck" command.

SD card corruption can sometimes occur if you power of a Pi without cleanly shutting it down first.

[pleriche]

Seems to be hardware, not file system structure. (You don't need another Linux system - you can just plug the dodgey card into a Pi USB socket in a USB card reader in order to run fsck. Done that.)

I even tried Spinrite on level 2 - multiple reports suggest that it can revive an SSD, but no luck.

[cpc464]

What did the fsck say ?

I had one SD card in a Pi that fsck could not repair, I had to re-image it in the end.

[pleriche]

As I said, it's a hardware error with the SDCard, as it even gives errors trying to reimage it with Win32DiskImager. One card gave innumerable errors from fsck, another reported clean.

I was hoping for any other good/bad experiences with different brands of card. I got an 8G Maplin Class 10 thinking that being over twice as big as I need it'd have plenty of spare blocks to call on once it started getting worn out. Perhaps a major brand such as Kingston or Samsung would be better.

[RaTTuS]

it may be worth while to search out a video [and blog] titled "the exploration and exploitation of an sd memory card"
it's quite interesting on various levels

[cpc464]

SD cards should not do this. I have an 8 Gb class 10 in a Sheevaplug that has been working for years under constant read/write 24x7. Think it is a Kingston but others have been similarly reliable, eg Transcend.

The Pi I have found a bit less robust, it seems to corrupt SD file systems fairly often, but always in a way that could be fsck'd or re-imaged. I have always used "dd" on Linux, never Windows tools. I have never had an SD card permanently fail in hardware on any device.

[pleriche]

Yes, I did see that 30c3 presentation when it was first published, but worth viewing again. The serious issues raised account at least in part for my questioning of Maplin SDCards.

[AndrewS]

Perhaps a major brand such as Kingston or Samsung would be better.

IIRC these are Samsung http://swag.raspberrypi.org/collections ... gb-sd-card and no doubt much cheaper than Maplin!

[gsh]

It's possible you've got a cheap copy SD card which actually say's it 8GB but actually is only 4GB... There are lots of chinese knock off cards out there that do that.

I've not seen any confirmed cases of corruption (which were not due to just powering off the Pi whilst running or occurred because of a poor power supply) in about six months...

Also change /etc/defaults/rcS to have FSCHKFIX=yes this will then automatically clean the filesystem if it is found to have corruption...

Gordon

[AndrewS]

There's apparently a program called H2testw which can be used to check for fake SD cards.

[pleriche]

I've just re-watched the 30c3 presentation, and it makes your blood run cold! They sell every piece of silicon that comes out of the fab, and if a 16G chip only has 4G of good memory cells, they'll sell it as a 4G SDCard. And if it only has 128M of good cells, they'll sell it as that! And that's what we entrust our data to!

Thanks Andrew - I tried H2Testw (lots of nice stuff on the Heise site - shame I don't speak German!) and both cards tested OK! But it said the Maplin one had a MB less memory than its reported size. (Spinrite had also noticed that.) So expanding the root fs to the maximum size using raspi-config will result in some unusable blocks at the end, if these are ever allocated. I don't know whether Ext4 will will allocate these last - quite possibly not. Previously, using the Jan Raspbian image, it always clagged with what appeared to be hardware errors on the apt-get upgrade, but with the June image, the upgrade is much less extensive and runs to completion. But how long this card is good for is anyone's guess.

The cheap eBay card (actually marked Sandisk, but who knows?) will take a Raspbian image but won't boot.

Thanks, Gordon - setting FSCKFIX=yes should probably be standard practice - I thought a journalled file system was supposed to be quite robust, but corruption seems to be fairly common from improper shutdown, whether through prematurely pulling the plug, or power glitches through USB events, or other system crashes.

Regards - Philip

[pluggy]

it may be worth while to search out a video [and blog] titled "the exploration and exploitation of an sd memory card"
it's quite interesting on various levels

Very Interesting. The "illusion of reliability" makes me wonder if I should ever entrust ANYTHING to flash memory ever again.....

The description of Chinese knockoff SD card factorys with chickens running round the floor was 'enlightening'.

[gsh]

I can guarantee you a way of creating a corrupted FSCK and it's nothing to do with Raspberry Pi per se...

Install mysql and have it running...

Power off your system

Guaranteed FSCK!

I believe the problem here is that there are two threads communicating through a temporary file such that it is created and opened by both sides and then deleted by one of the sides... So the file is marked on the filesystem as being deleted but it can't be actually deleted because the other side still has the file open and is reading / writing it...

When you power off the system it doesn't tidy up and delete the file as it should if you shutdown correctly. So when it boots up fsck finds a file still existing that has been marked as deleted. The fix is of course completely simple and doesn't cause a bug but the booting may fail because an fsck is required...

So yes FSCKFIX=yes is going to be added to the Raspbian filesystem

Gordon

[Shoka]

Thanks for the heads up, added that to my pi config.

Harry