Validrive and SSD

  • Release Candidate 6
    Guest:
    We are at a “proposed final” true release candidate with nothing known remaining to be changed or fixed. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.

Parisien-Entraide

New member
Oct 10, 2023
4
0
Hello,

I see nothing aubout SSD

Is the program only for USB sticks?


I tried with an old SSD (Crucial M4 d 256GB)

Detection: OK
Scan: OK
Report: OK

declared drive size 256,060,514,304 (256GB)
validated drive size 256,060,514,304 (256GB)
highest valid region 256,060,514,304 (256GB)



But... is it reliable?
 
First sentence on home page says "Quickly spot-check any USB mass storage drive for fraudulent deliberately missing storage."
So, should work with an SSD. I tested with an SSD and it ran fine.
Have not tried an external mechanical hard drive.
 
It's designed for USB thumb drives predominately. Remember that it's a free tool, that is intended for a single purpose. If you want a more robust tool for your SSD and HDD devices, then SpinRite is the tool for that.
 
I was excited to find the ValiDrive utility. I checked a 64GB Sandisk USB and it was fine.

I next checked a Kingston 16Gb USB and it stopped after detecting a bad read block and a bad write block.
I planned to do a low level format to try and fix this, but the drive is now set to read-only.

I tried a second Kingston 16Gb USB and got exactly the same result.
After much Googling I've been unable to reverse this.

I'm guessing that the drive had been OK till now as the reading and writing was under the control of the built-in controller on the USB. It was aware of the problems spots and could stay away from them.

I suspect that ValiDrive bypasses the HW controller on the drive and attempts to access the storage directly. If it hits a bad spot, the HW controller steps in and flags the drive as read-only. From what I've read, this is standard behavior to allow any get data to be retrieved from a failing drive.

If this is true, it means that ValiDrive has a good chance of trashing any drive that has bad areas that are currently taken care of by the drive's internal software. I hope I'm wrong about this but it would be worthwhile looking into it.
 
  • Like
Reactions: Tom-Ottawa
But... is it reliable?
Yes, it is. Although ValiDrive was created primarily with USB sticks in mind, it will work with any drive plugged into a USB port, be it a USB stick or a HDD, SSD, or NVMe drive. I have tested it successfully on a legitimate 4 TB USB 3.0 HDD and it screamed thru it in seconds.
 
drive is now set to read-only
If you have a flash device with bad write blocks, you should retire it ASAP. Failing to do so is asking for a world of hurt when the OS tries to use it and it flakes out in somewhat unpredictable ways, such as becoming read-only, as you experienced.
 
That drive was already dead, just a zombie that did not know it yet. Went and failed when the computer went to read a LBA that had failed silently, and thus the read error, while the controller was attempting to read the block, failed, and also probably also had run out of spare blocks to use, and thus did a final write to the internal hidden and non visible block table to set the read only flag, and stay that way. Internally flash will fail silently, especially MLC, which has much lower tolerance to drift of the thresholds, and relies on error correction a lot, so a read can actually result in a not fast return of data, as the flash controller does a few retries on the block, stores it in RAM, then marks the block as bad, and writes the block to a spare block, and updates the internal allocation table, then finally returns the data block to the outside. Can result in the USB controller software timing out and returning a read error before the drive finishes the action.

I did actually look to see how long a USB stick would run, so used it to run a live disro of Ubuntu, with swap enabled, and left it running for a few days. Drive died after 2 days of being on, just from all the log entries being written to it, and all the regular disk tasks. not used at all, just left running, on a rather old SLC (MLC was a long way off) flash drive of 4G.
 
  • Like
Reactions: peterblaise
I next checked a Kingston 16Gb USB and it stopped after detecting a bad read block and a bad write block.
I planned to do a low level format to try and fix this, but the drive is now set to read-only.

I tried a second Kingston 16Gb USB and got exactly the same result.
After much Googling I've been unable to reverse this.
I'd ditch that drive anyway, it went read-only for a reason. Many NAND controllers act that way once specific errors/conditions are met.
I suspect that ValiDrive bypasses the HW controller on the drive and attempts to access the storage directly.
Nope, it does not.
 
Thank you for all the answers

Tested with ;

Samsung PRO 850 (512 Go), 860 Pro (1To)
Samsung EVO 512 Go, 2To (2 SSD) 4To (3 SSD)
Crucial M4 256 Go
Crucial BX 300 500Go
Crucial MX 300 2 To
Crucial MX 500 1To and 2 To (3 SSD)

But the main test was with a Chinese model found on Amazon, because with this brand "Faxiang" there are a lot of FAKE SSDs
Fanxiang 4TB model: OK

I also tested several brands of USB keys from 1 to 512 GB / No problems
Unfortunately I don't have any fake USB keys or ones with read or write errors (and yet some are over 10 years old and are regularly used)

The big advantage compared to H2testw is the speed of execution of the test, and the more readable report
 
First of all I would like to say that ValiDrive is a great piece of software, which I have tried on four USB drives both USB 2.0 & 3.0.

USB drive sizes tested are 8GB, 16GB, 32GB & 128GB all which validated successfully.

I also tested a 32GB & 1TB SD card using a USB 2.0 speed internal card reader which also validated successfully, which brings me to one question.

How was the USB 2.0 speed internal card reader so fast at validating a 32GB & 1TB SD cards so fast?

Please see the full 1TB SD card test results below.

Thanks

Adam
 

Attachments

  • Screenshot 2023-10-14 165944.png
    Screenshot 2023-10-14 165944.png
    178.8 KB · Views: 84
@Adam-F,
If I understand the question correctly even: USB 2 vs. next versions is largely a bandwidth thing when it comes to speed. ValiDrive just transfers modest amounts of data (8 KB reads/writes IIRC) so I can imagine USB 2 bandwidth isn't a limiting factor here.
 
It's just odd, because the 1TB SD card read in the USB 2.0 internal reader, was completed in about 10 seconds, ware a 16GB USB stick that was a USB 2.0 stick ran for about 90 minutes to complete.
 
It's just odd, because the 1TB SD card read in the USB 2.0 internal reader, was completed in about 10 seconds, ware a 16GB USB stick that was a USB 2.0 stick ran for about 90 minutes to complete.
Yes but you asked as if it was weird that the 1 TB SD ran so fast with USB 2, which I argued isn't because due to small writes ValiDrive does we do not run into bandwidth problem. So why is the 1 TB fast and the 16 GB slow? It's Because of properties of these individual devices, using different NAND, controllers and whatnot. How is this odd? Maybe I just fail to see the point / question.
 
Yes remember the most common method used to derive the clock on flash drives is the USB data clock, which is used by the controller to lock an internal on chip oscillator to the USB data clock edges, and generate a 24 or 48MHz clock internally, which is used to drive all aspects of the chip controller. That then limits the internal MCU, a derivative of the venerable Intel 8051, which is from the 1970's, in the processing speed it has. It is fast enough to run at enough speed to move data to a buffer to generate a frame of USB data, but overall the USB transfer speed is slower. The SD cards internally, as they have gotten faster, have an on chip 100MHz plus oscillator, and a core that can handle streaming data in and out at much higher speeds, as the SD cards got optimised for video and photo use, as this was a camera format, and thus was optimised for write speed in design. Thus your 10x card can run up to 120MHz as a transfer rate clock, which of course translates into fast data, as the USB host can use block transfers to send a huge chunk of data per operation, with no need to request each block like with the USB stick, with it's limited clock rates. USB3 card readers and flash drives will be faster, even on USB2.x ports, as internally they generate a high speed clock for the controller, and operate faster.
 
  • Like
Reactions: peterblaise
". . . the main test was with a Chinese model found on Amazon, because with this brand "Faxiang" there are a lot of FAKE SSDs
Fanxiang 4TB model: OK
. . . The big advantage compared to H2testw is the speed of execution of the test, and the more readable report . . ."

How do you know the Fanxiang 4TB is OK if you did not run h2testw on it ( you didn't say )?

H2testw and ValiDrive do different things.

H2testw tests a partition, not an entire drive, by writing and reading back, generally every byte in the partition, and does not appear to be tricked by any fake drive's savvy programming so far.​

ValiDrive tests a drive, not a partition, by sampling reading and writing across the drive, not everything, just samples, and has been tricked by some fake drive's savvy programming.​

Run both H2testw and ValiDrive on the Fanxiang 4TB and let us know what you find.

Thanks.
 
Last edited: