Help! sdcard lost due to dead battery!


___

Advanced Member
Joined
Jan 31, 2006
Messages
3,376
Hey friends! Yesterday I was hacking away at a script on my pandora but forgot to connect the power supply. The pandora died on me while I was working. I booted with power supply connected and continued working. when I was ready to package my script as a pnd, I noticed my scripts had reset to an earlier state. I tried to run fsck on the card in my laptop and got the following message:


"Unable to set superblock flags"


so I looked up the backup superblocks and tried again with two different backup points. The scard seems to be severely damaged. nothing changed after remounting, it's a 128gb class 10 card by platinum formatted to ext4 btw.


I was able to get all my data off the card. Then I tried reformatting with gparted but it won't even delete the partition, always throwing me the same errors.


Does anyone have an idea what I should try next? I guess it's physical damage.


Anyone able to recommend a decent brand 128gb sdxc which won't make me poor? I am in europe, germany.


thanks!
 
I would try to delete all Partition Data on this Card with testdisk

and then try to repartitionate it via gparted.

Delete all Partition Data and write a new MBR.

Testdisk rescued many Things here in the Past ;)
 
Last edited by a moderator:
I was able to get all my data off the card. Then I tried reformatting with gparted but it won't even delete the partition, always throwing me the same errors.


Does anyone have an idea what I should try next? I guess it's physical damage.


Anyone able to recommend a decent brand 128gb sdxc which won't make me poor? I am in europe, germany.


thanks!
I don't think that your card is physically damaged.

You can try to fill it with zeroes using dd (be careful), the format it again.

Watch dmesg for eventual IO errors.

Use sandisk extreme/extreme pro.

http://pandorawiki.org/SD_compatibility_list
As one of the authors of this pandorawiki's entry for SanDisk 128 GB extreme cards I can only renew this recommendation. Entry is from late 2013 so my cards are just over one year old, are used continuously in my Pandora and never had any issues.

From my own experiences I'd like to say that sandisk is the manufacturer to choose. No card from them (owning two hands full, some from last millenium (CF-card)) ever failed me. And they are the producer of most other brands' SD-cards, too but seem to reserve the best chips for their own high end brands (extreme, extreme pro).

Just compared the prices:

Platinum 128 GB (up to 45MB/s read speed) = 62 Euro (amazon.de)

Sandisk extreme (up to 60MB/s read speed) = 102 Euro (reichelt.de)

For me it's worth the difference. (Read speed is negligible as the Pandora can only read about 30MB/s at most)
 
Thanks for all the tips! I can't get the data off of the sdcard which is why I think it's damaged.

I tried deleting the partition with gparted, won't work.

Tried deleting the data with testdisk, deletion confirmed, nothing on the sdcard seems to change though.

So I tried writing random crap to it with dd, it ran the whole night... rebooted, all the data is still there.

I will try the sandisk card you guys recommended. I have a few cards by sandisk myself.
 
Sandisk models lower than extreme are crap.
I won't go that far. You get what you pay for. Ultra cards are reasonable cheaper than newer extreme (pro) but the read speed is at par with older extreme cards. Only that read speed isn't the most important value when using the card in your Pandora...
 
I managed to nuke a 64GB Sandisk extreme card when I forgot the SD card reader in my netbook doesn't like writing the partition table on anything in the SD slot. Now, when I plug it in to anything, it just doesn't recognise that there's anything in the slot, so I've been unable to flash a new MBR and partition table or anything like that.
 
Sandisk models lower than extreme are crap.
I won't go that far. You get what you pay for. Ultra cards are reasonable cheaper than newer extreme (pro) but the read speed is at par with older extreme cards. Only that read speed isn't the most important value when using the card in your Pandora...
Ext* filesystems seems to be badly supported on those.
 
Ext* filesystems seems to be badly supported on those.
How can a card support some filesystems better than others?

On the topic, try booting the pandora with the SD card out, the insert it and unmount it if it still gets mounted. Then use fdisk or gparted to remove all partitions, apply changes and reboot.
 
Last edited by a moderator:
Ext* filesystems seems to be badly supported on those.
How can a card support some filesystems better than others?

On the topic, try booting the pandora with the SD card out, the insert it and unmount it if it still gets mounted. Then use fdisk or gparted to remove all partitions, apply changes and reboot.
I'd like to know that as well, because I will need to use ext3/4 formatted cards. All my computers run linux, so I won't be messing with any fat32 crappery... file permissions and general compatibility.

Also: I did try to remove partitions, with testdisk and gparted repeatedly on a laptop. Rebooted, took card out and put back in etc. Filesystem appears unchanged and like it was burnt in.


Running badblocks -svw for about 5hrs showed countless errors, but only on a specific pattern being written. I forgot which one though... would've to look it up. think it was on the 3rd run through.
 
Last edited by a moderator:
There's a theory that the flash controllers on these cards are optimised in terms of caching and wear level balancing and so on on the FAT filesystem specifics. Most of my SD cards are ext2/3 formatted though, and I've had no problems (except for the one card I knackered above, but that was a problem partitioning, not formatting).
 
Last edited by a moderator:
There's a theory that the flash controllers on these cards are optimised in terms of caching and wear level balancing and so on on the FAT filesystem specifics. Most of my SD cards are ext2/3 formatted though, and I've had no problems (except for the one card I knackered above, but that was a problem partitioning, not formatting).
And what those specifics would be exactly? Both FAT32 and EXT2/3/4 have variable cluster size, and 1 cluster is the minimal unit of data transfer. Still even the largest cluster sizes (tens of KBs) are far smaller than erase block sizes (MBs), so unless the OS disk cache is able to order write operations to sequential clusters, I dont see what logic could be implemented in the SD controller.
 
Good question. It's a theory, albeit not one of mine originally. I'm afraid I don't know anything much about the internals of disc formats yet, and like I said, I've always ignored that advice anyway.


That said, I once has a WD disc drive that had to have a bit set on every boot if you wanted to read the partition table if formatted to anything other than single FAT16 partition. I ended up booting off floppy which did the magic, then booted off the hard disc. That's the only trouble I've ever had not using FAT format though.
 
There's a theory that the flash controllers on these cards are optimised in terms of caching and wear level balancing and so on on the FAT filesystem specifics. Most of my SD cards are ext2/3 formatted though, and I've had no problems (except for the one card I knackered above, but that was a problem partitioning, not formatting).
And what those specifics would be exactly? Both FAT32 and EXT2/3/4 have variable cluster size, and 1 cluster is the minimal unit of data transfer. Still even the largest cluster sizes (tens of KBs) are far smaller than erase block sizes (MBs), so unless the OS disk cache is able to order write operations to sequential clusters, I dont see what logic could be implemented in the SD controller.
I'm not sure of the logic as to why.  However, my 128GB Lexar card showed a preference for EXT2 over EXT4.

Same card - same OS & system (Pandora).  Vulture's Eye was my canary in the coal mine.

Under EXT4, Vulture's Eye would take 10+ seconds to start.

Under EXT2, Vulture's Eye would start seemingly instantly.

I also noticed that EXT2 was snappier for general uses that hit the card too - though that wasn't something I could measure as readily.
 
I'm not sure of the logic as to why.  However, my 128GB Lexar card showed a preference for EXT2 over EXT4.

Same card - same OS & system (Pandora).  Vulture's Eye was my canary in the coal mine.

Under EXT4, Vulture's Eye would take 10+ seconds to start.

Under EXT2, Vulture's Eye would start seemingly instantly.

I also noticed that EXT2 was snappier for general uses that hit the card too - though that wasn't something I could measure as readily.
Did you disable journaling on EXT4 when you compared it to EXT2? Anything with journal would be slower, no matter what media you use.
 
Last edited by a moderator:
Also: I did try to remove partitions, with testdisk and gparted repeatedly on a laptop. Rebooted, took card out and put back in etc. Filesystem appears unchanged and like it was burnt in.


Running badblocks -svw for about 5hrs showed countless errors, but only on a specific pattern being written. I forgot which one though... would've to look it up. think it was on the 3rd run through.
Do all your tools really write something on the SD, or do they only say they do? If you close say testdisk and open it right again, does it still see the changes you've just made? That is the reason I preder fdisk, it is verbose about MBR being cached by the kernel and thus impossible to overwrite.

And what about badblocks? Did the output suggest there are badblocks on your card? I mean, an SD with badblocks is only good for preventing dust going into the slot, and you don't really have to format it for such use.
 
And what those specifics would be exactly? Both FAT32 and EXT2/3/4 have variable cluster size, and 1 cluster is the minimal unit of data transfer. Still even the largest cluster sizes (tens of KBs) are far smaller than erase block sizes (MBs), so unless the OS disk cache is able to order write operations to sequential clusters, I dont see what logic could be implemented in the SD controller.
Their way of file allocation and indexing works entirely different, though. The simple structure of FAT based filesystem surely offers some potential to make educated guesstimations on how things are being written. For example, the FTL could directly analyze the FAT itself - imagine a really crappy FTL that expects the FAT at a fixed position and only finds garbage because the drive was formatted with ext3.
 
Back
Top