f3
f3 copied to clipboard
AltraMayor
Different results of repeated f3probe tests on the same drives
I've started experimenting with using f3probe to discover faulty drives quickly.
I have a batch known bad 64GB drives that were previously tested with f3write/f3read and rejected so I've decided to use these - knowing I should expect f3probe to identify all of them as bad.
Drive 1
I have tested this one three times in a row an got progressively worse results each time:
F3 probe 7.1
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/sde' is a counterfeit of type limbo
You can "fix" this device using the following command:
f3fix --last-sec=67108863 /dev/sde
Device geometry:
*Usable* size: 32.00 GB (67108864 blocks)
Announced size: 58.59 GB (122880000 blocks)
Module: 64.00 GB (2^36 Bytes)
Approximate cache size: 31.00 MB (63488 blocks), need-reset=no
Physical block size: 512.00 Byte (2^9 Bytes)
Probe time: 7'50"
F3 probe 7.1
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/sde' is a counterfeit of type limbo
You can "fix" this device using the following command:
f3fix --last-sec=4836449 /dev/sde
Device geometry:
*Usable* size: 2.31 GB (4836450 blocks)
Announced size: 58.59 GB (122880000 blocks)
Module: 64.00 GB (2^36 Bytes)
Approximate cache size: 15.00 MB (30720 blocks), need-reset=no
Physical block size: 512.00 Byte (2^9 Bytes)
Probe time: 9'38"
F3 probe 7.1
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/sde' is a counterfeit of type limbo
You can "fix" this device using the following command:
f3fix --last-sec=30755 /dev/sde
Device geometry:
*Usable* size: 15.02 MB (30756 blocks)
Announced size: 58.59 GB (122880000 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: 15'42"
I'm not sure if the drive broke more during testing or if f3probe is using some randomness in it's work that can result in different results.
Drive 2
I've tested another drive that exhibited quite the contrary behavior: the first two tests)resulted in 0 Byte usable space , then the third one was more optimistic, but also identified the drive as Counterfeirt, not Damaged.
F3 probe 7.1
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/sdi' is damaged
Device geometry:
*Usable* size: 0.00 Byte (0 blocks)
Announced size: 58.59 GB (122880000 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: 6.94s
F3 probe 7.1
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/sdi' is a counterfeit of type limbo
You can "fix" this device using the following command:
f3fix --last-sec=3139 /dev/sdi
Device geometry:
*Usable* size: 1.53 MB (3140 blocks)
Announced size: 58.59 GB (122880000 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: 8'11"
Drive 3
F3 probe 7.1
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/sdh' is the real thing
Device geometry:
*Usable* size: 58.59 GB (122880000 blocks)
Announced size: 58.59 GB (122880000 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: 6'41"
F3 probe 7.1
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/sdh' is a counterfeit of type limbo
You can "fix" this device using the following command:
f3fix --last-sec=67108863 /dev/sdh
Device geometry:
*Usable* size: 32.00 GB (67108864 blocks)
Announced size: 58.59 GB (122880000 blocks)
Module: 64.00 GB (2^36 Bytes)
Approximate cache size: 255.00 MB (522240 blocks), need-reset=no
Physical block size: 512.00 Byte (2^9 Bytes)
Probe time: 11'11"
I wonder if running f3brew on these drives and providing it's output would be helpful?
There's a stage of the algorithm of f3probe that it knows that (1) the drive being tested is fake and (2) a possible usable size of the drive (i.e. a continuous segment of good blocks at the beginning of the drive). At this point, f3probe runs a probabilistic algorithm on this segment of good blocks to find bad blocks and to adjust the usable size accordingly; see find_a_bad_block() in libprobe.c. This explains why multiple runs of f3probe on the same drive may report different usable sizes.
Your example suggests that not only is the drive fake, but it's also failing because the second run of f3probe shows that the approximate cache size AND usable size of the drive decreased. This could be a permanent or temporary degradation. Drives heat up during regular use, and heat affects how chips work. If a chip that is almost failing is heated, it'll fail. Thus, if you let this drive cool down, it may get back or closer to the first report.
In any case, the drive is fake and f3probe correctly detected it.
About drive 2. f3probe will report a drive is damaged anytime when there are repeated I/O errors.
Drive 3. This drive is interesting because it passed f3probe's test at least once. If it were not for the second report suggesting that it has started to degrade, this drive could help me to figure out what it's doing to improve f3probe algorithm. When I do these analyses, drives often fail completly due to the repeated test of hypotheses. When a drive is already degrading, it doesn't help much since it makes the results of the tests very confusing and it does not survive many tests.
@AltraMayor - I'm not sure if the 1st tested drive is really fake, because I've already tested it with f3write/f3read and I don't remember any of the drives returning 32 GB of errors.
Also - it's a different talk, if our supplier sent us fakes than if he sent us faulty drives. I'm going to try to investigate this further.
If a drive is fake - a f3write/f3read test should confirm that, right?
@AltraMayor - I'm not sure if the 1st tested drive is really fake, because I've already tested it with f3write/f3read and I don't remember any of the drives returning 32 GB of errors.
I agree. My rule of thumb to distinguish fakes from failing drives is that a failing drive must show at least 50% of its capacity using f3write/f3read or f3brew at least once. I don't include f3probe in this list because it doesn't test all the memory of the drive. Since your drives have shown more than 50% of their capacity usingf3write/f3read, I'd classify them as failing drives.
If a drive is fake - a f3write/f3read test should confirm that, right?
Yes.
I have one which is similar to Drive 2, but for me it reports 0 usable bytes consistently on multiple runs.
F3 probe 7.1
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/sdd' is damaged
Device geometry:
*Usable* size: 0.00 Byte (0 blocks)
Announced size: 59.86 GB (125542400 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'32"
Operation: total time / count = avg time
Read: 0us / 0 = 0us
Write: 1'32" / 4096 = 22.5ms
Reset: 0us / 0 = 0us
f3write fails at the 8th file and f3read confirms everyting is fine up until 8.h2w which has a few corrupted bytes. I copied a 4.5G zip file to the pendrive and the md5sum matches the md5 of the origin.
~/downloads $ md5sum IE9.Win7.VirtualBox.zip
0e1d3669b426fce8b0d772665f113302 IE9.Win7.VirtualBox.zip
/media/mm/363C-D62F $ md5sum IE9.Win7.VirtualBox.zip
0e1d3669b426fce8b0d772665f113302 IE9.Win7.VirtualBox.zip
So in this case f3probe reports 'damaged' instead of 'counterfeit'.
Hi @milangfx,
f3probe is reporting the drive as "damaged" because it gets I/O errors when it writes to some location in the drive. This last conclusion about the write operation comes from the last three lines of the f3probe's output, in which only writes were done. Once I/O errors happen, f3probe aborts because it doesn't know what to do next since its algorithm is more of a game than a linear test like f3write/f3read.
You can try to partition the fake drive to use the begin of it. But I don't recommend doing so because, in my experience, once a drive starts to give I/O errors, it won't last much.
Sorry to comment on an issue that was opened 4 years ago, but I had the same thing happen quite recently on a 64GB flash drive I bought online.
First probe:
F3 probe 8.0
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/sdb' is the real thing
Device geometry:
*Usable* size: 58.59 GB (122880000 blocks)
Announced size: 58.59 GB (122880000 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: 27'46"
Operation: total time / count = avg time
Read: 844.8ms / 4816 = 175us
Write: 27'45" / 4192321 = 397us
Reset: 0us / 1 = 0us
Now I tried another probe a few minutes later:
F3 probe 8.0
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/sdb' is a counterfeit of type limbo
You can "fix" this device using the following command:
f3fix --last-sec=67108863 /dev/sdb
Device geometry:
*Usable* size: 32.00 GB (67108864 blocks)
Announced size: 58.59 GB (122880000 blocks)
Module: 64.00 GB (2^36 Bytes)
Approximate cache size: 30.68 MB (62836 blocks), need-reset=yes
Physical block size: 512.00 Byte (2^9 Bytes)
Probe time: 13'36"
Operation: total time / count = avg time
Read: 7.39s / 131379 = 56us
Write: 13'28" / 442108 = 1.8ms
Reset: 1us / 8 = 0us
What's extremely weird about this is that I managed to recreate that by zeroing the drive using dd if=/dev/zero of=/dev/sdb status=progress bs=512, running another probe was successful, running parted, making a couple partitions, creating different filesystems for them and then probing results in same result as the 2nd one (fake flash).
Also, I noticed when copying files using rsync, the files always get corrupted, even when I limited the partitions until sector 67108863
I will run badblocks on the flash drive to make sure, and then f3write f3write and update this when it's done.
EDIT:
badblocks -v /dev/sdb output:
Checking blocks 0 to 61439999O and do not use Direct I/O, even if it is avail‐
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found. (0/0/0 errors)
f3write last output:
Creating file 59.h2w ... OK!
Free space: 0.00 Byte
Average writing speed: 3.22 MB/s
f3read output:
Validating file 7.h2w ... 1782112/ 100/ 0/ 314940
Validating file 8.h2w ... 2043448/ 104/ 0/ 53600
Validating file 9.h2w ... 2097152/ 0/ 0/ 0
Validating file 10.h2w ... 2097152/ 0/ 0/ 0
Validating file 11.h2w ... 1912762/ 70/ 0/ 184320
Validating file 12.h2w ... 2097152/ 0/ 0/ 0
Validating file 13.h2w ... 2097152/ 0/ 0/ 0
Validating file 14.h2w ... 2097152/ 0/ 0/ 0
Validating file 15.h2w ... 2097152/ 0/ 0/ 0
Validating file 16.h2w ... 2097152/ 0/ 0/ 0
Validating file 17.h2w ... 2097152/ 0/ 0/ 0
Validating file 18.h2w ... 2097152/ 0/ 0/ 0
Validating file 19.h2w ... 2097152/ 0/ 0/ 0
Validating file 20.h2w ... 2097152/ 0/ 0/ 0
Validating file 21.h2w ... 2097152/ 0/ 0/ 0
Validating file 22.h2w ... 2097152/ 0/ 0/ 0
Validating file 23.h2w ... 2097152/ 0/ 0/ 0
Validating file 24.h2w ... 2097152/ 0/ 0/ 0
Validating file 25.h2w ... 2097152/ 0/ 0/ 0
Validating file 26.h2w ... 1912832/ 0/ 0/ 184320
Validating file 27.h2w ... 2048352/ 0/ 0/ 48800
Validating file 28.h2w ... 1961632/ 0/ 0/ 135520
Validating file 29.h2w ... 2097152/ 0/ 0/ 0
Validating file 30.h2w ... 2097152/ 0/ 0/ 0
Validating file 31.h2w ... 2097152/ 0/ 0/ 0
Validating file 32.h2w ... 2097152/ 0/ 0/ 0
Validating file 33.h2w ... 2097152/ 0/ 0/ 0
Validating file 34.h2w ... 2097152/ 0/ 0/ 0
Validating file 35.h2w ... 2097152/ 0/ 0/ 0
Validating file 36.h2w ... 2097152/ 0/ 0/ 0
Validating file 37.h2w ... 2097152/ 0/ 0/ 0
Validating file 38.h2w ... 2097152/ 0/ 0/ 0
Validating file 39.h2w ... 2097152/ 0/ 0/ 0
Validating file 40.h2w ... 2097152/ 0/ 0/ 0
Validating file 41.h2w ... 2097152/ 0/ 0/ 0
Validating file 42.h2w ... 2097152/ 0/ 0/ 0
Validating file 43.h2w ... 2097152/ 0/ 0/ 0
Validating file 44.h2w ... 2097152/ 0/ 0/ 0
Validating file 45.h2w ... 2097152/ 0/ 0/ 0
Validating file 46.h2w ... 2097152/ 0/ 0/ 0
Validating file 47.h2w ... 2090364/ 6788/ 0/ 0
Validating file 48.h2w ... 2095780/ 1372/ 0/ 0
Validating file 49.h2w ... 2097152/ 0/ 0/ 0
Validating file 50.h2w ... 2097152/ 0/ 0/ 0
Validating file 51.h2w ... 2097150/ 2/ 0/ 0
Validating file 52.h2w ... 2092228/ 4924/ 0/ 0
Validating file 53.h2w ... 2091414/ 5738/ 0/ 0
Validating file 54.h2w ... 2090608/ 6544/ 0/ 0
Validating file 55.h2w ... 2093302/ 3850/ 0/ 0
Validating file 56.h2w ... 2092522/ 4630/ 0/ 0
Validating file 57.h2w ... 2089790/ 7362/ 0/ 0
Validating file 58.h2w ... 2088436/ 8716/ 0/ 0
Validating file 59.h2w ... 1211544/ 1384/ 0/ 0
Data OK: 58.03 GB (121690340 sectors)
Data LOST: 565.14 MB (1157404 sectors)
Corrupted: 25.19 MB (51584 sectors)
Slightly changed: 0.00 Byte (0 sectors)
Overwritten: 539.95 MB (1105820 sectors)
Average reading speed: 21.72 MB/s
Either it was a problem with the USB hub, or a specific port, I'm not sure, but f3read and f3write prove it is a failing drive.
When you perform these tests, make sure the USB hub works correctly as well as its port, if possible, remove all other devices currently connected to the USB hub(A charger or other devices connected to the USB hub might cause errors)
Hi @FreezeHeat,
I agree with your conclusion that you have a good drive that is failing since the drive can hold most of its announced size.
While it's possible that you have/had a problem in your USB subsystem and I have dealt with such a case, I don't see enough data to support this conclusion since a failing drive alone can produce your results.
Congratulations on arriving at your own conclusions!