Bug 506254
Summary: | Palimpsest reports bad sectors on a good disk | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Miro Hadzhiev <extigyro> |
Component: | libatasmart | Assignee: | Lennart Poettering <lpoetter> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 11 | CC: | james, lpoetter, oded |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-08-05 22:02:32 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Miro Hadzhiev
2009-06-16 12:06:35 UTC
It looks like your disk does have bad sectors (1900724 according to the SMART report), which could well be correct. Not to worry though - hard drives have spare sectors for this purpose and your drive have reallocated the sectors to fresh spares. According to the SMART attributes, your drive is well above the failure threshold: Current value for reallocated-sector-count is 100 with a threshold of 5 - for a failure the current value should be equal or under the threshold. man smartctl and search for "-A". It looks like palimpsest is just trigger happy. This bug is possibly a dup of bug #498115 Hmm, 1900724 is a very high value. If it is true your hard disk is pretty broken and I wouldn't trust it anymore. However, I am assuming that this is probably just a parse failure, so I'll now disable the parsing of that attribute in libatasmart for your disk. I now added a quirk upstream for this: http://git.0pointer.de/?p=libatasmart.git;a=commitdiff;h=4fdaf003a3b7277c1f3aec45d52c362f6aa187bc I don't think this fix is correct - liatasmart should *completely ignore* the real values reported for the purpose of determining if the state of the drive is in error or not. In order to decide if the drive is in failure status, libatasmart should only consult the "Current value" vs. "Threshold", according to the logic described in man smartctl. If the drive considers 1900724 re-allocated sectors is a value of 100 vs a threshold of 5, then libatasmart should not second guess that. I forgot to mention that as I described in comment #47 bug #498115 , libatasmart describes even 1 reallocated sector as a fail status - which is obviously wrong. Adding a quirk for every such case is not the write way to go. We decided that it makes more sense to actually second-guess the drive here. Manufacturers tend to set those threshold artifically high, to make their drives look better. However you are right, checking against 0 is a bit too much. This will be changed to check against a threshold that is dependant on the actual size of the disk. I think that second guessing the manufacturer is not a good idea on the face of it - unless proven that as a rule of thumb implementors of the SMART standard cannot be relied upon to implement it properly, I would think that the default implementation in Linux should be to work with the standard. Baring that this is not likely to happen (and I acknowledge that there may be issues with some drives), I would hope that there would be some switch that allows me to ask libatasmart to honor the standard and the device manufacturer settings, on my machine. (In reply to comment #7) > I think that second guessing the manufacturer is not a good idea on the face of > it - unless proven that as a rule of thumb implementors of the SMART standard > cannot be relied upon to implement it properly, I would think that the default > implementation in Linux should be to work with the standard. Nice idea. However, that doesn't work. For the simple reason that there is no "SMART standard". There is simply no official spec of the SMART attributes stuff. There was a draft spec which was pulled back. Most vendors do follow that but departed from that in many many ways, sometimes in a compatible way, sometimes in an incompatible way. A good part of the information libatasmart parses is not documented anywhere, it's simply something that was observed that all (or some) manufacturars seem to agree on or follow, even if it isn't set in stone. libatasmart tries to make sense of the data available in the SMART information as good as it can. But since there is no official specification we need to take the data that is a available, distill some information from it, verify that it makes sense and then present that to the user. Also note that libatasmart .14 now compares the number of bad sectors against a threshold that depends on the disk size. Ok, thanks for the response. I still think there is room in palimpsest for showing where libatasmart thinks there is a failure while the manufacturer's "current value">"threshold value" says its OK(*) and in such cases allow the user to override the notification for just that property so that it reports failures according the the manufacturer's values. (*) even if these values are stupid, like setting the current value to always 100. |