TeraByte Unlimited

yes, that is the one. The view where you can see the drives in a tree
format where you'll see phylock under things like drv0

but also, try using the "disable trim" option as a test.


"Triplehammer" wrote in message news:[email protected]...

When you say "use device tree", what do you mean? I did find DeviceTree
V2.30 at osronline.com but it seems like I have to create an account there
to download it and it doesn't mention OS support after Win7/Server2008R2.
Just wanted to be sure what you meant before I did that.

If it helps, in the regkey
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}
in LowerFilters there is only EhStorClass and in UpperFilters there is only
phylock and partmgr.

TeraByte Support wrote:
> Then it sounds more like you want to check the drivers stack on the disk
> drive because something is modifying the sectors beyond where vss and
> phylock are located or using special calls to tell the driver on the disk
> stack to modify the drive that the file system didn't ask it to (vss
> doesn't
> know about) and not something phylock would know about. You can use
> something like device tree to look at the drive stack rather than just
> looking at upper and lower filters.

I normally do use Disable TRIM because I'm backing up SSDs; tried it several times without.

Okay, I've installed DeviceTree and run it, and there's a huge list of drivers.
DRV \Driver\ACIP\
DRV \Driver\ACPI_Hal\
and so on. There are several hundred items on the list, including
DRV \Driver\phylock
which has three of these:
DEV (unnamed)
each of which has
ATT Attached: (unnamed) - \Driver\partmgr
I suppose each DEV is a drive - the two SSDs and the one HDD.

Anything particular I should be looking for? Should I make screenshots of anything? I'm in a bit over my head with this.

Normally you don't have to use the disable trim option, but do use it now, only because the only thing in the stack so far would seem like the enhanced filter driver, which maybe is accepting some special trim command around the normal process. You could also go to windows disable it manually for a test.

On the device view, you want the other view in devicetree which shows the device and what is on the device stack.

However, If I recall that particular drive doesn't support DRAT so if there is any allocated file system clusters that has been trimmed and only allocated and not used/written, those sectors data can change (with no real change) which the validation byte-for-byte will find. Which I bet is most likely what is going on here...


"Triplehammer" wrote in message news:[email protected]...

I normally do use Disable TRIM because I'm backing up SSDs; tried it several
times without.

Okay, I've installed DeviceTree and run it, and there's a huge list of
drivers.
DRV \Driver\ACIP\
DRV \Driver\ACPI_Hal\
and so on. There are several hundred items on the list, including
DRV \Driver\phylock
which has three of these:
DEV (unnamed)
each of which has
ATT Attached: (unnamed) - \Driver\partmgr
I suppose each DEV is a drive - the two SSDs and the one HDD.

Anything particular I should be looking for? Should I make screenshots of
anything? I'm in a bit over my head with this.

Here's a link to a screenshot of what I see in DeviceTree when I use the "PnP" view instead of the "Driver" view:
http://i.imgur.com/VwqTyNE.png
I expanded what I could and still keep them in the screenshot. Where should I go from there?

How would I disable the enhanced filter driver?

it's actually under the "D" under \driver\disk which will show all items on
the disk stack (you'd want to look at the source drive).

But, as mentioned, it's probably related to the other issue, which means
byte-for-byte won't work until the sectors are rewritten. Always try to get
a drive with DRAT (or move to NVMe which requires consistent reads in
trimmed areas in its specs). So so you backup with validate, then restore
it. then backup byte for byte would work in that case.


"Triplehammer" wrote in message news:[email protected]...

Here's a link to a screenshot of what I see in DeviceTree when I use the
"PnP" view instead of the "Driver" view:

[
http://i.imgur.com/VwqTyNE.png
](http://i.imgur.com/VwqTyNE.png)

I expanded what I could and still keep them in the screenshot. Where should
I go from there?

How would I disable the enhanced filter driver?

After some reading in some other threads about DRAT support, it would appear that consumers have no way of finding out which SSDs support DRAT and which don't, until something stops working, because SSD manufacturers don't talk about DRAT support, consumers very rarely hear about it, talk about it, or know about it, and it appears that there are no applications (not even TrimCheck) that will confirm whether or not an SSD supports DRAT. Word of mouth, what little there is of it, appears to indicate that the Samsung 850 Pro is one of them.

Neither the manual or the help says that byte-for-byte can fail because of DRAT. It is especially not mentioned in the Validation Byte-for-Byte Failure page:
http://www.terabyteunlimited.com/kb/article.php?id=151
Perhaps you need to rethink how you are presenting Validate Byte-For-Byte. The SSDs that may see Validate Byte-for-Byte failures are very popular.

TeraByte Support wrote:
> But, as mentioned, it's probably related to the other issue, which means
> byte-for-byte won't work until the sectors are rewritten. Always try to
> get
> a drive with DRAT (or move to NVMe which requires consistent reads in
> trimmed areas in its specs). So so you backup with validate, then restore
>
> it. then backup byte for byte would work in that case.
>
>
> "Triplehammer" wrote in message news:[email protected]...
>
> Here's a link to a screenshot of what I see in DeviceTree when I use the
> "PnP" view instead of the "Driver" view:
>
> [
> http://i.imgur.com/VwqTyNE.png
> ](http://i.imgur.com/VwqTyNE.png)
>
> I expanded what I could and still keep them in the screenshot. Where
> should
> I go from there?
>
> How would I disable the enhanced filter driver?

Triplehammer,

We have 6 Intel 530 and 535. They support DRAT and DZAT. You can confirm this in the Intel SSD Toolbox, Drive Details.

We have 2 SanDisk SSD models (they were cheap so I bought them). One does and the other doesn't support DRAT. It's in the SanDisk SSD Dashboard, Tools, Drive Details, Advanced, TRIM

I must say the SanDisk that doesn't support DRAT is the HD0 in my test computer and /vb has never failed.

I apologize for my little rant above. I'm getting frustrated that vb keeps failing.

I attempted to do a backup of SSD #2 (Win10 Samsung 850 Pro) while booted up on SSD #1 (Win7 Intel 335) and byte for byte failed, where it hadn't before.

I made an IFL boot DVD and successfully backed up SSD #2 with byte for byte, then restored it. I then booted up SSD #2 and attempted to back it up with IFW but vb failed.

Here's the DeviceTree of the drives:
http://i.imgur.com/KfU3xyP.png

it can still have to do with a temp file created while in that copy and
backup / restore out side wouldn't update. To check if that's the issue,
you could try a DRAT or normal drive (restore to it, then boot from it and
do the bfb). Otherwise if you have something hiding it's writes in windows,
you can use the findlbaf.zip from the ftp site; run command prompt as
administrator then launch that to find file files involved with changing to
get an idea. Now if it's something hiding, down at the disk level, it could
hide itself so nothing found.

That all said, it could be the ssd drive as well, the failure of those are
going to be different than normal drives. The difference when its
heavy in use vs not being used. So another thing is to reset the entire
thing (wipe it or trim the entire thing), then restore. Another drive
will tell if it's windows environment or the drive.

"Triplehammer" wrote in message news:[email protected]...

I apologize for my little rant above. I'm getting frustrated that vb keeps
failing.

I attempted to do a backup of SSD #2 (Win10 Samsung 850 Pro) while booted up
on SSD #1 (Win7 Intel 335) and byte for byte failed, where it hadn't before.

I made an IFL boot DVD and successfully backed up SSD #2 with byte for byte,
then restored it. I then booted up SSD #2 and attempted to back it up with
IFW but vb failed.

Here's the DeviceTree of the drives:

[
http://i.imgur.com/KfU3xyP.png
](http://i.imgur.com/KfU3xyP.png)

On Sun, 28 Aug 2016 00:59:50 PDT, just as I was about to take a herb,
Triplehammer disturbed my reverie and wrote:

>I did chkdsk /f already (see above).

Try chkdsk /r. That fixes read/write errors. It fixed an issue here on
a drive that chkdsk /f passed as fit.
--
Cheers,

DrT

"If you want to find out what is wrong
with democracy, spend five minutes with
the average voter." - Winston Churchill