Making an image of an SD Card - Is this possible?


because its the first time I hear of this, and I find this very hard to believe. if that was true SSDs would also freak out if you wrote a 4GB+ file as this would also be a long continuous write spanning multiple erase blocks.
No, you didn't get my point. The problem isn't how it is being written, the problem is that you are writing the whole media, i.e. almost all blocks exposed by the FTL. It simply breaks the wear leveling resulting in data loss because the FTL has not enough free room to react correctly.

I'm gonna have to see some external information sources backing what you're saying because those would be the symptoms of a very broken FTL firmware.


with any semi-decent firmware, overwriting the whole media should unfragment a good portion of the FTL remapping, of course this would count as a full erase-write cycle for each erase block, but only once per erase block.


especially if you wipe the whole card first by sending it a TRIM command covering the whole device to be sure wont shuffle old data around.


there's the new BLKDISCARD ioctl command that can be used for this


random IO is what the FTL firmware has to work hard to wear level properly, not huge sequential block writes.


of course, if you're backing and restoring only 64MB of data on a 8GB card, that's a huge waste of time, better to just copy the files.


if you got 7GB of stuff on a 8GB card you want to backup and restore later then you might as well backup/restore the whole image, at least the file directory structure will be only written once, even if you overwrite 1/8th of the card for "no good reason", the file management wont be overwritten multiple times over as the OS is marking free blocks as allocated and updating the directory information.


there's a point where it causes less wear to rewrite the whole thing once rather than file-by-file.


if you want to test, fill an SD card to the brim with stuff like a whole bunch of debian packages.


then copy all those files to a backup folder on your HDD


also make a full backup image of the SD card on your HDD


reformat the card


time how long it takes to copy all files back to the card file by file (cp -r backup/* /media/sdcard)


time how long it takes to restore the image (dd bs=16777216 if=sd.img of=/dev/sd... )


since erasing flash blocks is the slowest operation by far, the time will tell you roughly how hard the FTL had to work.
 
I cant argue with the technicalities of why it shouldn't be possible, or is best avoided, as all the arguments put forth earlier made alot of sense as to why its probably a waste of time to bother trying to do this but....


it can be done.


I've just spent a few hours imaging and restoring SD cards and within certain boundaries (I'm still testing, no with zaxxon firmwares) it is certainly possible to shift entire bootable images between cards.


So far I have imaged and swapped :


Release 1 of Droidora from a 16gb class 10 Transcend card.


SLACKWARE 13.37-3 from a 16gb class 6 Adata card


A flashing set up for Pandora firmware from an 8gb Class 10 Transcend card


and am about to test the 8gb, card as a fresh SD Installer created HF7b2 installation, to see if it can be transferred to the 16gb cards and boot successfully.


The only issue so far has been attempts to transfer the larger Droidora/Slackware cards images (small in actual data) to the smaller 8gb card.


This took several reboots on the imaging PC to allow this procedure and whilst the card was recognised by Pandora and allowed for a 'boot from SD:1' option, in the case of Droidora (as SLACKWARE simply takes over the default boot), it sadly failed during the boot process of Droidora, stating "Unable to mount rootfs in unknown block #####"


It seems it maybe possible to at least move images into differing cards, so long as the cards are the same size or larger however.


Although I'm just a very bored, boring guy with no tech know, know how and these days, no techno either :)


Else I'd've kicked in my TV from lack of TV Out and gone and done, something else, less boring, instead!
 
Might as well be the case that the FTLs of SD cards are just simple and hackerish enough that it isn't a problem for them, companies care more about them being cheap than super efficient. SSDs' FTL firmwares are massive after all, containing all sorts of complex wear leveling algorithms that can go crazy under certain conditions.
 
Back
Top