ValiDrive tire kicking

  • SpinRite v6.1 Release #3
    Guest:
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. 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 please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

MichaelRSorg

Well-known member
Nov 1, 2020
109
17
routersecurity.org
Some random thoughts after initial usage of v1.0

Thank you, Steve. Great program.

The home page of ValiDrive does not say which versions of Windows are supported.

An estimate of the time needed to run the program would be useful. I tested 4 flash drives and the elapsed time was drastically different because one was extremely slow.

There is a drive capacity difference between the drives self-reporting and what Windows 10 reports.
I tested two 64GB (marketing number) flash drives
-- ValiDrive said one self-reported as 62GB, Windows 10 said it was 57.7GB
-- Another one self-reported to ValiDrive as 64.2GB, Windows 10 said that one was 59.7 GB
On a related note, a (marketing) 128GB drive, self-reported as 123, Windows said it was 114
I trust Steve much more than Windows but curious if anyone can explain why the capacity sizes are different.

FYI - speed test results from 4 different flash drives
avg read: 882, 1816, 1870 and 2491
avg write: 995, 3734, 5210 and 623,200
the last number is not a typo. Also, my last PNY drive :)
A ballpark on speed test results would be nice. Something like: the fastest drives are X speed, most are Y speed, the worst we have seen is Z speed.

User Interface
---------------
after testing: the CLOSE button looks it will close the program, but it does not. The text for the button would be better as SEE FULL REPORT or MORE or ...

while testing: the Current operation in progress is read/white/green. What do the colors mean? If you have a fast flash drive this changes too quickly to notice or care. But if you have a very slow one (see above) you can see the colors change.

detailed report
instead of minimum I suggest calling the field "fastest read".
instead of maximum perhaps "slowest write"
 
Last edited:
I trust Steve much more than Windows but curious if anyone can explain why the capacity sizes are different.
It is Marketing math versus CPU math.

Marketing uses base 10 math. Thus: 1 TB = 1000 GB and 1 GB = 1000 MB. Easy for consumers to wrap their minds around.

Windows uses CPU base 2 math. Thus: 1 TB = 1024 GB and 1 GB = 1024 MB. Not so easy for consumers to wrap their minds around.

If this math difference is extended from MB to KB and from KB to B then Windows, using CPU base 2 math, will see about 93% of the capacity (in Bytes) claimed by Marketing.

Marketing's only concern is selling drives...
 
Mis-understanding. The difference between marketing and reality is not what I was asking about.

My question was on the difference between what ValiDrive says the flash drive reported as its capacity and what Windows 10 shows as the capacity of the thing.

Interesting to note that a Samsung flash drive, with a marketing capacity of 64GB, reported to ValidDrive that it was 64.2GB. Never would have expected that.
 
Mis-understanding. The difference between marketing and reality is not what I was asking about.

My question was on the difference between what ValiDrive says the flash drive reported as its capacity and what Windows 10 shows as the capacity of the thing.
Ahh . . .my bad. :(

Apologies!
 
I somehow missed any and all information on validrive. Is there a link where I can find out about it. Maybe it's in a podcast I've missed. I couldn't find anything about it in the menus of the GRC site. Thanks.

May your bits be stable and your interfaces be fast. :cool: Ron
 
self-reported as 62GB, Windows 10 said it was 57.7GB
Windows 10 has a number of ways to "report" drive sizes, which of these are you referring to?

Also, you need to make sure which devices are using GB versus which are using GiB. (i.e. the difference between 1000 * 1000 * 1000 and 1024 * 1024 * 1024) Each of those extra 24 bytes may seem insignificant, but if you have enough of them they really add up. Also, don't forget some ways report the "core" drive capacity, and others report the file system capacity, which may be different because of reserved space and other meta-data related storage.
 
@magnificent_starfish , @DanR Thanks for the links. I just looked at the web page and downloaded the utility. My thoughts are DANG it's disgusting that we have to have such a thing. There sure are lots of evil people out there. Just make a blinking real drive and sell it at a reasonable profit. They probably had to go to a lot of trouble to reprogram the controller to fake everything. I usually buy only Sandisk or Samsung flash memory with the seller actually being Amazon so hopefully it won't be a problem. But thanks @Steve for rescuing us.

I taught at the college level at one time. I always told my students don't rely on a thumb drive. Your data can suddenly vanish. Even if you're doing nothing to the drive, the little electrons can leak out of the little basket over time. It's even in the flash specs. Or maybe you walked on a carpet with static and then touched a light switch or something. Always have a backup. What's the cliche? Two is one, one is none.

May your bits be stable and your interfaces be fast. :cool: Ron
 
Windows 10 has a number of ways to "report" drive sizes, which of these are you referring to?

I was referring to My Computer which shows the total capacity of each drive. I agree, that one possibility is that Windows 10 is subtracting out the size of the file system index data structure. Or, maybe the maximum potential size of the file system index.
 
". . . There is a drive capacity difference between the drives self-reporting and what Windows . . . reports . . . [ 64GB drives ] ValiDrive said . . . 62GB, Windows . . . said . . . 57.7GB . . . [ another ] . . . ValiDrive . . . 64.2GB, Windows . . . 59.7 GB . . . 128GB drive, self-reported as 123, Windows said it was 114 . . ."

1699813648145.png


And I get drive letters not agreeing, either.

As others have commented, every program measures stuff differently, especially Base 2 versus Base 10.
Marketing and sales use the highest result, such as 64 GB.​
Programmers measure available bytes, sectors, and clusters, and differentiate between data and metadata storage, such as 62 GB.​
Operating systems leave uncountable space off, such as little blank areas before or after the partition so the partition beginning and ending align with the operating systems' scheme for block management, such as 57 GB.​

ValiDrive measures the raw drive, and how many sectors there are, either 512 bytes per sector or 4K bytes per sector.

Windows reports the partitioned data space, how many clusters of sectors are available after partitioning and formatting, and then does the match on how many bytes are in those clusters.

Then there's the math to get from bytes to KB to MB to GB, dividing by 1,024 ( 2^10 ) at each step, not dividing by 1,000 ( 10^2 ) at each step, where my illustration of a Windows-reported 15,737.587.328 byte partition equals 14.6 GB, versus ValiDrive seeing a raw 15,728,640,000 bytes equaling 15.7 GB.

Same drive, different perspectives.

Of course, it's labeled and marketed as a 16 GB drive, which neither Windows nor ValiDrive measured exactly, let alone the same.

Though this is not new, it is something that ValiDrive does not address, even though ValiDrive supposedly is validating if a drive has the storage it claims to have, really meaning that ValiDrive compares the storage a drive declares to the hardware/software discovery system, not the storage size declared on the marketing label.

So I've got a 16 GB drive that presents as ~15 GB or ~14 GB, depending.

You've got 64 GB drives, one that presents as ~62 GB and ~57 GB, one that presents as ~64 GB and ~59 GB, and a 128 GB drive that presents as 123 GB and 114 GB.

ValiDrive does not address these comparatively minuscule discrepancies on it's way to looking for big discrepancies, such as a 32 GB drive presenting as a 2 TB drive.

Thanks.
 
Last edited by a moderator: