Mailinglist Archive: opensuse (795 mails)

< Previous Next >
Re: [opensuse] another WD Green AV-GP HD failure [solved]
  • From: "Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>
  • Date: Mon, 6 Nov 2017 00:29:13 +0100 (CET)
  • Message-id: <alpine.LSU.2.21.1711060016070.15643@minas-tirith.valinor>
Hash: SHA256

El 2017-11-05 a las 18:12 -0500, Felix Miata escribió:
Wols Lists composed on 2017-11-05 12:02 (UTC):
Felix Miata wrote:

Earlier in this thread I showed Smartctl reported 131 pending sectors and
reallocated sector count of 0. It's the second of the very same model in
identical service here, the two being manufactured less than 90 days apart. I
consider the old HD junk at this point, and likely most if not all of that model
from that period.

imho you're throwing away a teenager of a drive ... I'll explain why.

Firstly, do you understand what a "pending relocation" is? Yup, that's
at 131, but I'd be far more concerned about that figure if it was the
"reallocated sectors" figure.

Without knowing better, it looks like a quantity of sectors that failed to be
written to.


When a sector fails to be written (the disk firmware probably tries a number of times), the sector is inmediately remapped with a spare. At that point, the disk reports no bad sectors and it writes normally.

That number is the number of sectors that produce an error when read, because that operation does not cause a remap.

Pending relocations say absolutely nothing about the health of the
drive, although they are bad for your data ... all it means is the drive
can no longer read the sector, which could be anything from a stray
cosmic ray, to a tired recording, to a power surge moving the actuator,
to flaking oxide presaging a head crash. Anything.
Lots of sectors on this device hard or impossible to read:

The STB is apparently insufficiently sophisticated to utilize Smart features, or
work through repeated read failures gracefully.

SMART is transparent to the system, it happens internally to the disk without the main system intervention.

What the host can to is interrogate the disk for its health or ask the disk to test itself. And in that hardware it doesn't.

Given that this is the second of exact same model, of less than 3 months
difference in age, that developed a multitude of unreadable sectors in 3 years
or less, in exactly equivalent usage, I have to be suspicious of poor design or
execution at manufacture.

Hard disk manufacture.

Humour me. "dd if=/dev/zero of=/dev/wdgreen". Your pending sectors WILL
go back to zero - trust me. If relocated sectors goes up, then yes that
is cause for concern, but there's every likelihood they will stay at zero.

# date
Sun Nov 5 15:48:14 EST 2017
# dd if=/dev/zero of=/dev/sdb bs=16384
dd: error writing '/dev/sdb': No space left on device
19535702+0 records in
19535701+0 records out
320072933376 bytes (320 GB, 298 GiB) copied, 5324.73 s, 60.1 MB/s
# date
Sun Nov 5 17:45:24 EST 2017
# smartctl -x /dev/sdb | grep -A26 "SMART Attributes Data"
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
1 Raw_Read_Error_Rate POSR-K 200 200 051 - 1986
3 Spin_Up_Time POS--K 157 153 021 - 3150
4 Start_Stop_Count -O--CK 099 099 000 - 1535
5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
7 Seek_Error_Rate -OSR-K 200 200 000 - 0
9 Power_On_Hours -O--CK 072 072 000 - 20916
10 Spin_Retry_Count -O--CK 100 100 000 - 0
11 Calibration_Retry_Count -O--CK 100 100 000 - 0
12 Power_Cycle_Count -O--CK 099 099 000 - 1524
192 Power-Off_Retract_Count -O--CK 200 200 000 - 39
193 Load_Cycle_Count -O--CK 200 200 000 - 1535
194 Temperature_Celsius -O---K 102 084 000 - 41
196 Reallocated_Event_Count -O--CK 200 200 000 - 0
197 Current_Pending_Sector -O--CK 200 198 000 - 0
198 Offline_Uncorrectable ----CK 100 253 000 - 0
199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 1
200 Multi_Zone_Error_Rate ---R-- 100 253 000 - 0
||||||_ K auto-keep
|||||__ C event count
||||___ R error rate
|||____ S speed/performance
||_____ O updated online
|______ P prefailure warning

Current Pending was 198 198 000 - 131

So, maybe it's serviceable somewhere, but the DVDR has been upgraded to 500GB.

Yes, the above is the normal procedure.

You might see the "Reallocated_Sector_Ct" changing - when that number hits the barrier, replace disk as fast as possible, it has no more spare sectors.

The drive cannot correct pending sectors by itself, it needs the
computer to attempt to write to them. If the write is successful, it
clears the error. If the write is unsuccessful, it relocates the sector
elsewhere (which is the point at which you start worrying about the
health of the drive).

In its originally shipped proprietary STB installation state, how would one go
about forcing a write to an already occupied area of unknown and unknowable

You can't. Instead, you zero it out completely as you just did, then replace contents with backup.

- -- Cheers
Carlos E. R.

(from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith))

Version: GnuPG v2

< Previous Next >