While on holiday recently, my wife bought a 32GB micro-SD card, which she intended to use in her tablet. Since then, it has been giving various errors, so I thought I should take it and verify its quality.
In order to test the card, we’re going to run three tests:
- Access Speed, to assess the card Speed Class.
- Drive Size, to assess if the reported size matches the actual size.
- Data durability. to assess that data written can be read back reliably.
Before we start…
The tools and techniques we’re going to use will be destructive to any data that is on the SD card. If this is important to you, make a backup of your data to a safe location before starting.
Testing Access Speed
A relatively quick assessment of speed can be made using the ‘gnome-disks’ tool. This sometimes appears as ‘Disks’ under the start menu on most modern Linux distributions. Opening this, you can find the SD card in the drive list, and use the tools to run a benchmark test. We’re interested in the write speed, so ensure you select to do a write test. Once complete, the benchmark tool will show a graph of results similar to the following figure.
SD Card Benchmark Results
We can see that the write speed is averaging 5.8 MB/s. Comparing this to the SD Association Speed Class data, we can conclude that this is only sufficient to claim Speed Class 4. This is quite disappointing for a card that was sold as a Class 10 High Speed card.
We’re going to have to mark this test as a fail.
Testing Drive Size
Again, the gnome-disks tool shows the reported size of the SD card as 34 GB (33,554,432,000 bytes). There is some ambiguity in terms of how disk sizes are reported, given that there are two definitions of what a Gigabyte is. Some consider it as 109 bytes (a decimal gigabyte), while some consider it as 230 bytes (a binary gigabyte). That said, the card was sold as a 32GB card, so if it holds that much (or more), we’re happy.
To test the drive size we’re going to create a 32GB file containing random data. Assuming you have a hard-disk location suitable for a file of this size, one can be created using the command:
dd if=/dev/urandom of=rnd_data bs=1024 count=32768000
‘dd‘ is the disk-duplicator, we’re using it to read from the input file (if) /dev/urandom. This is a pseudo-file to the kernel random number generator, and will return a random string of ones and zeros. We’re going to write this data to the output file (of) called rnd_data. We’re reading block size chunks (bs) of 1024 bytes (1 kilobyte). We’re also going to read ‘count’ blocks. Count was derived by dividing the reported disk size by the block size. As this is a large amount of random data to produce, it took several hours to produce this file, so be patient.
Once this file is created, we can copy it to the SD card to see if it fits. Again we can use the dd command for this, but this time we’ll need administrator rights.
sudo dd if=rnd_data of=/dev/sdc bs=1024 count=32768000
In my case the drive was listed as /dev/sdc, though this might differ in your case. Again the gnome-disks utility can help show where your device is listed. This command will overwrite the disk contents with the random data we previously produced. Back up any data on the card before running this command. Depending on the write speed of your card, this can also take several hours to complete.
In the end the results were a pass. All 32768000 blocks were written, so we can say the card had sufficient capacity to pass this test. Had the card been of a lower capacity, dd will show how many blocks were written. This will give an estimate of actual drive size in kilobytes. Dd also shows the average write speed as 3.8 MB/s, which is not enough to claim Class 4. Again, further proof that this is a mislabelled speed class.
Testing Data Durability
To ensure that the data we wrote can be correctly read back we can copy the SD card contents back to another file. Again we’ll use dd…
sudo dd if=/dev/sdc of=rnd_read bs=1024 count=32768000
Reading is typically quicker than writing, but as we’re moving a large data size it can also take some time to complete. Once the data has been read back, we can compare the data that was written (rnd_data), with the data that was read back (rnd_read) using a hashing algorithm:
md5sum rnd* 729d62450dbf55d0676ddff494a7597d rnd_data c628379249c448eba5502acb9de9d477 rnd_read
The test is a failure as the checksums don’t match. It’s clear that the data read back doesn’t match the data written. If data durability can’t be assured, the card is useless. It’s little wonder the tablet constantly complained that the card didn’t have a file system.
Caveat Emptor (Buyer Beware)
To finish you can delete the rnd files and recover their disk space. Two of our three tests failed, so we can say that we bought a dud SD card.
So if I have any final advice it would be when buying SD Cards, or indeed any other electronics, is to buy reputable brands from reputable dealers. Alas, as we made the purchase abroad, a refund is not likely. Hopefully these instructions can help you avoid the duds, and get a refund if possible.
Chris Collins 