The raw value of SMART attribute 9 (Power-on Hours) provides a 4-byte hours count and a milliseconds count in the remaining (3) bytes (Reference: Intel Solid-State Drive 520 Series Specification, February 2012, section 4.5.1). This is the format used by most SandForce based SSDs.On the smartmontools mailing lists we got two reports about 520 Series SSDs which return a very high hours count (894850 hours ~= 102 years). The milliseconds counter wraps around after 3599999ms but the hours count is apparently incremented independently. Is this a known bug? The Power-on Hours count from Device Statistics (Log address 0x04, page 1, offset 0x010) provides a reasonable value: smartctl -i -A -l devstat /dev/sdc smartctl 5.43 2012-03-22 r3525 [i686-linux-3.3.0] (local build) ... Model Family: Intel 520 Series SSDs Device Model: INTEL SSDSC2CW120A3 Firmware Version: 400i User Capacity: 120,034,123,776 bytes [120 GB] ... ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH ... RAW_VALUE ... 9 Power_On_Hours_and_Msec 0x0032 000 000 000 ... 894850h+42m+26.330s ... Device Statistics (GP Log 0x04) Page Offset Size Value Description ... 1 0x010 4 56 Power-on Hours...
The value you are referring to as hours, 894850, is the raw data for attribute 09. My two 520's show SMART attribute 09 values of 894962, and 894896 as the raw values displayed in the Intel SSD Toolbox. If you check the Anandtech review of the 520, you can find a picture of the SMART attributes shown in the Toolbox, with the same raw value for attribute 09 that you mentioned, 894850. That value seems to be the initial, brand new 520, SMART data in the 09 attribute field.
Since these values are raw data, which are supposed to have the format that you mentioned (although your description does not quite match what I read in the 520 specification document), it looks like smartctl is reading the raw data value, and printing it as if it were the true, parsed/processed hour count, without any interpretation, although it appears in the Raw Data column, but has hours, minutes, etc. labels. Rather confusing IMO.
IMO, the format of the raw data of attribute 09 is not fully defined, and does not seem to fit the description given in the specs. Or Intel is doing something else with this data.
Given how long I've used my two 520's, which I installed a few weeks apart, and looking at my data and what seems to be the initial value of 894850, a simple interpretation (and pure guess) looks like this: 894962 - 894850 = 112, and 894896 - 894850 = 46. Those differences would be reasonable as Power-On Hour Counts for my 520's, which I have not used very long (I shutdown that PC daily and don't use it every day.) Still, just a guess on my part.
But that does not match what you get in the Device Statistics Log data, which is 56 hours, which would be 0 hours by my interpretation of the raw data.
I don't have smartmontools on my 520 PC, but I'll run smartctl soon to see what I get for my hour counts in the Dev Stats Log data.
1. From SandForce SMART Spec, July 2010, Table 1:0x09: Power-On Hours: Raw Usage: [3-0]: total number of power-on hours [6-4]: total number of milliseconds since last hour update 2. From Intel 520 Spec, February 2012, Table 11: 09h: Power-On Hours Count: The raw value reports two values: the first 4 bytes report the cumulative number of power-on hours over the life of the device, the remaining bytes report the number of milliseconds since the last hour increment. Both IMO describe the same format. Therefore I decided to use the SandForce attribute 9 print format also in the smartmontools drive database entry for Intel 520 (You could override this with smartctl -v or -P option, see man page.) The actual 520 firmware apparently adds a huge value to the hours count. This IMO violates the above specification.
Is this intentional?