3 ms·

What is the percentage of SD cards which are not fake ? Are we sure that popular SD cards on Amazon are not fake ?

by polote 9y ago

notyourday 9y ago
I do not know about Amazon but I have some interesting experiences: Over last several years I have ordered a few hundred SD Cards, some from Ebay some from Amazon, some bought at the stores. Store cards were Kingston and PNY branded - bought at Microcenter. Amazon were some unbranded ones and Sandisks. My method of testing is rather simple - for 64G card generate a file of 63864569856 bytes of random data, dd it onto a card dd result off the card, fingerprint both. If they match the card is probably good. This is what I found: * cards with fake sizes will fail to write entire file with IO error * cards with questionable quality will happily spew the following into kernel log: [6135586.258783] sd 7:0:0:2: [sdf] tag#0 CDB: Read(10) 28 00 07 6f 4f 80 00 00 08 00 [6135586.258785] blk_update_request: I/O error, dev sdf, sector 124735360 [6135586.654749] sd 7:0:0:2: [sdf] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE [6135586.654752] sd 7:0:0:2: [sdf] tag#0 Sense Key : Hardware Error [current] [6135586.654753] sd 7:0:0:2: [sdf] tag#0 Add. Sense: No additional sense information [6135586.654755] sd 7:0:0:2: [sdf] tag#0 CDB: Read(10) 28 00 07 6f 4f 80 00 00 08 00 [6135586.654757] blk_update_request: I/O error, dev sdf, sector 124735360 [6135586.654760] Buffer I/O error on dev sdf, logical block 15591920, async page read * Sandisk had the lowest number of the failures when bought on ebay - sub 10%, highest rate of failures when bought on Amazon - over 90%. * Kingstons from Micro Center passed the tests. * PNYs failed the test. The only wrinkle that I currently have is that I use Sandisks in a dual card Nikon configured for dual write. So far two of the cards that passed the tests created a "Card error" reported by the camera on separate occasions with separate slots. I do not however know if the issue is caused by the the adapter or by the card. I just ordered a few new adapters to see if I can isolate it. [Edit: Formatting] [Late addition: below] The cards that triggered an error in camera passed the read/write test after the error so I am inclined to believe it could be the adapter.
- qb45 9y ago
  > My method of testing is rather simple - for 64G card generate a file of 63864569856 bytes of random data, dd it onto a card dd result off the card, fingerprint both. If they match the card is probably good. One optimization: dd bs=1M count=N if=/dev/urandom | tee /dev/mmcblk0 | md5sum md5sum /dev/mmcblk0
  - notyourday 9y ago
    Ah, I generated a file once and now it is sitting on my disk drive instead of generating it every time. This also allows me to guarantee that I have the data that I have written so I can see if there's a specific set of corruption that happens. That's for example how I found that certain cards do 16GB loop.

What is the percentage of SD cards which are not fake ? Are we sure that popular SD cards on Amazon are not fake ?

by polote 9y ago

What is the percentage of SD cards which are not fake ? Are we sure that popular SD cards on Amazon are not fake ?

I do not know about Amazon but I have some interesting experiences: Over last several years I have ordered a few hundred SD Cards, some from Ebay some from Amazon, some bought at the stores. Store cards were Kingston and PNY branded - bought at Microcenter. Amazon were some unbranded ones and Sandisks. My method of testing is rather simple - for 64G card generate a file of 63864569856 bytes of random data, dd it onto a card dd result off the card, fingerprint both. If they match the card is probably good. This is what I found: * cards with fake sizes will fail to write entire file with IO error * cards with questionable quality will happily spew the following into kernel log: [6135586.258783] sd 7:0:0:2: [sdf] tag#0 CDB: Read(10) 28 00 07 6f 4f 80 00 00 08 00 [6135586.258785] blk_update_request: I/O error, dev sdf, sector 124735360 [6135586.654749] sd 7:0:0:2: [sdf] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE [6135586.654752] sd 7:0:0:2: [sdf] tag#0 Sense Key : Hardware Error [current] [6135586.654753] sd 7:0:0:2: [sdf] tag#0 Add. Sense: No additional sense information [6135586.654755] sd 7:0:0:2: [sdf] tag#0 CDB: Read(10) 28 00 07 6f 4f 80 00 00 08 00 [6135586.654757] blk_update_request: I/O error, dev sdf, sector 124735360 [6135586.654760] Buffer I/O error on dev sdf, logical block 15591920, async page read * Sandisk had the lowest number of the failures when bought on ebay - sub 10%, highest rate of failures when bought on Amazon - over 90%. * Kingstons from Micro Center passed the tests. * PNYs failed the test. The only wrinkle that I currently have is that I use Sandisks in a dual card Nikon configured for dual write. So far two of the cards that passed the tests created a "Card error" reported by the camera on separate occasions with separate slots. I do not however know if the issue is caused by the the adapter or by the card. I just ordered a few new adapters to see if I can isolate it. [Edit: Formatting] [Late addition: below] The cards that triggered an error in camera passed the read/write test after the error so I am inclined to believe it could be the adapter.

qb45 9y ago
> My method of testing is rather simple - for 64G card generate a file of 63864569856 bytes of random data, dd it onto a card dd result off the card, fingerprint both. If they match the card is probably good. One optimization: dd bs=1M count=N if=/dev/urandom | tee /dev/mmcblk0 | md5sum md5sum /dev/mmcblk0
- notyourday 9y ago
  Ah, I generated a file once and now it is sitting on my disk drive instead of generating it every time. This also allows me to guarantee that I have the data that I have written so I can see if there's a specific set of corruption that happens. That's for example how I found that certain cards do 16GB loop.