This message is from the T13 list server.
Dan;
I like your idea of the new environmental SMART extension. My first thoughts
would be to try to come up with a way to not have to have the new "environmental
driver" to have to always poll for status. What about thinking of a way to tell
the system at the end of every disk operation that the environmental status
needs to be checked. I am thinking along the line similar to the error bit. When
status is read, if an error condition exists, then this bit is set and the
system has to do the appropriate recovery routine. I haven't checked every
command, bit it looks like for most, the status byte has bits 1 and 2 listed as
NA, so we might want to consider using them to let the driver know it needs to
check for some type of environmental problem.
Also, is there any thoughts for pressure? I know drives have a limit as to the
altitude that they can operate in, so in theory, we might have a pressure sensor
also to tell that there is a problem here as well as temperature and vibration.
Rick Kalish
"Daniel J Colegrove" <[EMAIL PROTECTED]> on 04/18/2002 05:48:27 PM
To: [EMAIL PROTECTED]
cc: (bcc: Richard Kalish/ALI_SJC/ACER)
Subject: [t13] SMART Temp and Vib Problem Notification
(Something to think about before next week's
meeting)
This message is from the T13 list server.
Dear T13 Reflector Members:
Devices are being equipped with sensors and software to detect
external conditions that may be causing device problems such as high
or low temperatures or excess vibration. These new sensors will be
used only if there is a standard way to report a correctable condition.
It would seem to make sense to add the ability to report temporary
conditions to the SMART Return Status command. Unfortunately the
design of the SMART Return Status command does not lend itself to
extension. If there is no error a specific two byte code is returned in
the LBA Mid and LBA High registers. If failure is predicted a different
two byte code is returned. The other registers are marked na, not
reserved. Adding a new return code has the potential of confusing
existing SMART software, which is expecting only the two codes defined
today. Using the other registers is probably not a good idea either as
they are NA, not reserved, so there is no guarantee of their value in
existing drives.
My conclusion is that we need a new SMART Return Status
Extended command that has a bit for Failure Predicted and one (or more)
for
Environmental Condition Notification. Existing SMART software would
continue to use the current SMART Return Status command but new
software, which has to poll anyway, could check for both failure
prediction and an environmental condition with the same poll using
the new extended command.
The next question is how to report what environmental condition is
out of operational range. The data could be sent back with SMART
Return Status Extended, but the data would be limited to what we
could put in registers. It could be returned as a group of SMART
Attributes but I think that it would be better to do it as a new log page
in Read Log Extended. Today I have heard of only three conditions
that need to be reported, hot, cold and vibration so the problem
indication can go in any of these methods.
As usual, we need an Identify data bit to indicate that SMART Return
Status Extended is supported. I see no reason to enable or disable
the environmental reporting.
I am working on a proposal document that I hope to have for
next week's meeting. Please let me know what you think about how
devices should report environmental conditions.
Best Regards,
Dan Colegrove
[EMAIL PROTECTED]
Senior Technical Staff Member
Storage Technology Division
IBM Corporation
702-614-6119
702-614-7955 fax
