Bug 1140791

Summary: incorrect display of SMART attributes.
Product: [Fedora] Fedora Reporter: Przemek Klosowski <przemek>
Component: udisks2Assignee: Michael Catanzaro <mcatanzaro+wrong-account-do-not-cc>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: amigadave, tsmetana, zeenix
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-24 02:02:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1103179    
Bug Blocks:    

Description Przemek Klosowski 2014-09-11 17:15:08 UTC
Description of problem:
The SMART tool incorrectly displays SMART attributes of e.g. SSD disks. 

Version-Release number of selected component (if applicable):
gnome-disk-utility-3.10.0-3.fc20.x86_64


How reproducible: every time


Steps to Reproduce:
1. run gnome-disks
2. select a SSD disk, select SMART Data & Self Tests from the top-left ops menu
3. observe the SMART attributes in the new SMART Data & Self Tests window

Actual results:
170	available-reserved-space
173	attribute-173
174	attribute-174
181	program-fail-count-total
183	runtime-bad-block-total
189	high-fly-writes
202	ta-increase-count
206	flying-height


Expected results:
170	Grown_Failing_Block_Ct
173	Wear_Leveling_Count
174	Unexpect_Power_Loss_Ct
181	Non4k_Aligned_Access
183	SATA_Iface_Downshift
189	Factory_Bad_Block_Ct
202	Perc_Rated_Life_Used
206	Write_Error_Rate

Comment 1 Przemek Klosowski 2014-09-11 17:21:48 UTC
The symptoms are the same as a libatasmart bug 
https://bugzilla.redhat.com/show_bug.cgi?id=1103179

I thought gnome-disks uses libatasmart, but ldd doesn't show it among the shared libraries---maybe it's linked statically. Does it link statically or share code? 

Anyway, the SMART attributes are unfortunately not standardized and the other SMART software, smartmontools, have a whole mechanism to report manufacturer/model specific parameter assignment. I am not sure whether it's better to duplicate it in libatasmart and/or gnome-disks, or rip out the current code and use smartmontools.

Comment 2 David King 2014-09-12 07:39:18 UTC
gnome-disk-utility uses udisks2 via D-Bus, which in turn depends on libatasmart. For feature requests, it is probably better to file a bug report upstream:

https://bugs.freedesktop.org/enter_bug.cgi?product=udisks

Comment 3 Tomáš Bžatek 2014-09-12 13:33:59 UTC
Yes, udisks links libatasmart dynamically:

$ ldd /usr/lib/udisks2/udisksd | grep atasmart
	libatasmart.so.4 => /usr/lib64/libatasmart.so.4 (0x0000003000800000)

Comment 4 Przemek Klosowski 2014-09-12 14:33:20 UTC
This is not really a feature request---I consider this a bug in libatasmart and all tools using it. Originally, when I filed the libatasmart bug report https://bugzilla.redhat.com/show_bug.cgi?id=1103179 I only knew it from skdump tool. Since there is a a correctly functioning alternative, smartctl, and libatasmart development has been stagnant since 2012, I asked libatasmart author Lennart Potterling whether he feels that continuous development is worth the trouble. I understand that he's a busy guy, with systemd and pulseaudio and whatnot, so I wasn't surprised that he doesn't have the bandwidth to continue working on libatasmart.

However, skdump is not the only user of this lib: 
repoquery --whatrequires libatasmart  
reports that it is used in kde-partitionmanager and udisks/udisks2 as well.

I'll file at freedesktop.org as well. Again, the issue is whether to improve SMART parameter handling in libatasmart or retarget udisks/kde-partitionmanger to use smartctl.

Comment 5 Fedora Admin XMLRPC Client 2015-02-26 17:26:34 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Fedora Admin XMLRPC Client 2015-02-26 22:39:24 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Michael Catanzaro 2015-03-24 02:02:23 UTC

*** This bug has been marked as a duplicate of bug 1103179 ***