Wols Lists composed on 2017-11-05 12:02 (UTC):
Felix Miata wrote:
Wols Lists composed on 2017-11-05 09:24 (UTC):
Felix Miata wrote:
Follow-up: I got the new HD installed using the image file created by dd_rhelp. The DVDR's title menu lists all recordings as it listed before, and makes new recordings successfully, but apparently dd_rhelp was more accurate with its 99.99% report than with 100.00%. The recording that the DVDR locked up playing has an 11 second loss/bad spot at the same place.
Yup. So you've saved everything else - good. And that'll now last another 7 years :-
I won't know everything else is good without watching all 100+ hours in real time. :-(
20906 hours powered up equates to only about 2.4 years of constant on.
Was that recording an old one made when the disk was nearly new? If the DVDR couldn't read it, I'm not surprised ddrescue couldn't either. If SMART doesn't report any problems on the drive, it should be safe to format and re-use it - I guess the magnetism on that one block just faded too much over time ...
Had you read the link in the post you replied to you should have noticed the disk would have been far from new when that recording was made, possibly at around 14426 hours or 20 months disk on time. The SD DVDR that the disk is in offers no evidence that it employs Smart technology.
Ah. I see. But even so ...
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.
I had a look at the WD Green spec sheet. It comes with a 2-year warranty, so yes, assuming the drive is used 8 hours a day it's probably well outside its wall-clock warranty, but it's only been powered up just over it.
The drive also is rated at 300K spin-up cycles. If your typical program is 30mins, that means you've used about 40K. Just over one tenth, which is why I describe the drive as a teenager. (And you've probably used rather less. Apparently you missed the OP: https://lists.opensuse.org/opensuse/2017-11/msg00010.html
No need to guess. There is ostensibly only one program, the proprietaryware that uses the disk in its own proprietary manner, with few and generally brief exceptions, constantly recording when powered up. As I have it powered up more often than not, its usage differs little from a surveillance system, biggest difference editing out of commercials. Power cycling is infrequent, while backup and restore are as a practical matter not feasible even though it includes a DVD-RW device. Write back from DVD to HD using the device is only possible via real time (dub) recording. Genuine byte-accurate backup/restore is only possible by removal from the STB and using other equipment.
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: http://fm.no-ip.com/Tmp/Hardware/Disk/Funai/wd3200avvs8180log.txt
The STB is apparently insufficiently sophisticated to utilize Smart features, or work through repeated read failures gracefully. 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.
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: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 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.
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 location? -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org