Changes to SD card undone after re-mount (e.g. deleted files re-appear)

Question

After having a corrupted file system on my SD card due (probably due to unsufficient power supply) I want to make a new filesystem. (e2fsck fails, log below.)

However, any file-related changes on the SD card are magically undone!

• First example: when I mount the SD card, delete some files, the files disappear. When I unmount it and mount it again, the files are there again! Similarly when I modify a file's content, the original content is back after re-mount.
• Second example: when I create a new partition table with fdisk, the old partition table is back in place immediately. (Log below.)
• Third example: while I run dd if=/dev/zero of=/dev/mmcblk0 bs=1M, fdisk reasonably said Disk /dev/mmcblk0 doesn't contain a valid partition table. When dd was done, the old partition table was back again.

I have not locked the SD card physically with the small switch. I don't get any read-only errors. In fact, I don't get any errors at all! dmesg doesn't report anything except that I'm mounting a file system with errors.

The problem also occurred running a Xubuntu live cd (12.10). Unfortunately I don't have access to other computers and/or SD card readers at the moment.

Is that a problem of my computer, my SD card, or am I missing something all the time? Any suggestions what I could try?

---

e2fsck fails:

$ sudo e2fsck /dev/mmcblk0p2 
e2fsck 1.42.5 (29-Jul-2012)
/dev/mmcblk0p2: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? yes
e2fsck: unable to set superblock flags on /dev/mmcblk0p2


/dev/mmcblk0p2: ********** WARNING: Filesystem still has errors **********

---

Here's the log that shows that fdisk has no effect:

$ sudo fdisk /dev/mmcblk0

Command (m for help): p

Disk /dev/mmcblk0: 31.5 GB, 31460425728 bytes
4 heads, 16 sectors/track, 960096 cylinders, total 61446144 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00017b69

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880    61446143    30661632   83  Linux

Command (m for help): d
Partition number (1-4): 1

Command (m for help): d
Selected partition 2

Command (m for help): p

Disk /dev/mmcblk0: 31.5 GB, 31460425728 bytes
4 heads, 16 sectors/track, 960096 cylinders, total 61446144 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00017b69

        Device Boot      Start         End      Blocks   Id  System

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.



$ sudo fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 31.5 GB, 31460425728 bytes
4 heads, 16 sectors/track, 960096 cylinders, total 61446144 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00017b69

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880    61446143    30661632   83  Linux

Solution 1

At this point I would suggest running badblocks on the SD card to see what it finds.

It sounds like the card's write logic is damaged, what you see on a mount point is simply the cached version of your data. It's supposed to be written back via sync and during umount. Seeing that you don't mention that the SD card is hanging at all suggests the damage is severe enough to create false positive write back responses or in simpler terms your disk is lying to you when it says a write is complete.

You could try toggling the write protect switch while the card is removed from the system. e.g.

1. toggle write protect
2. insert
3. do something trivial
4. unmount/eject
5. reverse write protect
6. rinse/repeat

In an effort to tickle the circuitry which might be caching a "stuck at 1" value. Other than that, crush it so no one else suffers any more grief and toss it.

Solution 2

Your card seems to be locked via the MMC write protection flag. If you have a Linux computer with an SD/MMC card reader, try running

sudo sdtool /dev/mmcblk0 unlock

Note that you need an MCC device (not a USB mass storage device like /dev/sdX) for this to work.

sdtool can be found here. There is a Raspberry Pi build, otherwise you'll have to build from sources. It seems that a similar action can be performed with hdparm, but I haven't tried that personally.

Note that defective cards lock themselves internally in a similar way to prevent further data damage, and will ignore unlock commands.

Comments

[Palantir]

Got hit with the same exact problem today. It's the second SD card in two months that gets fried this way by my phone. Changes on the filesystem are apparently done, but never persisted. Switching on and off the read-only switch unfortunately has no effect. So probably the phone is capable of somehow damaging SDs.

[ppetraki]

@Palantir, solid state storage can be a pita sometimes. It could be that you just got a bad batch of silicon. Or your phone OS isn't managing the media well and it exhausted the write capacity (write endurance) of the media. Heavy media (downloads) use + poor ssd management could easily burn up your card.

[Palantir]

Heavy use + poor management may be very well the case. I was using that SD card to handle apps, not media (i.e. Link2SD), so heavy use was granted. Also, absolutely poor management too, because the problem happened after a phone crash... :-@

[Palantir]

Thanks a lot for your comments... I will try to invest in a new phone, instead of buying yet another SD ;-)

[schlimmchen]

Very, very interesting! When locking a card this way, it does indeed not spill an error when trying to write to it and the write action is not carried out (tested with a known good SD card). Unfortunately, this does not help with my (obviously) defective card.

[Dmitry Grigoryev]

@schlimmchen The card is not to blame. Mass storage drivers are optimized for speed, so they tend to do a lot of caching and forego checking SD/MMC status flags, not to mention verify the data that has been written.