WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: counterfeits and fakes continue, buyers be aware and do due-diligence always  (Read 3140 times)

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11522
Hi jazzbiker
... Isn't it enough to fill the drive with any non-repetitive sequence and then verify it? ...
To the best of my knowledge, yes it is. In my opinion, it's
also the only way to be absolutely certain there isn't any
slight of hand (funny business) going on.

My reply #1 does exactly that.

Quote
... Why so much hype and movements? ...
If there is any hype, it's probably about time and trying to
speed up the process by doing selective testing. My 4 Gig
SD cards took about 10 minutes to fill with data. If you
extrapolate that to a 64 Gig card it now takes 160 minutes.

If I have to let my computer work a while to confirm my SD
card can be trusted to save all of my data, it's worth it to me.

I often use my camera to document various steps in a project.
Since these steps often involve removing or adding material
to a part, those pictures can't be recreated if they are lost
due to a "faulty" memory card.

Offline jazzbiker

  • Hero Member
  • *****
  • Posts: 934
Hi Rich!
Hi jazzbiker
... Isn't it enough to fill the drive with any non-repetitive sequence and then verify it? ...
To the best of my knowledge, yes it is. In my opinion, it's
also the only way to be absolutely certain there isn't any
slight of hand (funny business) going on.

My reply #1 does exactly that.
I know that Your programming skills are based on the solid digital and hardware background. So You definitely know how flash memory works behind the scenes. I mean an internal block organization, when writing the block includes flashing (clearing) the whole block and then writing row after row where each row consists of N bytes until the whole block will be written. Such things can not be fooled around I believe. (Am I wrong?) The time of the block writing is Tclear + X * Trow. The block size is usually rather big, something of 256K or bigger in size.
What's Your opinion, can the user get the block size of the chips making the flash drive? It's about possible optimizations.

If about f3... Probably its code is perfect, but more than 1K LOC, Qt, Swift, Docker, ... holy shit, welcome to the Bloatshire!

Don't trying to say that someone should not use this package, if it does the job successfully it's all You need.

Offline jazzbiker

  • Hero Member
  • *****
  • Posts: 934
Hi CentralWare!

I didn't know that the plague is so widespread :-( I've never seen not a single fake flash, for me it is the story from the "internet", while You come across day by day :-(

I think as the first step You may promote f3 package among You clients, at least.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11522
Hi jazzbiker
There's a controller that sits between you and the actual
memory chips. That controller contains firmware and is
responsible for determining which chips and when to
perform the actual write. The controller also performs
wear leveling by remapping heavily used locations. I
suspect it may also include some RAM to buffer the
data before it needs to be committed to flash. So it
would not be easy determining block size.

... If about f3... Probably its code is perfect, but more than 1K LOC, Qt, Swift, Docker, ... holy shit, welcome to the Bloatshire! ...
That's a bunch of optional stuff. All I compiled was
f3read and f3write, 51K and 50K respectively, and
that's not stripped.

Offline gadget42

  • Hero Member
  • *****
  • Posts: 731
was reviewing some of Michael Horowitz webpages and was at:
https://defensivecomputingchecklist.com/extracredit.php

and on that page he mentions this interesting device:
https://usbkill.com/

definitely thought-provoking
The fluctuation theorem has long been known for a sudden switch of the Hamiltonian of a classical system Z54 . For a quantum system with a Hamiltonian changing from... https://forum.tinycorelinux.net/index.php/topic,25972.msg166580.html#msg166580