Notes:
A new optimization was added in this build called the hash cache. This is strictly targeted at the level 4 check, and in fact, it's not active on any other check level. The level 4 check on the previous build was VERY slow on machines with small amounts of RAM free or on large databases. The hash cache solves this by explicitly allocating a specific amount of RAM for the second part of the level 4 check, the verification stage. It allocates 256 MB by default but if you have plenty of RAM (gigabytes) and would prefer windows to handle the file caching, you can do that with /hashcache=0.
The more RAM assigned to the hash cache the less passes you have to perform per file verification. With the hash cache off everything is accomplished with one pass but your disk seeks heavily, unless windows caches the hashes into RAM using the built-in OS file system cache.
Also, if you are in the middle of a level 4 verification check with the last build, and it's not moving very fast, you can Ctrl-C it to abort and resume with this new build. Just move the Index.NNNN.dat.md5 file from the temp folder that was created by the tool (WhsDbCheck_Temp) up one level to where the database files are. Then start a level 4 check with this new version and it will find the md5 file, and simulate the read check taking you directly into the verification stage using the new hash cache. Pretty neat.
Changes:
|