1

I would like to find out how many write cycles I can get from my SD card.

I have googled and found good answers like this but its too complicated for a normal person like me.

Say its a 64GB exfat formatted card.

Isn't it possible to just write a large 59GB random file to it. Delete it. Make a count. And repeat the whole cycle, until the card fails (I am assuming something will finally prevent a write operation).

  1. I guess a 59GB random file can be created like this:

    dd if=/dev/urandom of=/dev/sdd1/file.txt bs=61865984 count=1024
    
  2. Delete the file:

    rm /dev/sdd1/file.txt
    
  3. I am not sure how to do the count operation or do the loop or whether putting it in a .sh file has other syntax/restrictions. Could you please help me with this?

Is my above idea ok (acceptable). I am not trying to be perfect.

Also is there some ready software/script that does this?

(I understand for this I will need to leave the PC on for several months, but I am ok with that. Or maybe when I run the script after a reboot, it will only add to the previous count.)

Thank You. :-).

PS: Why I am doing this - I find that there are huge capacity microsd cards available from oem/no name brands which are quite cheap compared to good brand cards. People say that these cards are unreliable. I just wanted to see how bad they actually were. Practically what I thought was - In 5 years I might write a total of 1TB to a card. That is just 17 cycles! Which I guess even the worst card might be able to do. :-)............

  • No need for a file system. You could just put of=/dev/sdd in your dd command. Still, the result you get needn't be reproducible with another card of this making. – Bananguin Nov 14 '15 at 21:27
  • better use /dev/zero than random, it is far worse for the SSD card. I killed a MicroSD card doing a lot of dd commands to test several Linuxes for ARM, and a few tries cross-compiling NetBSD 7...it is not difficult. Nevertheless dd is not representative of the typical usage of writing a file here and there. – Rui F Ribeiro Nov 14 '15 at 21:37
0

I think your idea can work.

You can write the data directly to the drive's device node (eg /dev/sdd). The rm command is not possible or necessary (it doesn't really remove much data anyway, rm only updates the metadata in the file system. You might consider writing all ones on one cycle, followed by all zeroes on the next cycle.

The trick is to make a persistent counter that you can pick up after reboots. This can be easily accomplished with a file, in the example the COUNT_FILE is "$HOME/.counter". The count may be lower than actual because the system could have been rebooted or etc before the dd completes.

You could also call something like this in /etc/rc.local to start it automatically when the system boots.

#!/bin/ss

COUNT_FILE="$HOME/.counter"

read COUNT < "$COUNT_FILE"

if echo "$COUNT" | grep '[^0-9]' > /dev/null
then
    echo >&2 "$0: ERROR: non-integer counter found in $COUNT_FILE."
    exit 1
fi

while true
do
    echo dd if=/dev/urandom of=/dev/sdd bs=61865984
    COUNT=$(( COUNT + 1 ))
    echo $(( COUNT )) > "$COUNT_FILE"
done

You might also investigate the badblocks command which writes patterns to the disk and reads them back. The good thing about using badblocks is that it writes, reads and compares every byte on every cycle, so you should start seeing more and more badblock numbers as the disk begins to fail.

Also, if you accidently get a different USB drive connected as /dev/sdd, then you'll completely destroy it when this script runs.

  • Thank you so much. This is exactly what I wanted. And I hadn't thought about the possibility of accidentally erasing another usb drive. Thank You for thinking ahead and warning me. :-)....................... – music Nov 27 '15 at 13:21
2

By the time you've got an answer, that particular SD card is dead. This may give you some indication of the longevity of other cards with the same brand and model (or it may not...individual cards vary and, worse, the underlying hardware may change without the model number being changed - manufacturers do evil things like that all the time).

My suggestion is to not care. Buy a spare SD card, and make sure you take regular backups of any important data on the card.

  • Thank you for answering. Yes, you are right, having a backup and also that a test may not be perfect due to things that I don't know. But you also missed the point, I am just trying to get a general idea and I am also ready to sacrifice a card because its so cheap. I was just worried that the card may be so bad that it may fail after just some 10 complete writes or something. And mainly the coding part is what was confusing me. – music Nov 27 '15 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.