f3probe false positive

[grahamas]

I just bought a SanDisk 64GB microSD card from a trusted brick-and-mortar source and was surprised to find that f3 reported "counterfeit of type limbo" after a ~2s scan. Nothing about the packaging or markings suggested counterfeit (I only ran the test out of an abundance of caution) so I ran it again, and, as expected, a ~2min scan reported the device as good.

$ docker run -it --rm --device /dev/sda peron/f3 f3probe --destructive --time-ops /dev/sda
F3 probe 7.2
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Bad news: The device `/dev/sda' is a counterfeit of type limbo

You can "fix" this device using the following command:
f3fix --last-sec=67108863 /dev/sda

Device geometry:
	         *Usable* size: 32.00 GB (67108864 blocks)
	        Announced size: 59.48 GB (124735488 blocks)
	                Module: 64.00 GB (2^36 Bytes)
	Approximate cache size: 1.00 MB (2048 blocks), need-reset=no
	   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 1.78s
 Operation: total time / count = avg time
      Read: 152.3ms / 4203 = 36us
     Write: 1.61s / 20640 = 78us
     Reset: 2us / 1 = 2us

$ docker run -it --rm --device /dev/sda peron/f3 f3probe --destructive --time-ops /dev/sda
F3 probe 7.2
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Good news: The device `/dev/sda' is the real thing

Device geometry:
	         *Usable* size: 59.48 GB (124735488 blocks)
	        Announced size: 59.48 GB (124735488 blocks)
	                Module: 64.00 GB (2^36 Bytes)
	Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
	   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 1'48"
 Operation: total time / count = avg time
      Read: 805.4ms / 4816 = 167us
     Write: 1'45" / 4192321 = 25us
     Reset: 1us / 1 = 1us

[AltraMayor]

Assuming that the drive is legit, my educated guess is that the drive remapped a bad block. If you search among old issues here on GitHub, you'll find other users who have experienced variations of this behavior of legit drives. There's no software interface for F3 to check if that is the case, so it's a problem without a solution. When I buy a brand new drive, I like to run f3write/f3read to test it and force the drive to remap all bad blocks.

[grahamas]

Gotcha. So to clarify, does the block remapping mean that all future tests should pass? Meaning: I'll maybe get a bad block and the device will remap it, leading to a failed test, then subsequently that block will have already been dealt with so the future tests will pass?

Put another way, should my standard for "good" be that it reaches steady-state pass, rather than that the first test passes?

[AltraMayor]

Gotcha. So to clarify, does the block remapping mean that all future tests should pass? Meaning: I'll maybe get a bad block and the device will remap it, leading to a failed test, then subsequently that block will have already been dealt with so the future tests will pass?

A remapped block behaves as any other good block, so it should pass all future tests.

Put another way, should my standard for "good" be that it reaches steady-state pass, rather than that the first test passes?

It's a good standard. Typically, a single pass of f3write or f3brew is enough to force all necessary remaps. It's worth pointing out that only a few blocks, if any, usually need to be remapped in a legit, new drive.