Description of problem: Using preview image, disk applet tells me my harddrive is failing due to bad sectors. Clicking details and I find the failing item to be: ID: 197 Attribute: Current Pending Sector Count Current: 100 Worst: 100 Threshold: 0 Value: -48103422 Sectors Status: FAILING Type: Old-age Updates: Online It looks like a bogus number to me. Version-Release number of selected component (if applicable): gnome-disk-utility-0.3-0.5.20090415git.f11.i586 How reproducible: Use preview desktop livecd Additional info: The drive is a 120 GB ATA Fujitsu MHY2120B according to the utility. I'm going to boot back into F9 and see if smartctl under f9 gives the same info. -jef
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.