Hacker News Reader

Hacker News

Comment by bagels | Hacker News Reader

Full thread

bagels

How long does this tool take to verify a real drive?

"it only writes what’s necessary to test the drive"

How does that actually work, wouldn't that mean the whole stated capacity would have to be written?

View on HN

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.

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

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.

Why would they only have a small write cache?

You can map a lot of memory from pcie

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.

accidentally quadratic.

you just want two non-nested loops.

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

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).

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.

> 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

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

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

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)

Reply on news.ycombinator.com