From: David E. <tw...@us...> - 2003-02-06 14:37:41
|
Hello! Thanks for improving the smartsuite! 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. 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.1-4. A similar difference in the Spin_Up_Time value between smartsuite and smartmontools was observed on an IBM 30 GB drive (IBM-DTLA-307030). -- Regards, -\- David Eriksson -/- SynCE - http://synce.sourceforge.net CalcEm - http://calcem.sourceforge.net Desquirr - http://desquirr.sourceforge.net SetiWrapper - http://setiwrapper.sourceforge.net |
From: Bruce A. <ba...@gr...> - 2003-02-07 05:01:35
Attachments:
crap3
|
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 two-byte 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.1-4. > > A similar difference in the Spin_Up_Time value between smartsuite and > smartmontools was observed on an IBM 30 GB drive (IBM-DTLA-307030). 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 4-byte quantity, losing the top two bytes! In your case, the actual value of the 6-byte 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 vendor-specific -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 |
From: David E. <tw...@us...> - 2003-02-07 11:52:01
|
On Fri, 2003-02-07 at 06:01, Bruce Allen wrote: > 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 4-byte quantity, losing the top two bytes! > > In your case, the actual value of the 6-byte 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!] Nice collection! :-) > 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 vendor-specific -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... I did some very quick analysis: It seems like you only printed 32-bit values in your list, not 48-bit or 64-bit? Anyway, the 32-bit values seem to be two 16-bit values. Some times the first (higher) 16-bits are 0, but otherwise the two values in each pair are pretty close to each other. -- Regards, -\- David Eriksson -/- SynCE - http://synce.sourceforge.net CalcEm - http://calcem.sourceforge.net Desquirr - http://desquirr.sourceforge.net SetiWrapper - http://setiwrapper.sourceforge.net |
From: Bruce A. <ba...@gr...> - 2003-02-08 09:56:19
Attachments:
spinup
|
> I did some very quick analysis: > > It seems like you only printed 32-bit values in your list, not 48-bit or > 64-bit? Ooops! You are 100% correct. I used a version of smartctl which (according to smarctl -V) had version 1.44 of ataprint.c rather than the necessary version 1.45 or above. I've taken the data set again. See the attached file. If you can make sense of how to interpret the numbers, let me know and I'll add a vendor-specific option for this. Cheers, Bruce |
From: Bruce A. <ba...@gr...> - 2003-02-08 10:08:07
Attachments:
spinup2
|
> > I did some very quick analysis: > > > > It seems like you only printed 32-bit values in your list, not 48-bit or > > 64-bit? > > Ooops! You are 100% correct. > > I used a version of smartctl which (according to smarctl -V) had version > 1.44 of ataprint.c rather than the necessary version 1.45 or above. > > I've taken the data set again. See the attached file. If you can make > sense of how to interpret the numbers, let me know and I'll add a > vendor-specific option for this. Ummm, I am not doing things very well these days. By accident I included the output from four GXP120 disks that we had been testing, as well as the GXP180 disks. I've removed those four lines in what is attached. I've also sorted it by raw value. Let me know if you can make sense of it... Bruce |