SD Card Life Cycle

Epitome

Member
Oct 22, 2013
17
0
0
Just something I was not aware of and was just 'exposed' to with the loss of a 256 GB SD card and all data from it. Started with some photo's being fully or partially greyed out. Then I could not access the Gallery more than once as all Gallery and Album content was grey and not accessible unless I did a Restart or Off and On cycle. Then some of the music and audio book files would not play more than a chapter without a Restart.

The 'average' SD card has a read/write life of 100,000 cycles. That seems like a lot, but perhaps it is not.

For instance, I have nearly 7,000 songs in my music library. I add books to the library and listen to as I work out at the gym and then delete the file or chapter that I have just listened to. My camera defaults to store pictures on the SD card. I have several apps that store data on the card. Etc . . . .

Every time I listen to a song or album there are multi read accesses. Every time I add or delete or move a photo into a new Album, there is a read/write. Basically, every time I access anything on the phone that uses the card there are read/writes.

The only thing I do not know about, actually lots I don't know about, is that I do not know is using Smartswitch or some other app for backup is considered a read/write. I suspect it is.

Tips

- Do not defrag a memory card. This consumes write/erase cycles and shortens the MTBF considerably.
- Use FAT32 instead of a journaling file system (like NTFS), which will write more often.
- SD cards are rated to hold data at something like 10 years sitting idle, but a lot of environmental events can shorten the life considerably. Heat is an enemy.
 
Basically, every time I access anything on the phone that uses the card there are read/writes.
Not exactly. Looking at a picture, reading a book (unless the app keeps a bookmark in the book file) are reads, not writes.

- Do not defrag a memory card. This consumes write/erase cycles and shortens the MTBF considerably.
And does nothing. Defragging is used to keep from shuffling the read head of a hard drive all over the platter. It doesn't take any longet to read one block from the beginning of an SD card, then the next block from the end, than it takes to read them all sequentially.

- Use FAT32 instead of a journaling file system (like NTFS), which will write more often.
And it you want portable storage, and you run Windows, you have to run FAT32 up to 32GB and exFAT above that. The other choice would be ext3 or ext4, and Windows can't read that. (Almost no one formats an SD card as NTFS - you'd have to do that in Windows [or possibly at the Linux level - I haven't tried, but if the device recognizes an NTFS volume, it's probably capable of handling an NTFS filesystem, even to the point of formatting it - but you'd be in a terminal app - normal "plug the card in and the phone asks you if you want to format it" formatting results in a FAT32 or exFAT format.).

- SD cards are rated to hold data at something like 10 years sitting idle, but a lot of environmental events can shorten the life considerably. Heat is an enemy.
Heat is the enemy of anything electronic, but if the card gets hot enough to lose data, the phone is getting hot enough to fail catastrophically.

And you missed another not-so-well-known fact. Android apps have to keep their current state at all times. (Some don't, but that's not Android's fault.) That means writing to where they're stored - constantly in some cases (scroll the screen a few times and that might cause 50 writes). So an app that's "moved" to the card could have the "keep track of where we are" code sitting on the card, and it's constantly writing. That can destroy a card pretty quickly - days, even. So don't move apps to an SD card.
 
When you change things, at least. There's no reason to have 20 backups that are all the same. And, unless you're doing incremental backups, only keep the last one. (If you don't know what incremental backups are, just keep the last backup.)
 
First off to the OP and subsequent posters, thanks for sharing the information. As far as defragging and FAT32, I am totally lost. Could someone convert this into layman's terms and bottom line it for those of us that aren't that tech savvy?
 
First off to the OP and subsequent posters, thanks for sharing the information. As far as defragging and FAT32, I am totally lost. Could someone convert this into layman's terms and bottom line it for those of us that aren't that tech savvy?
FAT32 is nothing more than a file system. It tells the operating system how the files are organized and where they are at on the drive. Kind of like the card catalog of a library.

Defragging is used to optimize hard disk drives. As drives get used files become fragmented with pieces getting in put various places on the drive. Defragging gathers up these pieces and puts them back together in one spot on the drive so the read heads don't have to move as much to find the data. This speeds up data access.

With solid state technology, which include SD cards, thumb drives, and solid state drives (SSD), defragging is not needed. Solid state, SD cards, etc., do not have read heads. That means the physical location of the data on the drive is irrelevant because there are no read heads to move around to find the data.

Does that help?