How long does this tool take to verify a real drive? "it only writes what’s nece...

10000truths · 2024-09-12T23:30:36.000000Z

Define hash(x) that takes an integer and returns a sector-sized hash.

Define S = claimed total number of sectors.

  for(i=0; i<S; ++i) {
    write_sector(i, hash(i))
    for(j=0; j<=i; ++j) {
      if(hash(j) != read_sector(j)) {
        return i
      }
    }
  }
  return S

The above pseudo code will return the number of sectors the flash drive actually has.

sroussey · 2024-09-12T23:34:38.000000Z

Write everything before read or you will just get back cached results.

10000truths · 2024-09-13T01:57:32.000000Z

Cache can only mask performance. It can't mask fraudulent reporting of storage capacity. At worst, the test above will return (size of write cache + size of actual storage), but a bargain-bin flash drive is going to have a very small (if any) write cache, so it's not going to overestimate by much.

geocar · 2024-09-13T10:31:26.000000Z

Why would they only have a small write cache?

You can map a lot of memory from pcie

bagels · 2024-09-13T00:43:52.000000Z

Sure, so if the drive is genuine, or even one sector short (I recognize it's more typically a much larger fraction for the fraudulent drives), you'd still have to write to nearly the full stated capacity to verify.

This approach though, seems to require reading the first sector many times.

nullc · 2024-09-13T14:20:42.000000Z

accidentally quadratic.

you just want two non-nested loops.

10000truths · 2024-09-13T20:04:15.000000Z

It's not accidental. It's optimized to minimize the number of writes necessary to determine whether the reported storage capacity is genuine.

nullc · 2024-09-13T23:12:32.000000Z

If it is genuine your quadratic version will perform the same number of writes as the linear time solution.

If it is non-genuine what do you care how many writes it will perform? In that case the media is trash anyways.

The quadratic test will take an eternity due to the n^2 hashing operations and reads unless it terminates extremely early.

If you really have a need to terminate writing early, you could at least perform only a few reads randomly after each write (which will terminate early with high probably not long after you reached the maximum).

jtriangle · 2024-09-12T23:07:35.000000Z

write 0001, read and confirm, repeat until drive is full.

For a fake drive, it'll take awhile, because the underlying storage is much, much slower than it should be, often usb2 speeds.

Realistically, this is just a test that satisfies curiosity without opening the drive. It's obvious when you have a fake drive because it won't benchmark anywhere near what it should.

bagels · 2024-09-13T00:45:15.000000Z

From what I understand, some of the fraudulent drives have firmware that just wrap the writes around to the beginning.

ungamedplayer · 2024-09-13T04:16:41.000000Z

I had or had one in my possession that did exactly this. Another writes above a certain size were simply discarded.

CaptainOfCoit · 2024-09-12T23:10:00.000000Z

> For a fake drive, it'll take awhile

Or, for any mid to large sized real storage. Writing/reading 64GB takes a while, fake or not

sukmaagung · 2024-09-13T04:01:55.000000Z

The problem is the fake storage can just overwrite the new data on top existing data. Then you always confirm new data is correct because it broke the old ones.

But something like 2TB micro SD when actually it only has 64GB capacity, that will be very long time waiting 2TB to fully written.

How about write some file, then verify sometimes the new sometimes the old one, repeat until full.

Write(0.h2w) Write(1.h2w) Read(1.h2w) Write(2.h2w) Write(3.h2w) Read(3.h2w) Read(2.h2w) Write(4.h2w) Write(5.h2w) Read(5.h2w) Write(6.h2w) Write(7.h2w) Read(7.h2w) Read(6.h2w) Read(4.h2w) Write(8.h2w) Write(9.h2w) Read(9.h2w) Write(10.h2w) Write(11.h2w) Read(11.h2w) Read(10.h2w) Write(12.h2w) Write(13.h2w) Read(13.h2w) Write(14.h2w) Write(15.h2w) Read(15.h2w) Read(14.h2w) Read(12.h2w) Read(8.h2w) ...Read(0.h2w)