Stress (write) Test an SD card to destruction using a simple shell script

Question

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. :-)............

Answer 1

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.

Answer 2

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.

Persistent counter

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

Badblocks

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.

Warning

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