From: David Eriksson <twogood@us...>  20030207 11:52:01

On Fri, 20030207 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 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!] 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 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... I did some very quick analysis: It seems like you only printed 32bit values in your list, not 48bit or 64bit? Anyway, the 32bit values seem to be two 16bit values. Some times the first (higher) 16bits 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 