LabVIEW
Testing for Counterfit Flash Drives
@Blokk wrote:
I really do not understand what is the goal here. You want to test thumbdrives from unreliable sources/sellers to see whether the reported storage capacity is fake or not. What about the expected life time of such cheap products? I can imagine, such low quality products might have the stated storage, but much lower maximum write/read cycles. Or higher chance to get malfunction...There is no way you can test these products for these parameters. So you end up reselling low quality products anyway...Yep, you could make money from this I guess. But the other side of the story...well...
If you buy a flash drive from a reliable source, they give proper traceability, they have customer support, they give you few years of guarantee in some cases...
Honestly, I'd pay a few extra bucks and buy from a reliable source that will replace the thing if it goes bad. It's not like it's cost-prohibitive to buy these things.
Besides, the combined cost of replacing failed ones wouldn't be worth the effort of reselling these things, IMHO. I'd rather paint Civil War chess pieces.
@emw129 wrote:
@rolfk wrote:
Defragmenting an SSD, which flash drives are too, is not only useless but in fact a sure way to shorten its life expectancy significantly! There are no mechanical moving parts in a flash drive, so defragmenting doesn't really give any speed advantage like with a mechanical hard disk, which has to turn an entire turn to access a different sector on the harddisk if it isn't subsequent. And they rotated with 5400 to 7000 RPMs but that still means huge amounts of time for one RPM.
But flash cells have a limited number of write cycles they can survive and defragmenting is generally a very intensive moving around of data sectors to recombine files.
Every decent defragmentation program nowadays will simply refuse to work on a flash drive or SSD.
The flash drive still presents a software interface to the OS that looks like a rotating harddisk for the sake of backwards compatibility so a stupid defragmentation program might attempt to defragment the "harddisk" but in doing so will basically shorten the life for the flash drive.
Thumb Drives (Solid State Memory's) (based on CASFET technologies) have been tested to be written to and read from for hundreds of peta cycles (Quadrillions of Cycles), without loosing the ability to store and read back data. It is not likely you will ever write and read from the same spot that many times. So solid state drives are far more durable than hard drives. Defragmentation only benefits Hard Drives, because in hard drives the sectors and tracks over may write and delete cycles much of the disk data addresses can be come scrambled, and your drive head can find it self ping ponging across the hard drive accessing a file that is on many different tracks and sectors, thus causing the read and write cycles to slow down. De-Fragmentation actually places the sectors and tracks in such locations, as such the head is reading and writing continually without ping ponging around the drive like a ping pong ball. So Defragmentation is more about hard drive timing working together with sector and Track locations to make for smooth read and write cycles with minimal head movements in addition to reclaiming miss-managed empty sectors. In a solid state drive there is no moving head. Defragmentation is occurring in the background to conserve memory management, not head movement and timing.
In hard drive communications there used to be a direct way of forcing the hard drive to write and read specific tracks and sectors. That seems to of gotten lost in the advanced windows operating systems. But defragmentation software seems to know how to do it, even to sold state drives (For what ever reason).
In Theory if I wrote at the beginning, at the middle and at the 1/4th and 3/4th memory points with different data, and went back and read those data points back, I could very quickly prove the size of the Thumb drive was correct, because memory size always in powers of 2. If the Thumb drive was not the size it says it was, then the 1/2 and 3/4th memory locations would over write the beginning and 1/4 memory points. A very quick test to confirm thumb's true drive size, or I would get a memory error when attempting to write to the 1/4, 1/2 and 3/4th locations.
There are a number of existing programs out there that do this, but many of them destroy the thumb drive after doing so, rendering the thumb drive useless, even if it is a good thumb drive: And the others can take 100's of hours to test a Thumb drive without harming the thumb drive:
LOL - what makes you think you have the answer, then? This whole thing sounds just a bit "icky" to me.
Even-though CASFET may allow peta zillion write cycles, defragmenting them has no advantage at all besides burning up energy so I don't see why a defragmentation tool should even bother to try to detect them in order to allow defragmenting them anyhow. The safe thing to do is trying to detect if it is a rotating harddisk and if not to simply disallow any work on a drive.
And flash drives have also the problem that there are always some cells that appear damaged right after production, so the internal chip is always somewhat bigger than the advertised size and those damaged cells get disabled and remapped to spare ones. This also means that the actual "disk image" that is presented to the OS is by no means a linear mapping to the physical cells on the chips. So your theoretical approach of scanning at 1/4, 1/2 and 3/4 of the size is still quite possibly getting dwarfed by the fact that because of the non-linear mapping from the "disk image" to the physical cells you might end up with a positive result while your flash disk still in fact only contains 1/4 of the advertised size.
The whole idea of reliably scanning flash disks for high volume application after having been packaged and sealed in the factory is basically doomed.
If someone is able to modify the controller firmware to lie about the capacity of the flash memory they surely can also modify the mapping algorithm to make sure that anything but a near full memory write and read back operation is unlikely to detect the smaller memory. If the energy that is invested to develop such fake products for a few dollars of gain would be instead put into improving products for real, we might be having even more advanced computers nowadays.
You say that there is a program out there that will verify the drive but destroys it? You're also buying a large quantity and reselling? Unless you're supplying for military specs, use the baker's dozen method. (buy N, destroy 1) I wouldn't think it's likely that a manufacturer would only make some drives counterfeit.
@ATE-EGNE wrote:
You say that there is a program out there that will verify the drive but destroys it? You're also buying a large quantity and reselling? Unless you're supplying for military specs, use the baker's dozen method. (buy N, destroy 1) I wouldn't think it's likely that a manufacturer would only make some drives counterfeit.
? Any legit manufacturer would make NO counterfeit drives...
@billko wrote:
? Any legit manufacturer would make NO counterfeit drives...
Correct, this is a bit of an XY problem. The real problem is "Is the manufacturer legit?"
If:
1) all drives from counterfeit manufacturers are counterfeit.
2) all drives from legitimate manufacturers are legitimate.
Then:
Buy one drive per manufacturer, and test the drive destructively.
If (test == good)
{ manufacturer == legit;}
else
{manufacturer == counterfit;}
If we want to control for possible defects, I'd suggest a destructive test on every N drives where N decreases over time as the manufacturer's legitimacy falls farther out of question.
@ATE-EGNE wrote:
@billko wrote:
? Any legit manufacturer would make NO counterfeit drives...Correct, this is a bit of an XY problem. The real problem is "Is the manufacturer legit?"
If:
1) all drives from counterfeit manufacturers are counterfeit.2) all drives from legitimate manufacturers are legitimate.
Then:
Buy one drive per manufacturer, and test the drive destructively.
If (test == good)
{ manufacturer == legit;}
else
{manufacturer == counterfit;}
If we want to control for possible defects, I'd suggest a destructive test on every N drives where N decreases over time as the manufacturer's legitimacy falls farther out of question.
Ahhh, I see where you are coming from. 🙂
