Tools for hard drive diagnostics, repair, and data recovery
Post a reply

Re: Another useless data recovery toy?

January 9th, 2025, 8:37

The work continues.

Device ID received. Data transfer (read and write), recalibrate, sleep - everything is working well. The last things are left - software and hardware reset. My test disk drive especially has few UNC sectors for testing that.

I think it makes no sense to implement SMART, there are a lot utilities for this.

2025-01-09 22-25-18.png

Re: Another useless data recovery toy?

January 9th, 2025, 8:43

aekhv wrote:I think it makes no sense to implement SMART, there are a lot utilities for this.
It's better to have it all in one place though, especially if the eventual goal is for a stand alone imager rather than just an interface for other tools.

Re: Another useless data recovery toy?

January 15th, 2025, 5:49

Guys, please point me where to find an actual SMART attributes description. I found the manual from Seagate (Seagate SMART Attribute Specification, March 10, 2011), according to it SMART structure version number must be 0x000A, but my test drive send me 0x0010.

2025-01-15 19-42-50.png

Re: Another useless data recovery toy?

January 15th, 2025, 15:18

Are you looking at the ATA command spec?

https://people.freebsd.org/~imp/asiabsdcon2015/works/d2161r5-ATAATAPI_Command_Set_-_3.pdf (page 285)

There are later versions, but the SMART information would be the same.

This is the NVMe spec:

https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf

Re: Another useless data recovery toy?

January 15th, 2025, 21:23

fzabkar wrote:Are you looking at the ATA command spec?

Nope, you din't understood. I have these docs already. Take a look on page 262 of ATA/ATAPI Command Set 3:
2025-01-16_11-15-10.png

Bytes 0...361 are vendor specific, and these bytes are actually contain SMART atrributes. I need an actual SMART attributes description/specification. The Seagate manual that I have seems to be too old.

Re: Another useless data recovery toy?

January 15th, 2025, 21:46

It appears that you already have this document:

https://t1.daumcdn.net/brunch/service/user/axm/file/zRYOdwPu3OMoKYmBOby1fEEQEbU.pdf

If you are asking for the definition of attribute #n, then there is no standard. Every vendor does it differently, and there is no consistency even between their own models. That why smartmontools has a large database. As for 0x10 versus 0x0A, I seem to recall that WD drives also report a version number of 0x10.

Re: Another useless data recovery toy?

January 15th, 2025, 22:01

I went through this and it seems I only saved one link. I think it is what I used for HDDSuperClone. I remember searching and searching, but I don't remember if I found anything more useful.

https://www.data-medics.com/forum/threa ... ific.1476/

Re: Another useless data recovery toy?

January 15th, 2025, 22:37

fzabkar wrote:As for 0x10 versus 0x0A, I seem to recall that WD drives also report a version number of 0x10.

Yeah, I think the same, it's WD specific.

maximus wrote:I went through this and it seems I only saved one link. I think it is what I used for HDDSuperClone. I remember searching and searching, but I don't remember if I found anything more useful.

Very useful, thanks. But no info about structure: length (byte, word, dword etc) and signed/unsigned. That's what I want to know.

Re: Another useless data recovery toy?

January 15th, 2025, 23:04

aekhv wrote:But no info about structure: length (byte, word, dword etc) and signed/unsigned. That's what I want to know.

You are asking an impossible question. There is no standard for these attributes. Every model is potentially different.

All you can do is to report the 56-bit raw value in hexadecimal format, just as CrystalDiskInfo does. The user should be left to make the appropriate interpretations because it is inevitable that yours will sometimes be wrong.

Why do SMART tools report attributes differently?

https://www.hddoracle.com/viewtopic.php?p=22249#p22249

Re: Another useless data recovery toy?

January 15th, 2025, 23:23

Very useful, thanks. But no info about structure: length (byte, word, dword etc) and signed/unsigned. That's what I want to know.

My best answer would be to always provide the raw data (raw value) so the end user could try to figure it out. The values are often vendor specific and subject to their interpretation.

Re: Another useless data recovery toy?

January 16th, 2025, 0:24

This is just one case (Toshiba MQ01ACF050) which demonstrates why one cannot rely on interpretations of SMART reports by any SMART tool:

https://forums.tomshardware.com/threads/toshiba-mq01acf050-has-high-udma-error-count-c7-and-high-write-error-rate-c8.3823356/#post-23119437

In this case UDMA_CRC_Error_Count is actually a Seek Error Rate attribute, and Multi_Zone_Error_Rate appears to be counting the number of times that the drive switches between serpentine zones. But the user and I did not have the benefit of any documentation. Instead, we worked this out by experimenting.

Re: Another useless data recovery toy?

January 16th, 2025, 7:28

Hooray! S.M.A.R.T. status is implemented. Attributes values are the same as in CrystalDiskInfo.
2025-01-16 21-21-17.png


From this moment MiniAHCI kernel module and QMiniAHCIDevice library are completed. Both placed to my GitHub: https://github.com/aekhv

Re: Another useless data recovery toy?

January 16th, 2025, 8:47

I would report big-endian raw values rather than little-endian. Little-endian would confuse people.

Re: Another useless data recovery toy?

January 16th, 2025, 9:27

in this form, eg raw bytes, i think this order is better. Few systems use BE natively, for those who are consumers of such info it is trivial it is LE.
i also hate when some prog is written to group like 2 or 4 bytes together and it is just the same order as they were, ie LE but looks like a 16 or 32bit number. That's what i would call confusing.
I would omit the colons tho, the numbers look like MAC addresses :D (yeah, those are 6 bytes only)

Re: Another useless data recovery toy?

January 16th, 2025, 14:22

pepe wrote:in this form, eg raw bytes, i think this order is better. Few systems use BE natively, for those who are consumers of such info it is trivial it is LE.

Ordinary people "consume" SMART info. Data recovery people hardly ever use it, I would think. Perhaps the OP could provide an LE/BE toggle -- LE for you and him, and BE for the rest of us. ;-)

Re: Another useless data recovery toy?

January 16th, 2025, 21:47

Relax guys, this is just a basic test application to demonstrate library's features. :roll:

By the way, it's time to think about clone application. The best example for me is PC-3000 Data Extractor, so I'll be moving in that direction.

Re: MiniNVMe and MiniAHCI kernel modules for Linux

January 17th, 2025, 7:37

Dmitry was so kind to rename this topic's name. :D

Re: MiniNVMe and MiniAHCI kernel modules for Linux

January 18th, 2025, 7:14

A little history lesson. Five years ago, in 2020, I already did a simple Parallel ATA reader with clone application. The reader device was based on Arduino DUE (Atmel SAM3X8E chip). Unfortunately it's not supports UltraDMA transfer mode, only PIO mode was available (3 MB/sec max).
arduindo-due-reader-11.jpg

arduindo-due-reader-22.jpg

The clone application was named Easy-Reader. And the video of course:
https://rutube.ru/video/9913748b63d7258da382d27d81e7760c/
https://rutube.ru/video/f75a529e31bdc712a3184fa4959ed009/
https://rutube.ru/video/ba6a718e5811a45304d3be95c785dbaa/

I also experimented a lot with FPGA-based readers, but I was completely disappointed in this. It's too complicated devices. Now the perfect solution has been found: it's a regular AHCI/NVMe controller and the alternative driver.

Re: MiniNVMe and MiniAHCI kernel modules for Linux

March 30th, 2025, 2:22

MiniNVMe driver for Windows? Hm... Actually why not? In progress... 8)
2025-03-30_16-08-36.png

Re: MiniNVMe and MiniAHCI kernel modules for Linux

April 2nd, 2025, 4:51

The Easy Reader seems very impressive.
Are you going to "add" it to the NVME system? Will it also work with regular HDD?

Thanks
Post a reply