Bug 498284

More info:
smartctl -a /dev/sda  

No obvious failure in the output associated with ID 197.

Here's the transcribed line for 197:

197 Current_Pending_Secotr 0x0032 100 100 000 Old_age Always - 120173136838658

Is it perhaps that the raw_value is too large for the disk utility and it wraps into a negative number?

let me know if you need more info

-jef

Please include the info requested here

http://www.freedesktop.org/wiki/Software/DeviceKit-disks

Created attachment 341817 [details]
devkit-disks --dump'

Created attachment 341818 [details]
devkit-disks --show-info /dev/sda

Created attachment 341819 [details]
skdump /dev/sda

Created attachment 341820 [details]
gvfs-mount -li  as user

Created attachment 341822 [details]
cat /proc/self/mountinfo

Created attachment 341823 [details]
skdump --save=skdump-output /dev/sda

Let me know if you need anything else.

-jef

Which version of libatasmart is this?

libatasmart-0.12.2.f11.i586

I should change the summary to say F11 preview, I buried that in the more verbose description text.


-jef

Hmm, the power on time libatasmart decodes is 14.8 years. Is that realistic? Probably not, right? Is 4.5 years more realistic? Probably neither?

Are the 493 power cycles realistic?

Hmm, weird beast this drive. Nothing seems to make sense.

Hmm, in my little database of SMART data from weird drives we already have an entry from a FUJITSU MHY2120BH drive, although a different firmware version. And it has completely different attributes. And after some minor fixing on our side they now are properly parsed but apparently need some completely different rules than yours.

Weird, weird, weird.

factory installed on a dell inspiron notebook..about a year old now i think.

-jef

Fixed now in 0.12-3.

https://fedorahosted.org/rel-eng/ticket/1746

This release simply disables decoding of attributes 9, 196, and 197 since those fields seem to be invalidly encoded on your drive.

If you care enough you might want to invest some time in figuring out what exactly happens here, and if it is possible to come to sensible results with slightly different decoding. Attribute 9 probably *is* the power-on time, but somehow strangely encoded. Given that this must be increasing lineraly with wallclock time you might be able to figure out what is going on. Just look at the 'raw data' column of skdump's output and try your luck.

Also note that I have SMART data of another drive of the same model as yours, however with a different firmware version (0084000D instead of 0085000B). Not sure which firmware is the newer one, though (i.e. is B/D or 84/85 what matters?). The other firmware has a lot more attributes which are all decoded correctly. I am thus tempted to say that the the other firmware is newer and you might be able to fix this issues properly by updating your drive's firmware.

Anyway, libatasmart doesn't choke on this anymore, so I am closing the bug. If you find something out about the SMART encoding on your drive you know where you can reach me. ;-)

thanks,

I'll look at flashing the harddrive firmware...i've never had a compelling reason to do that before. It's probably the firmware for sure.

I can only imagine how many other real-world drives have this sort of weirdness.  Generally speaking is this going to be widespread enough that there going to be a need for a hardware specific quirks collection or a way to systematically collect odd failure dumps like mine to figure out which drive/firmware is producing reliable info? 

-jef

libatasmart includes a quirk database. I mostly imported it from smartmontools but it also has a handful of new entries now.

Since we pushed dk-disks into F11 we only had three reported cases where we needed to update the quirk database, including your case. Three cases is not that much I'd say. We'll see how that will change when F11 is released but for now i am quite confident that the amount of quirks necessary won't increase drastically.