Diskovery (beta)

188 is treated as a vital attribute, so it's flagged for review (yellow highlight) is its raw value is not all zeroes. The other four attributes that are considered vital are 5 (reallocated sector count), 187 (uncorrectable error count), 197 (unstable sector count) and 198 (uncorrectable sector count). All are courtesy of BackBlaze analysis from some time ago.

 

Thanks for the clarification. Do you know what 188 means actually ? My PC is working fine except for some startup issues at random, indicating a BIOS issue (some hash being not correct, after shutdown and reboot it starts fine again).
I find this nifty software very nice.
Oh, maybe out of topic, is there a way to move my license for bvckup2 from one PC to a new one ? Thanks.

 

Re: 188 - according to this it means

but more importantly:

meaning that Micron themselves don't consider this a critical attribute. I'll patch up the app to observe this.

Re: Bvckup 2 license - drop me an email please.

 

Thanks for the clarification about ID 188, even if this confirm I am bit lost with these parameters. And thanks for bvckup 2 too.

 

Pretty cool app.

 

Report send yesterday.

 

New version is out - 0.9.1.0

• Massive improvements to the SMART attribute interpretation - now uses 25+ vendor-specific tables and counting.
• Improved UI support for inspecting SMART attributes, including an option of toggling between raw (hex) and interpreted formats
  
• Support for saving/viewing snapshots
• Support for copying what you see in the UI to the clipboard, as plain text
  
• New icon (here)
  
• New domain for the homepage - https://diskovery.io - a rare example where the .io tld makes at least some sense

Links:

• Full change log
  
• Direct download

Short version of the TBD list:

• Support for reading NVMe health data
  
• Support for LSI-based RAID controllers, including MegaRAIDs and PERCs

As per usual, any thoughts or comments - let me know.
If you are going to run it, please submit the scan log.

 

Alex, the GET (Direct download) link above is not found via DNS... maybe a typo?

Edit: missing a ":" in the link address... FYI

 

Fixed, thanks.

 

A, after first DISK selection (successful), seems to be hung on other disk selections following the first (no change in right pane).

 

Sent you a description and LOG accordingly... SSD involved in issue.

 

Should be resolved now. For SSD drives it in fact looped trying to parse certain unknown SMART attributes.
Please re-download and give it another try.

 

Looks much better... thanks!

 

Froggie, your Seagate drive is really something... When queried for ATA IDENTIFY block one way, it responds correctly. When queried in a slightly different way, it actually returns the SMART attribute summary (with correct checksum and what not). Then, when asked for SMART attributes, it does return them, but this time the checksum (a single byte out of 512) is different and wrong. This is easily the most WTH drive behavior I've seen to date. What is this lovely device? Was dropped often when it was a child or something?

 

I've sent you some additional guidance... I think. Yup, it's a bit wierd.

 

First of all... thanks much to Alex for his help with this (and that's what happened to ME when I was a baby).

With some software tweaking on his side and some hardware troubleshooting on my side we came to the following conclusion... the drive is fine but the external DOCK that houses it, also HOSES it. Just to pass this on to any interested parties, here's the DOCK information...

ORICO 6518series (MPN: ORICO 6518SUS3)

It's a combination eSATA/USB3 flat entry device. I have been using them for a coupla years now and they have been flawless in both their eSATA and USB3 data usage as far as system storage devices are concerned... that is until DISKOVERY (a GREAT product, BTW) discovered our little internal issue. Both of the units I have act in exactly the same manner. The issue is basically in eSATA mode, discovery methods from Windows produce inconsistent results for the device docked... USB3 mode seems to work just fine.

Thanks again, Alex, for all your help with this (DAMN that Diskovery program!).

 

Having looked at the logs again I have to say that this is not a very good dock.

A request for IDENTITY block using ATA PASS-THROUGH interface returns a mangled SMART attribute block. That's already not very good.

A request for SMART block returns the same mangled response - the checksum is wrong, there's an attribute with an ID of 255 at the last slot, etc.

A request for SMART thresholds via CSMI yields an outright failure, even though SMART attributes *are* readable that way, but in their half-corrupted form.

All in all, it's a good old buggy firmware. Sorry, Froggie.

 

@angstrom Do you have an ETA on when Diskovery will reach stable build status? Thank you.

 

It is currently stable as in "no known issues". It is in beta status because I want to add NVMe and MegaRAID support first. I was hoping to complete this before the end of August, but this is not likely to happen. Likely to be in late September - October time frame.

... though I guess we can just drop "beta" and call it a release

 

@angstrom Excellent, thank you for your clarification.

 

Update's out. Change log is here - http://diskovery.io/changes

 

kool

 

Update's out, adds full support for NVMe drives among other things.

 

New build is available - 0.9.9 - adds logging of various details for NTFS volumes, including their cluster size (a.k.a. "allocation unit").
Also got it rebuilt using newer Visual C++ toolchain, so naturally the executable grew by almost 20KB just because of that.

https://diskovery.io

 

What about my suggestions? Will any of them be implemented soon?