Re: Which attributes can estimate number of bad blocks?

[email protected] Mon, 1 Aug 2016 15:42:26 -0400
Newsgroups gmane.linux.utilities.smartmontools
Message-ID <[email protected]>
If you ASSUME that pending sectors are bad, then yes, add reallocated and
pending. Generally though, if there are only 1 or 2, they are not bad.

I wouldn't add 187 and 198, as they can indicate unrelated problems.

> Thank you for explaining that a current pending sector isn't always going
> to be reallocated by the drive.  I don't see how soft error differs from
> bad sector though.  Also a medium error is a bad sector but the drive
> thinks a write fixed the sector.
>
> However, you didn't address my question.  I'm trying to estimate the
> number of sectors already found to be bad.  I was adding the raw value of
> attributes 5 and 197 to get a quick estimate.  My question is whether to
> add raw values of attributes 187 and 198 as well, or are these redundant
> (already included in) attributes 5 and 197?
>
> If the estimated number is below some psychological limit (not set by me)
> then I proceed to more intensive testing.  If the estimate is over the
> psychological limit then the drive can be assigned to scrap without
> needing any further testing.  So I'm trying to make a reasonable estimate.
>
>
> ----- Original Message -----
>>From: "[email protected]" <[email protected]>
>>To: Norman Diamond <[email protected]>
>>Cc: "[email protected]"
>> <[email protected]>
>>Date: 2016/7/28, Thu 23:34
>>Subject: Re: [smartmontools-support] Which attributes can estimate
>> number  of bad blocks?
>>  
>>Current Pending Sector can indicate one of 3 things [on platter drives]:
>>
>>* A bad sector that hasn't been reallocated yet, i.e. written to (a hard
>>error).
>>* A soft error. One or 2 sectors might indicate this problem. Every drive
>>I've seen so far with 8+ turned out to be a bad drive.
>>* The most insidious of all, a medium error. The sector can't hold it's
>>charge, for long. You can write to it then immediately read from it OK,
>>but usually in less than an hour, it goes corrupt again. You'll see that
>>in the same sector(s) keeps failing. This is a drive you should trash.
>>
>>It sounds like you have a drive with medium error(s).
>>
>>As for trashing a drive, it varies depending on who you ask, but at 5+
>>(raw value) reallocated, I trash. At 8+ Pending, I trash.
>>
>>In regards to 187 and 197, I will retire a drive with any raw value more
>>than 0. But this is based more on Backblaze's published results than my
>>own observations. Usually I don't see those, or the drive is already
>>failing based on Reallocated and Pending.
>>
>>> To get a quick estimate of the number of bad blocks that have already
>>> been
>>> detected, I add the raw values of attributes 5 (Reallocated_Sector_Ct)
>>> and
>>> 197 (Current_Pending_Sector).
>>>
>>> Should I also add the raw values of attributes 187 (Reported_Uncorrect)
>>> and 198 (Offline_Uncorrectable)?  Or are these redundant, already
>>> included
>>> in attributes 5 and 197?
>>>
>>> Are there others that I should add?
>>>
>>> Of course this estimate isn't as reliable as ... well actually, other
>>> methods of testing aren't particularly reliable either[*].  Anyway the
>>> reason for getting a quick estimate is that if we know quickly that a
>>> drive belongs on the scrap heap, it saves time.
>>>
>>> [* I have a drive with particularly bad firmware.  Reading the entire
>>> drive causes Current_Pending_Sector to increase.  Writing the bad
>>> sectors
>>> doesn't cause Reallocated_Sector_Ct to increase but does cause
>>> Current_Pending_Sector to go down to 0.  I guess the drive thinks that
>>> a
>>> write operation fixed the sector so the sector doesn't need
>>> reallocation,
>>> but the next attempt to read shows that the sector didn't get fixed. 
>>> If
>>> the drive were in warranty, I might not have it any more :-) ]
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Smartmontools-support mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/smartmontools-support
>>>
>>
>>
>>
>>
>>  
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Smartmontools-support mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/smartmontools-support
>



------------------------------------------------------------------------------