Hi David,
> Thanks for improving the smartsuite!
Thank you for the kind comment.
> I just bought an 180GB IBM 180GXP, and found smartmontools while I was
> wondering my my temperature was shown way off any reasonable value by
> smartsuite.
Ah, yes.
It was fun to reverse engineer this. Three twobyte numbers crammed into
six bytes  actual temperature, along with min and max temperatures.
> Smartmontools solved that problem for me, but instead I get a very
> large value for Spin_Up_Time. I'm not even sure what that attribute
> means, but I assume that one of the values is wrong!
>
> I have attached output given by smartctl from smartsuite 2.1 and from
> smartmontools 5.14.
>
> A similar difference in the Spin_Up_Time value between smartsuite and
> smartmontools was observed on an IBM 30 GB drive (IBMDTLA307030).
I hadn't noticed this  thank you for calling it to my attention.
Anyway, first, let me explain why smartsuite and smartmontools
disagree. Smartsuite has an error: it contains:
long long rawvalue;
for (j = 0 ; j < 6 ; j++) {
rawvalue = data.vendor_attributes[i].raw[j] << (8*j) ;
}
printf ("%u\n", (unsigned int)rawvalue);
The first four lines are correct: they combine the six bytes of vendor
data to make an 8 byte integer (a long long). The last line is incorrect:
it prints this as a 4byte quantity, losing the top two bytes!
In your case, the actual value of the 6byte object is correctly given by
smartmontools. It is
30064771389 (base 10) = 11100000000000000000000000100111101 (base 2)
Note that in the base 2 representation, if we print out only the final
four bytes
100111101 (base 2) = 317
[the actual value that smartsuite gives is 319. The raw value probably
changed by two between the two measurements.]
Now, onto the solution. I am interested in this because I own 300 of
these disks (GXP180, 120GB version) and have root access to 300 others.
[These are not typos: the merlin cluster in Berlin has 300 of these disks
and this weekend we are adding 300 of them to the medusa cluster in
Milwaukee!]
So for fun I printed the raw values in base 10 and base 2 for 293 of the
disks. I've attached the text file to my email.
If you can figure out the pattern (ie, what it means) I'll be glad to add
a vendorspecific v option to smartctl. I've got to work on some other
stuff right now, but I'll take a good look at the numbers when I have a
chance and see if I can figure out the pattern.
I may just add an option to smartsuite to mask out either the bottom two
or bottom four bytes. This would also allow one to drop the top bytes 
though I would really like to know what they mean...
Cheers,
Bruce
