Get S.M.A.R.T. information on external USB hard drive

[Dan Lenski]

Interesting. A short look at all my enclosures shows that
- Cutie 2.5" case (0x067b/0x2507): supported - Revoltec Alu Book Ed. 2
(0x04fc/0x0x15): supported - Agrosy HD360U-P (0x0840/0x0098): not
listed, i.e. unknown - Jou Jye Venus DS3 (0x152d/0x2336): supported -
WD Elements 1TB (0x1058/0x1001): supported

4/5 supported and 1/5 unknown according to their list. Not bad.

Lucky you! One of my 2.5" enclosures is unknown (Moai M110E chip) and the
other is apparently "impossible" (Alcor AU6390). I've looked at the data
sheets for both, and there's no mention of any ATA passthrough.

You'll probably get more info on your unknown enclosure if you look at
what chip it uses.

The problem here is that you basically need a new implementation for
each chipset. Takes time and is annoying. Hopefully vendors will move to
the now-defined passthrough standard soon.

Yes, indeed. Though I've looked at the code for the Cypress chips, and
it's extremely straightforward. So *if* you can get the necessary docs,
it should be very easy to add support for other enclosures that support
passthrough.

Dan

 

[Squeeze]

Arno Wagner wrote in news:[email protected]

Interesting. A short look at all my enclosures shows that
- Cutie 2.5" case (0x067b/0x2507): supported
- Revoltec Alu Book Ed. 2 (0x04fc/0x0x15): supported
- Agrosy HD360U-P (0x0840/0x0098): not listed, i.e. unknown
- Jou Jye Venus DS3 (0x152d/0x2336): supported
- WD Elements 1TB (0x1058/0x1001): supported

4/5 supported and 1/5 unknown according to their list. Not bad.

And nicely shows what a clueless idiot you are and always have been, babblebot.

In addition there is a lot of good and honest SMART information on
their pages. They do "get" it, including that for useful disk
healt assessment you have to look at the raw attributes.

This looks like a pretty good product for a very reasonable price.
I think we should recommend this to anybody looking for something
commercial under Windows (that may also work with USB in many cases)
in the future.

As long as it supports USB passthrough is doesn't need to.

 

[Squeeze]

Dan Lenski wrote in news[email protected]

Hi all,

Here is a page that claims to list all known USB-to-IDE bridge devices,
and whether or not it is possible to transport SMART data over them:
http://www.hdsentinel.com/usbharddisks.php (from the makers of "Hard Disk
Sentinel" software).

Of course, as others have pointed out, this relies on non-standard
extensions of the USB mass storage protocol,

since the official standard does /not/ support SMART-over-USB.

Yes it does.
The problem is whether the driver will allow using whatever the solution is.
The same problem exist with IDE drivers. Some support passing SMART
commands, others do not by lacking necessary the hookup points for the
SMART driver extensions.

 

[Squeeze]

Arno Wagner wrote in news:[email protected]

As there is no standardized vau to transport SMART over USB,

There isn't either for transport SMART over IDE adapters/controllers.

 

[Eric Gisin]

Arno Wagner wrote in news:[email protected]


There isn't either for transport SMART over IDE adapters/controllers.

FolkNazi does it again! The SMART IOCTL was there 10 years ago.

 

[Daniel Lenski]

Yes it does.
The problem is whether the driver will allow using whatever the solution
is. The same problem exist with IDE drivers. Some support passing SMART
commands, others do not by lacking necessary the hookup points for the
SMART driver extensions.

I'm not sure if I understand what you're getting at, but...

I was simply stating that the USB Mass Storage Class standards document
(http://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf) does
*not* explicitly require or specify any mechanism for performing SMART on
a device.

If some particular USB-to-IDE bridge supports pass-through, this is *not*
thanks to the standard, but because of a vendor extension.

Some USB-to-IDE bridge chips simply *do not* have any documented pass-
through capabilities, and this is perfectly compliant with the standard
unfortunately. (And I'm not sure what drivers have to do with it
either... of course it's possible to write a driver that doesn't
implement the full capabilities of the device.)

Dan

 

[Squeeze]

Eric Gisin wrote in news:[email protected]

FolkNazi does it again! The SMART IOCTL was there 10 years ago.

"The SMART system is a technology that monitors and predicts device performance. The SMART IOCTL API specification version 1.1 or
later, published by Compaq Computer Corporation and Microsoft Corporation, describes the API used by a program to issue SMART
commands to an IDE drive in Windows 98. In Windows, the API is implemented in a vendor-specific driver named Smartvsd.vxd"

IOW,
No provision for Smartvsd.vxd in the IDE driver, No SMART information.

Thank you, Gisin Newbie.

 

[Squeeze]

changed encoding of message to western european.

Daniel Lenski wrote in news[email protected]

I'm not sure if I understand what you're getting at, but...

So maybe you better refrain from answering until you do.

USB allows encapsulating any data you want.
There isn't much need for that if there is no means of doing that
from the software aspect. Then all you need to do is incorporate
that call in one of your own that encapsulates the SMART command.

I was simply stating that the USB Mass Storage Class standards document
(http://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf) does
*not* explicitly require or specify any mechanism for performing SMART on
a device.

No, that is what you are saying now. That's not what you said before.

If some particular USB-to-IDE bridge supports pass-through, this is *not*
thanks to the standard, but because of a vendor extension.

Yes, the physical capability and a driver extension module supplying the
necessary call for SMART software to use.

Some USB-to-IDE bridge chips simply *do not* have any documented pass-
through capabilities,

Which is of no help without the necessary software calls, if they did.

and this is perfectly compliant with the standard unfortunately.

(And I'm not sure what drivers have to do with it either...

The driver has to support the call that transfers SMART data.

No such call, no such access, that simple.
That's why Cypress supply their own Mass Storage driver.

of course it's possible to write a driver that doesn't
implement the full capabilities of the device.)

Which covers most all drivers.

 

[Arno Wagner]

I'm not sure if I understand what you're getting at, but...

I was simply stating that the USB Mass Storage Class standards document
(http://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf) does
*not* explicitly require or specify any mechanism for performing SMART on
a device.

If some particular USB-to-IDE bridge supports pass-through, this is *not*
thanks to the standard, but because of a vendor extension.

Some USB-to-IDE bridge chips simply *do not* have any documented pass-
through capabilities, and this is perfectly compliant with the standard
unfortunately. (And I'm not sure what drivers have to do with it
either... of course it's possible to write a driver that doesn't
implement the full capabilities of the device.)

Ignore "Squeeze". He has no clue what he is talking about.

Arno

 

[Odie]

Arno Wagner wrote in news:[email protected]

Ignore "Squeeze". He has no clue what he is talking about.

Yes, please do.
Squeeze and Folkert Rienstra have consistently said that it is possible
to do SMART over USB in theory. Obviously they have no clue.

Arno Wagner on the other hand said that it wasn't possible at all.
Then he said it was possible with some chipsets.
Then he said that most drives he owns even support it.

Obviously Arno Wagner is the best source for your information.
Long live Arno Wagner.

 

[Arno Wagner]

Arno Wagner wrote in news:[email protected]

Yes, please do.
Squeeze and Folkert Rienstra have consistently said that it is possible
to do SMART over USB in theory. Obviously they have no clue.

Arno Wagner on the other hand said that it wasn't possible at all.
Then he said it was possible with some chipsets.
Then he said that most drives he owns even support it.

Obviously Arno Wagner is the best source for your information.
Long live Arno Wagner.

And another truely pathetic faked posting by somebody that
nobody listens to anymore. This is not Odie.

Incidentially the whole discussion is about standardized ways,
not vendor extensions. Something consistently ignored by said
incompetents.

Arno

 

[Jesco Lincke]

Arno Wagner wrote in news:[email protected]


Yes, please do.
Squeeze and Folkert Rienstra have consistently said that it is possible
to do SMART over USB in theory. Obviously they have no clue.

Arno Wagner on the other hand said that it wasn't possible at all.
Then he said it was possible with some chipsets.
Then he said that most drives he owns even support it.

Obviously Arno Wagner is the best source for your information.
Long live Arno Wagner.

And obviously some people prefer bashing other people's information (via
multiple aliases) over providing anything useful themselves...

 

[Dan Lenski]

So maybe you better refrain from answering until you do.

Communicating one's opinion is usually seen as a good way to achieve
mutual understanding.

USB allows encapsulating any data you want. There isn't much need for
that if there is no means of doing that from the software aspect. Then
all you need to do is incorporate that call in one of your own that
encapsulates the SMART command.

I'm well aware of that. There is a big difference between *allowing* any
data, and *mandating* proper handling of a specific type of data.

No, that is what you are saying now. That's not what you said before.

Okay, I think you're quibbling about the word "support". What I stated
before was (quote): "the official standard does /not/ support SMART-over-
USB"

You're right, I should have said, "the official standard does /not/
require or specify SMART-over-USB". Happier now?

Which is of no help without the necessary software calls, if they did.

Well, I have the software skills, so I'd be much happier if the hardware I
own supported it.

The driver has to support the call that transfers SMART data.

No such call, no such access, that simple. That's why Cypress supply
their own Mass Storage driver.

Interesting. I haven't looked too much at how SMART support works under
Windows. Under Linux, all UMS devices use the same driver, and there's a
user-space API to issue arbitrary SCSI-encapsulated commands to the
devices, which can be used for pass-through or other vendor extensions.
(For example, I have a digital camera that can be controlled through USB
using some vendor extensions on top of the UMS driver.)

Dan

 

[Squeeze]

Jesco Lincke wrote in news:[email protected]

And obviously some people prefer bashing other people's information (via
multiple aliases) over providing anything useful themselves...

Which of course becomes a self fulfilling prophecy when people like your
self use extensive killfiles to prevent "anything useful" filtering through.

Btw, someone finally says something nice about Arno Wagner and not even
a Wagner shill like yourself believe him. What has the world become to.

 

[Squeeze]

Dan Lenski wrote in news:[email protected]

Communicating one's opinion is usually seen as a good way to achieve
mutual understanding.

Responding without having a clue to what you are responding to, isn't.

I'm well aware of that.

Which didn't exactly show through in your response.

There is a big difference between *allowing* any data, and
*mandating* proper handling of a specific type of data.

That's what you have error handling for.

Okay, I think you're quibbling about the word "support".

That in combination with the word "Standard".

What I stated before was (quote): "the official standard does /not/ support SMART-over-USB"

You're right, I should have said, "the official standard does /not/
require or specify SMART-over-USB". Happier now?

Just a little. The problem is with "standard". There isn't just one standard,
there are many. So when you say Standard and USB in one sentence you say
"USB standard". The USB standard doesn't exclude SMART over USB.

Supposedly when you said "the standard" you meant to say "that standard".
'That' being the document describing the minimum capabilities of a Mass Storage driver and Firmware capabilities of a Mass Storage
Device.
Unfortunately I see very little of that in the document that you (presumably) refer to: usbmassbulk_10.pdf. Perhaps I missed it.

Well, I have the software skills, so I'd be much happier if the hardware I
own supported it.


Interesting. I haven't looked too much at how SMART support works under
Windows. Under Linux, all UMS devices use the same driver, and there's a
user-space API to issue arbitrary SCSI-encapsulated commands to the
devices, which can be used for pass-through or other vendor extensions.

Right, your drivers support that API.
Without such support that API goes nowhere.

 

[Dan Lenski]

Dan Lenski wrote in news:[email protected]

Responding without having a clue to what you are responding to, isn't.

Well we seem to have cleared up the issue, right? So I don't see a
problem.

That in combination with the word "Standard".


Just a little. The problem is with "standard". There isn't just one
standard, there are many. So when you say Standard and USB in one
sentence you say "USB standard". The USB standard doesn't exclude SMART
over USB.

Again, I didn't intend to state that anything was excluded... only to
specify the /minimum capabilities required/ by the UMS standards document.

Supposedly when you said "the standard" you meant to say "that
standard". 'That' being the document describing the minimum capabilities
of a Mass Storage driver and Firmware capabilities of a Mass Storage
Device.

From the context of my original post, I think it was quite clear that I
was referring to the same standard as in the previous sentence.

Unfortunately I see very little of that in the document that you
(presumably) refer to: usbmassbulk_10.pdf. Perhaps I missed it.

The document describes in detail the binary protocol for communication
with a UMS device. And it specifies the particular command set,
encapsulated within that protocol, that a device must support in order to
comply with the standard.

Furthermore, the document does not require--but neither does it exclude--
the possibility that a UMS device may support additional commands or
interfaces, such as might be used to implement ATA passthrough.

What's there to miss?

(And I never mentioned firmware. By which I assume you mean "a program
executed by a microcontroller in the USB device.")

Right, your drivers support that API. Without such support that API goes
nowhere.

Agreed.

Dan

 

[Squeeze]

Dan Lenski wrote in news:[email protected]

Well we seem to have cleared up the issue, right? So I don't see a
problem.

We'll see.

Again, I didn't intend to state that anything was excluded... only to
specify the /minimum capabilities required/ by the UMS standards document.

You are repeating yourself.

From the context of my original post, I think it was quite clear that
I was referring to the same standard as in the previous sentence.

To you. Not to me apparently and I am your audience, not just you yourself.

The document describes in detail the binary protocol for communication
with a UMS device.

I believe that that could be somewhat accurate.

And it specifies the particular command set, encapsulated within that
protocol, that a device must support in order to comply with the standard.

I'm sorry, but I can't find it.

Furthermore, the document does not require--but neither does it exclude--
the possibility that a UMS device may support additional commands
or interfaces, such as might be used to implement ATA passthrough.

What's there to miss?

Well, you tell me.
I'm looking for that elusive command set that by omission shows that
SMART is not supported. It's not there. There is no mention of it.
By that token you can say that either everything is supported or nothing
is supported.

(And I never mentioned firmware. By which I assume you mean "a program
executed by a microcontroller in the USB device.")

So you didn't, so what?