[opensuse] another WD Green AV-GP HD failure
Last I reported one of these was for a 2TB model in August 2017. This one is a 320GB model WD3200AVVS shipped in a DVDR manufactured in 2011, the exact same model I had fail in a sister DVDR 3 years ago. The HD check function of the DVDR reported HD hours in use >20000. The HD was manufactured a month before the DVR, so both are more than 5 years old. When DVDR is powered up and not intentionally recording, it constantly buffers up to the last 6 hours of the currently tuned channel or input source for replay or permanent saving. These DVRDs use the HD in a proprietary manner, so backup and restore like we do with PC files is not possible. It can write to/from DVD, but only in real time, which makes backup and restore impractical other than by removing the disk from the DVDR and imaging it, useless for anything saved since making the last image. The DVDR froze trying to play a recording, so I shut it down, pulled the HD out, and made an image of it thus: ddrescue -d /dev/sdc dvdrfile.img dvdrfile.logfile Rescued size while running was 10MB less than total size. Average rate was 49894kB/s. Errsize: 67072B. Errors: 81. Rescued: 320072MB. ipos/opos 314588MB. Runtime: 106min. The man page, like most man pages, is minimalist WRT examples. https://www.linux.com/learn/intro-to-linux/2017/3/gnu-ddrescue-best-damaged-... like https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html suggests 3 retries. I tried again adding -r5, but errsize only improved by 3 X 512. Should I try again using -r12 or more, or with other options? Or with dc3dd, or something else? Should I try again after dropping its temperature in the refrigerator or freezer? Is more improvement pointless to hope for? Excerpt from smartctl -x: 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 - 906 3 Spin_Up_Time POS--K 154 153 021 - 3266 4 Start_Stop_Count -O--CK 099 099 000 - 1529 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 - 20906 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 - 1518 192 Power-Off_Retract_Count -O--CK 200 200 000 - 39 193 Load_Cycle_Count -O--CK 200 200 000 - 1529 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 198 198 000 - 131 198 Offline_Uncorrectable ----CK 100 253 000 - 0 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 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 -- "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
Hello, On Wed, 01 Nov 2017, Felix Miata wrote:
The DVDR froze trying to play a recording, so I shut it down, pulled the HD out, and made an image of it thus:
ddrescue -d /dev/sdc dvdrfile.img dvdrfile.logfile
Rescued size while running was 10MB less than total size.
You probably misread the output ;) If you watch progress, you'll see ipos/opos starts at the start of the defect(s), tries to read, and then skips what was already read. If you have e.g. some "special" DVDs with (simulated) defects at the start, then ddrescue tries at the start, skips ahead, reads the rest of the disk, retries at the start, and ipos/opos might end up at 20MB when done. When 6678MB of 6679MB were read successfully. BTDT.
Average rate was 49894kB/s. Errsize: 67072B. Errors: 81. Rescued: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that's what counts 320072MB. ipos/opos 314588MB. Runtime: 106min.
[REORDERED]
Excerpt from smartctl -x: 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 - 906 3 Spin_Up_Time POS--K 154 153 021 - 3266 4 Start_Stop_Count -O--CK 099 099 000 - 1529 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 - 20906 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 - 1518 192 Power-Off_Retract_Count -O--CK 200 200 000 - 39 193 Load_Cycle_Count -O--CK 200 200 000 - 1529 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 198 198 000 - 131 ^^^ That looks quite fine besides the "Current Pending". And: 131*512 = 67072 Bytes = 65.5kB. Matches.
[REORDERED]
Should I try again using -r12 or more, or with other options? Or with dc3dd, or something else? Should I try again after dropping its temperature in the refrigerator or freezer? Is more improvement pointless to hope for?
You can try... But as the disk has flagged 131 sectors as bad (but pending to be mapped out as defect -> Reallocated), I doubt you'll get more off that disk. You're missing 65.5kB. You decide. HTH, -dnh -- "I treat shops as military objectives to be penetrated and stripped of needed resources in as little time as possible. She has adventures in them." -- Joe Thompson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-11-01 at 02:50 -0400, Felix Miata wrote:
The DVDR froze trying to play a recording, so I shut it down, pulled the HD out, and made an image of it thus:
ddrescue -d /dev/sdc dvdrfile.img dvdrfile.logfile
Rescued size while running was 10MB less than total size. Average rate was 49894kB/s. Errsize: 67072B. Errors: 81. Rescued: 320072MB. ipos/opos 314588MB. Runtime: 106min.
If you try "dd_rhelp" instead you will see that it takes about the same time to copy, then (usually) try the bad areas for more time, perhaps hours, till you abort it. Just in the hope that it may work once. Probably a waste of time, just accept that you lost data and move on.
Excerpt from smartctl -x: SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE
197 Current_Pending_Sector -O--CK 198 198 000 - 131
Well, that's the big issue. You have at least 131 bad sectors, known to the disk firmware. If you find out their LBA you can zero them, which causes remapping with good spare records, and the disk would work again for some time. You could try "badblocks" on it (a very slow operation) to find out the LBA. It may trigger the remapping on its own. Then you could copy that disk to a new disk of same size and insert the new one on the machine... I would also google to see if someone has found a method to extract the recordings out of the machine. Mine uses Linux, and people made alternative firmware that adds a web page that allows downloading of recordings to a computer. In any case, my disk is formatted ext2 and is external (typically FAT). - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAln5xxUACgkQtTMYHG2NR9VgdQCeLmLLe5vvJm927ZjGE8OoTEC2 LEcAn0CYMu5jp+g71wmef72EQR2se86q =bYuN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/11/17 13:07, Carlos E. R. wrote:
You have at least 131 bad sectors, known to the disk firmware. If you find out their LBA you can zero them, which causes remapping with good spare records, and the disk would work again for some time.
You could try "badblocks" on it (a very slow operation) to find out the LBA. It may trigger the remapping on its own. Then you could copy that disk to a new disk of same size and insert the new one on the machine...
Hmm... As is well known on the raid list, the remap occurs when an attempt is made to rewrite the faulty bloc. So if you want to carry on using the faulty drive, I'd just delete the track that froze, and forget about it. When the DVDR attempts to re-use the freed space, it should re-allocate it then. The worry is that the other blocks may be scattered all over the file system and cause a bunch of other recordings to fail. And that it might be a sign of an impending disk failure. It sounds brutal, but if the disk itself seems okay, I'd do a format, blank it completely, and hope it carries on for another seven years or so ... :-) Recordings do have a half life unfortunately. The magnetism wears out, and if you write to sectors next door that accelerates the process. Then when one day you try to read a sector that hasn't been written/refreshed for years, the read fails. Nothing wrong with the drive - the recording's just faded away. The only way to fix it is to retrieve the old data from SOMEWHERE ELSE, and overwrite the duff sector, as raid does. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-11-01 at 15:44 -0000, Wols Lists wrote:
On 01/11/17 13:07, Carlos E. R. wrote:
You have at least 131 bad sectors, known to the disk firmware. If you find out their LBA you can zero them, which causes remapping with good spare records, and the disk would work again for some time.
You could try "badblocks" on it (a very slow operation) to find out the LBA. It may trigger the remapping on its own. Then you could copy that disk to a new disk of same size and insert the new one on the machine...
Hmm... As is well known on the raid list, the remap occurs when an attempt is made to rewrite the faulty bloc.
I know. Thus, in order to find out the LBA address of the bad sectors and rewrite them I run "badblocks". And then, contrary to the common knowledge, when I do that the bad sectors disappear and SMART reports no pending sectors (!). I do not have an explanation, only that it has happened to me every time I tried since I remember (say three years back) and others. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAln6PQ8ACgkQtTMYHG2NR9Ue6ACfboFhnt9xvmjkNATPb8UBdqda 7yAAn1R6Nq41XDSWhHSXqk3a9hAiYkO9 =8AYr -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/11/17 21:30, Carlos E. R. wrote:
Thus, in order to find out the LBA address of the bad sectors and rewrite them I run "badblocks". And then, contrary to the common knowledge, when I do that the bad sectors disappear and SMART reports no pending sectors (!). I do not have an explanation, only that it has happened to me every time I tried since I remember (say three years back) and others.
That sounds like "badblocks -n". The possibility, also, is that badblocks triggers the drive to do a rewrite internally. When the bad sectors disappear, does the data stored in those sectors disappear at the same time? Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2017-11-02 at 22:17 -0000, Wols Lists wrote:
On 01/11/17 21:30, Carlos E. R. wrote:
Thus, in order to find out the LBA address of the bad sectors and rewrite them I run "badblocks". And then, contrary to the common knowledge, when I do that the bad sectors disappear and SMART reports no pending sectors (!). I do not have an explanation, only that it has happened to me every time I tried since I remember (say three years back) and others.
That sounds like "badblocks -n". The possibility, also, is that badblocks triggers the drive to do a rewrite internally.
But I did not use any option.
When the bad sectors disappear, does the data stored in those sectors disappear at the same time?
Good question. I think data should disapear, but as I could not find out which sectors were bad, I could not find out if they were in use and by what. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAln7m2YACgkQtTMYHG2NR9XMrACdGsbi8SA1BKly9hn1HqwG71+R Jl8AniJvmPwTqUgvuJ8xd5aiPFHkmWXM =hp3t -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/11/17 22:25, Carlos E. R. wrote:
On Thursday, 2017-11-02 at 22:17 -0000, Wols Lists wrote:
On 01/11/17 21:30, Carlos E. R. wrote:
Thus, in order to find out the LBA address of the bad sectors and rewrite them I run "badblocks". And then, contrary to the common knowledge, when I do that the bad sectors disappear and SMART reports no pending sectors (!). I do not have an explanation, only that it has happened to me every time I tried since I remember (say three years back) and others.
That sounds like "badblocks -n". The possibility, also, is that badblocks triggers the drive to do a rewrite internally.
But I did not use any option.
When the bad sectors disappear, does the data stored in those sectors disappear at the same time?
Good question. I think data should disapear, but as I could not find out which sectors were bad, I could not find out if they were in use and by what.
No problems thrown up by fsck? Weird. But given that something as simple as a hard drive now seems to run a full-blown operating system (usually linux!?!?), then oddities are to be expected. Troubleshooting the real cause of a raid failure on the raid list can be very frustrating. We've had a couple recently where the "why" is obvious. We'd just like to track down the "how" so we can fix it... (And at least one recently, where transient power issues were destroying in-flight writes inside the disk, which is really worrying...) Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2017-11-02 at 22:34 -0000, Wols Lists wrote:
On 02/11/17 22:25, Carlos E. R. wrote:
On Thursday, 2017-11-02 at 22:17 -0000, Wols Lists wrote:
On 01/11/17 21:30, Carlos E. R. wrote:
Thus, in order to find out the LBA address of the bad sectors and rewrite them I run "badblocks". And then, contrary to the common knowledge, when I do that the bad sectors disappear and SMART reports no pending sectors (!). I do not have an explanation, only that it has happened to me every time I tried since I remember (say three years back) and others.
That sounds like "badblocks -n". The possibility, also, is that badblocks triggers the drive to do a rewrite internally.
But I did not use any option.
When the bad sectors disappear, does the data stored in those sectors disappear at the same time?
Good question. I think data should disapear, but as I could not find out which sectors were bad, I could not find out if they were in use and by what.
No problems thrown up by fsck? Weird.
I don't run fsck when I know there are bad sectors. If the error is on metadata it can be catastrophic. First I "repair" the bad sector issue.
But given that something as simple as a hard drive now seems to run a full-blown operating system (usually linux!?!?), then oddities are to be expected.
Troubleshooting the real cause of a raid failure on the raid list can be very frustrating. We've had a couple recently where the "why" is obvious. We'd just like to track down the "how" so we can fix it...
(And at least one recently, where transient power issues were destroying in-flight writes inside the disk, which is really worrying...)
Seems interesting ;-) - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAln7osoACgkQtTMYHG2NR9V99ACeKAaC1M9nIZpHABxYA7ViikVy 6QUAnRZDLjCj6wvWCV1cnIxyTMRnobW2 =AsTg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/11/2017 08:50, Felix Miata wrote:
Last I reported one of these was for a 2TB model in August 2017. This one is a 320GB model WD3200AVVS shipped in a DVDR manufactured in 2011, the exact same model I had fail in a sister DVDR 3 years ago. The HD check function of the DVDR reported HD hours in use >20000. The HD was manufactured a month before the DVR, so both are more than 5 years old. When DVDR is powered up and not intentionally recording, it constantly buffers up to the last 6 hours of the currently tuned channel or input source for replay or permanent saving. These DVRDs use the HD in a proprietary manner, so backup and restore like we do with PC files is not possible. It can write to/from DVD, but only in real time, which makes backup and restore impractical other than by removing the disk from the DVDR and imaging it, useless for anything saved since making the last image.
The DVDR froze trying to play a recording, so I shut it down, pulled the HD out, and made an image of it thus:
ddrescue -d /dev/sdc dvdrfile.img dvdrfile.logfile
Rescued size while running was 10MB less than total size. Average rate was 49894kB/s. Errsize: 67072B. Errors: 81. Rescued: 320072MB. ipos/opos 314588MB. Runtime: 106min.
The man page, like most man pages, is minimalist WRT examples. https://www.linux.com/learn/intro-to-linux/2017/3/gnu-ddrescue-best-damaged-... like https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html suggests 3 retries. I tried again adding -r5, but errsize only improved by 3 X 512.
Should I try again using -r12 or more, or with other options? Or with dc3dd, or something else? Should I try again after dropping its temperature in the refrigerator or freezer? Is more improvement pointless to hope for?
Excerpt from smartctl -x: 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 - 906 3 Spin_Up_Time POS--K 154 153 021 - 3266 4 Start_Stop_Count -O--CK 099 099 000 - 1529 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 - 20906 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 - 1518 192 Power-Off_Retract_Count -O--CK 200 200 000 - 39 193 Load_Cycle_Count -O--CK 200 200 000 - 1529 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 198 198 000 - 131 198 Offline_Uncorrectable ----CK 100 253 000 - 0 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 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
As Carlos suggested, use dd_rhelp to recover the recoverable. Forget badblocks, if you really want to try to make the disk usable for a short time, smartctl -t long /dev/sdx and use hdparm --write-sector on the first reported bad sector (you might need to repeat), copy the sector number to hdparm command and follow the "do you really want to" instructions. If your disk hasn't got any reallocatable sectors left then what you get from dd_rhelp is all you're going to get. Lastly, my instinct says that wd green has a firmware bug that Western digital don't want to fix either that or they use sub standard platters. Regards Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Wed, 01 Nov 2017, Dave Plater wrote:
On 01/11/2017 08:50, Felix Miata wrote:
ddrescue -d /dev/sdc dvdrfile.img dvdrfile.logfile [..] As Carlos suggested, use dd_rhelp to recover the recoverable.
Guys, do NOT confuse dd_rescue from Kurt Garloff with GNU ddrescue! Felix was using the latter! And dd_rhelp is part of the former! -dnh, *tsk* -- The true sysadmin does not adjust his behaviour to fit the machine. He adjusts the machine until it behaves properly. With a hammer, if necessary. -- Brian Kantor -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-11-01 at 20:18 +0100, David Haller wrote:
Hello,
On Wed, 01 Nov 2017, Dave Plater wrote:
On 01/11/2017 08:50, Felix Miata wrote:
ddrescue -d /dev/sdc dvdrfile.img dvdrfile.logfile [..] As Carlos suggested, use dd_rhelp to recover the recoverable.
Guys, do NOT confuse dd_rescue from Kurt Garloff with GNU ddrescue! Felix was using the latter! And dd_rhelp is part of the former!
I know. I intentionally suggested dd_rhelp, because it makes choices automatically. Or so it says. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAln6R6IACgkQtTMYHG2NR9V55wCeOQ6BfC/undEA1PK/NhTRDBTx aggAn315L2OXX4oSjzuEQJR44Strj6Om =0aw9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David Haller composed on 2017-11-01 20:18 (UTC+0100):
Dave Plater wrote:
Felix Miata wrote:
ddrescue -d /dev/sdc dvdrfile.img dvdrfile.logfile
As Carlos suggested, use dd_rhelp to recover the recoverable.
Guys, do NOT confuse dd_rescue from Kurt Garloff with GNU ddrescue! Felix was using the latter! And dd_rhelp is part of the former!
-dnh, *tsk*
That distinction I was trying to make before starting the process with this disk. There had been no reference to dd_rhelp when I was trying to, so apparently I picked the other one compared to my last use 3 years ago, gnu_ddrescue. No man page for dd_rhelp, only --help option, so I'm trying to follow: http://www.ubuntugeek.com/recover-data-from-a-damaged-hard-disk-using-dd_rhe... It's gave me apparent syntax error. # dd_rhelp /dev/sdc wd3200avvs.img info produced [quote]
Probing logfile location : './wd3200avvs.img.log' Found convenient logfile location './wd3200avvs.img.log' No info available since there's no readable './wd3200avvs.img.log'.
'info' option outputs information on current rescuing state by parsing this log file that would have been created by a precedent use of dd_rhelp or dd_rescue. Since there's no log file, it has nothing to display. This happens if you haven't launched a dd_rhelp before.[/quote] Eventually I figured out info needs to be left off to actually run the command. It estimated about 94 minutes before reporting the first error. Files size is already >10% of the input disk size.... -- "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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-11-01 at 18:35 -0400, Felix Miata wrote:
Dave Plater wrote:
Guys, do NOT confuse dd_rescue from Kurt Garloff with GNU ddrescue! Felix was using the latter! And dd_rhelp is part of the former!
That distinction I was trying to make before starting the process with this disk. There had been no reference to dd_rhelp when I was trying to, so apparently I picked the other one compared to my last use 3 years ago, gnu_ddrescue.
No man page for dd_rhelp, only --help option, so I'm trying to follow: http://www.ubuntugeek.com/recover-data-from-a-damaged-hard-disk-using-dd_rhe...
It's gave me apparent syntax error.
# dd_rhelp /dev/sdc wd3200avvs.img info
Syntax is simple: dd_rhelp {filename|device} {output-file} that's all. It will automatically create a log. In your case: # dd_rhelp /dev/sdc wd3200avvs.img You write the line with "info" at the end on a second terminal once there is one running already, to ask info of the first one. For help, read "/usr/share/doc/packages/dd_rhelp/FAQ" (there are other files in that directory). - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAln6Tq0ACgkQtTMYHG2NR9X6qwCff9nDoii++dqKTPHlOhegoZ2r A+kAnitehFvWhSkvmwwTV/583vAA/dNm =UQNS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. composed on 2017-11-01 23:45 (UTC+0100):
> On Wednesday, 2017-11-01 at 18:35 -0400, Felix Miata wrote:
>>> Dave Plater wrote:
>>> Guys, do NOT confuse dd_rescue from Kurt Garloff with GNU ddrescue!
>>> Felix was using the latter! And dd_rhelp is part of the former!
>> That distinction I was trying to make before starting the process with this
>> disk. There had been no reference to dd_rhelp when I was trying to, so
>> apparently I picked the other one compared to my last use 3 years ago, gnu_ddrescue.
>> No man page for dd_rhelp, only --help option, so I'm trying to follow:
>> http://www.ubuntugeek.com/recover-data-from-a-damaged-hard-disk-using-dd_rhelp.html
>> It's gave me apparent syntax error.
>> # dd_rhelp /dev/sdc wd3200avvs.img info
> Syntax is simple:
> dd_rhelp {filename|device} {output-file}
> that's all. It will automatically create a log. In your case:
> # dd_rhelp /dev/sdc wd3200avvs.img
Seems too simple to be correct. :-p
> You write the line with "info" at the end on a second terminal once there
> is one running already, to ask info of the first one.
On completion, it generated this:
[quote]
>> Probing logfile location : '...wd3200avvs.img.log'
Log file exists already.
>> Found convenient logfile location '...wd3200avvs.img.log'
=== dd_rhelp INFO - 1 parsed chunks...
- Biggest unparsed chunk: 0 byte
- xferd(succ/err): 298.09 GiB(298.09 GiB/332.00 KiB)
100.00%(99.99%/0%)
left to parse: 0 byte
- End of file: EOF = 298.09 GiB
All your data has been dd_rescued !!
Please note that it doesn't mean that it has been RECOVERED:...[/quote]
So it seems all that must be done is dd that image back to the new HD when it
arrives. I'm not sure how long it took. I don't see in the 1MB+ log the start
time. Finish was about 20 minutes ago, so based on my last thread post here I
guess it took a bit over 5 hours.
Thanks to Greg, David, Dave and Carlos for the help!!!
> For help, read "/usr/share/doc/packages/dd_rhelp/FAQ"
> (there are other files in that directory).
--
"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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday, 2017-11-02 at 00:08 -0400, Felix Miata wrote:
> Carlos E. R. composed on 2017-11-01 23:45 (UTC+0100):
>> Syntax is simple:
>
>> dd_rhelp {filename|device} {output-file}
>
>> that's all. It will automatically create a log. In your case:
>
>> # dd_rhelp /dev/sdc wd3200avvs.img
>
> Seems too simple to be correct. :-p
You see why I like it?
>> You write the line with "info" at the end on a second terminal once there
>> is one running already, to ask info of the first one.
>
> On completion, it generated this:
> [quote]
>>> Probing logfile location : '...wd3200avvs.img.log'
> Log file exists already.
>>> Found convenient logfile location '...wd3200avvs.img.log'
> === dd_rhelp INFO - 1 parsed chunks...
> - Biggest unparsed chunk: 0 byte
> - xferd(succ/err): 298.09 GiB(298.09 GiB/332.00 KiB)
> 100.00%(99.99%/0%)
> left to parse: 0 byte
> - End of file: EOF = 298.09 GiB
>
> All your data has been dd_rescued !!
>
> Please note that it doesn't mean that it has been RECOVERED:...[/quote]
I'm not sure if this part: "100.00%(99.99%/0%)" means that there is a
little bit that failed, but if it is so, the program thought it impossible
to copy it over.
It says that "332.00 KiB" are in error, anyway. Very probably, being
video, only means that some movies have a burp. Only an issue if it
affects metadata.
(If a sector is totally unreadable, it is replaced with zeroes)
> So it seems all that must be done is dd that image back to the new HD when it
> arrives. I'm not sure how long it took. I don't see in the 1MB+ log the start
> time. Finish was about 20 minutes ago, so based on my last thread post here I
> guess it took a bit over 5 hours.
The log purpose is that you can abort the operation and continue it when
you wish, not really to be read.
> Thanks to Greg, David, Dave and Carlos for the help!!!
Welcome!
- --
Cheers,
Carlos E. R.
(from openSUSE 42.2 x86_64 "Malachite" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAln69X8ACgkQtTMYHG2NR9VrpgCcCNt+fYcAvWRK+IqLzCl5vnZE
gUAAnRVrZcbTR5xdBwyQdkGBOn2wAQI0
=8FHO
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata composed on 2017-11-02 00:08 (UTC-0400): ... > On completion, it generated this: > [quote] >>> Probing logfile location : '...wd3200avvs.img.log' > Log file exists already. >>> Found convenient logfile location '...wd3200avvs.img.log' > === dd_rhelp INFO - 1 parsed chunks... > - Biggest unparsed chunk: 0 byte > - xferd(succ/err): 298.09 GiB(298.09 GiB/332.00 KiB) > 100.00%(99.99%/0%) > left to parse: 0 byte > - End of file: EOF = 298.09 GiB > All your data has been dd_rescued !! > Please note that it doesn't mean that it has been RECOVERED:...[/quote] > So it seems all that must be done is dd that image back to the new HD when it > arrives. I'm not sure how long it took. I don't see in the 1MB+ log the start > time. Finish was about 20 minutes ago, so based on my last thread post here I > guess it took a bit over 5 hours. 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. Again, thanks to Greg, David, Dave and Carlos for the help!!! For the whole story in context of the particular DVDR model line, visit: http://www.avsforum.com/forum/106-dvd-recorders-standard-def/1277209-hard-disk-file-system-investigation-magnavox-537-535-533-515-513-2160a-2160-2080-philips-3576-3575-a-8.html#post55071630 -- "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
On 05/11/17 05:39, 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 :-) 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 ... Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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. 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. -- "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
On 05/11/17 10:02, 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. 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.) 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. 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. 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). Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
-----BEGIN PGP SIGNED MESSAGE----- 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.
No. 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: 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.
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: 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.
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 location?
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)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF0EAREIAAYFAln/nskACgkQja8UbcUWM1ysWQD4qai/tQlbyytTZXcEtqf8NLmA xo9r10UNehjwz6YVlgD+NXqmsDh/oGzr5KwmmszIioO2Ia/+zvDSaahJJusY9JI= =3m+s -----END PGP SIGNATURE-----
Felix Miata composed on 2017-11-05 18:12 (UTC-0500):
Wols Lists composed on 2017-11-05 12:02 (UTC):
Felix Miata wrote: ...
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?
I found the 3 month older identical model WD3200AVVS pulled from use 3 years ago and applied essentially the same process to the same state. It appears I have a fairly matched pair doing shelf duty now: # smartctl -x /dev/sdc | 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 - 3342 3 Spin_Up_Time POS--K 156 153 021 - 3191 4 Start_Stop_Count -O--CK 100 100 000 - 873 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 7 Seek_Error_Rate -OSR-K 100 253 000 - 0 9 Power_On_Hours -O--CK 063 063 000 - 27078 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 100 100 000 - 866 192 Power-Off_Retract_Count -O--CK 200 200 000 - 31 193 Load_Cycle_Count -O--CK 200 200 000 - 873 194 Temperature_Celsius -O---K 113 073 000 - 30 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 194 173 000 - 313 198 Offline_Uncorrectable ----CK 100 253 000 - 0 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 2 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 # date Sun Nov 5 21:40:11 EST 2017 # dd if=/dev/zero of=/dev/sdb bs=8192 39071404+0 records in 39071404+0 records out 320072933376 bytes (320 GB, 298 GiB) copied, 5406.76 s, 59.2 MB/s # date Sun Nov 5 23:21:02 EST 2017 # smartctl -x /dev/sdc | 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 - 3342 3 Spin_Up_Time POS--K 156 153 021 - 3191 4 Start_Stop_Count -O--CK 100 100 000 - 873 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 7 Seek_Error_Rate -OSR-K 100 253 000 - 0 9 Power_On_Hours -O--CK 063 063 000 - 27080 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 100 100 000 - 866 192 Power-Off_Retract_Count -O--CK 200 200 000 - 31 193 Load_Cycle_Count -O--CK 200 200 000 - 873 194 Temperature_Celsius -O---K 098 073 000 - 45 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 200 173 000 - 0 198 Offline_Uncorrectable ----CK 100 253 000 - 0 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 2 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 -- "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
On 06/11/2017 06:51, Felix Miata wrote:
Felix Miata composed on 2017-11-05 18:12 (UTC-0500):
Wols Lists composed on 2017-11-05 12:02 (UTC):
Felix Miata wrote: ...
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?
I found the 3 month older identical model WD3200AVVS pulled from use 3 years ago and applied essentially the same process to the same state. It appears I have a fairly matched pair doing shelf duty now:
# smartctl -x /dev/sdc | 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 - 3342 3 Spin_Up_Time POS--K 156 153 021 - 3191 4 Start_Stop_Count -O--CK 100 100 000 - 873 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 7 Seek_Error_Rate -OSR-K 100 253 000 - 0 9 Power_On_Hours -O--CK 063 063 000 - 27078 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 100 100 000 - 866 192 Power-Off_Retract_Count -O--CK 200 200 000 - 31 193 Load_Cycle_Count -O--CK 200 200 000 - 873 194 Temperature_Celsius -O---K 113 073 000 - 30 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 194 173 000 - 313 198 Offline_Uncorrectable ----CK 100 253 000 - 0 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 2 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 # date Sun Nov 5 21:40:11 EST 2017 # dd if=/dev/zero of=/dev/sdb bs=8192 39071404+0 records in 39071404+0 records out 320072933376 bytes (320 GB, 298 GiB) copied, 5406.76 s, 59.2 MB/s # date Sun Nov 5 23:21:02 EST 2017 # smartctl -x /dev/sdc | 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 - 3342 3 Spin_Up_Time POS--K 156 153 021 - 3191 4 Start_Stop_Count -O--CK 100 100 000 - 873 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 7 Seek_Error_Rate -OSR-K 100 253 000 - 0 9 Power_On_Hours -O--CK 063 063 000 - 27080 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 100 100 000 - 866 192 Power-Off_Retract_Count -O--CK 200 200 000 - 31 193 Load_Cycle_Count -O--CK 200 200 000 - 873 194 Temperature_Celsius -O---K 098 073 000 - 45 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 200 173 000 - 0 198 Offline_Uncorrectable ----CK 100 253 000 - 0 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 2 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
Just a thought, your device doesn't use smart on the disk but smart settings stay across resets and power cycles. Maybe if you enable smart via smartctl the disk might take better care of itself. Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Plater composed on 2017-11-06 10:17 (UTC+0200):
Just a thought, your device doesn't use smart on the disk but smart settings stay across resets and power cycles. Maybe if you enable smart via smartctl the disk might take better care of itself.
Is that not how WD ships? This is from before I actually installed it: http://fm.no-ip.com/Tmp/Hardware/Disk/hdpd-201301-mdr5132-wd5000avds5500.txt Note that the DVDR keeps the disk actively recording most of the time it's powered up. Would that affect Smart being able to take care of itself? -- "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
On 06/11/2017 10:44, Felix Miata wrote:
Dave Plater composed on 2017-11-06 10:17 (UTC+0200):
Just a thought, your device doesn't use smart on the disk but smart settings stay across resets and power cycles. Maybe if you enable smart via smartctl the disk might take better care of itself.
Is that not how WD ships? This is from before I actually installed it: http://fm.no-ip.com/Tmp/Hardware/Disk/hdpd-201301-mdr5132-wd5000avds5500.txt
You've never done a smartctl -t long ? That's an offline surface scan. hdparm say's smart is enabled, does it give reports in journalctl/log? Interesting difference between WD and seagate, my wd doesn't have this neither does yours but my seagate has "Hardware_ECC_Recovered" just below temperature.
Note that the DVDR keeps the disk actively recording most of the time it's powered up. Would that affect Smart being able to take care of itself?
AFAIR it used to be a bios option for smart to be enabled, my daughter's Vista system's 150G seagate developed problems and after putting it in my linux system I found smart disabled, I enabled it, also in bios and did a long internal test, which it passed and it worked again in her system. A brand new 1gig WD Elements usb 3 hard drive I bought didn't have smart enabled in fact it wasn't recognized by smartctl before I used a command (I found in the man page and have since forgotten) to enable smart, now it works like a normal disk with smartctl. Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Plater composed on 2017-11-06 14:36 (UTC+0200):
Felix Miata wrote:
Dave Plater composed on 2017-11-06 10:17 (UTC+0200):
Just a thought, your device doesn't use smart on the disk but smart settings stay across resets and power cycles. Maybe if you enable smart via smartctl the disk might take better care of itself.
Is that not how WD ships? This is from before I actually installed it: http://fm.no-ip.com/Tmp/Hardware/Disk/hdpd-201301-mdr5132-wd5000avds5500.txt
You've never done a smartctl -t long ? That's an offline surface scan.
Not on that brand new disk.
hdparm say's smart is enabled, does it give reports in journalctl/log?
It might have while preparing it for installation. The STB DVDR has no journal or logging. The only screen it has is "self check": DVD connect status: OK HDD connect status: OK HDD Power On Hours: 44 HDD format start: enter Power Off: power
Interesting difference between WD and seagate, my wd doesn't have this neither does yours but my seagate has "Hardware_ECC_Recovered" just below temperature.
Note that the DVDR keeps the disk actively recording most of the time it's powered up. Would that affect Smart being able to take care of itself?
AFAIR it used to be a bios option for smart to be enabled, my daughter's Vista system's 150G seagate developed problems and after putting it in my linux system I found smart disabled, I enabled it, also in bios and did a long internal test, which it passed and it worked again in her system. A brand new 1gig WD Elements usb 3 hard drive I bought didn't have smart enabled in fact it wasn't recognized by smartctl before I used a command (I found in the man page and have since forgotten) to enable smart, now it works like a normal disk with smartctl.
Those are PCs. This is a proprietary device installation. It has no apparent "BIOS", at least, not one that is accessible for selecting various options we are used to seeing in PC BIOS setup utilities. Looking through the output of smartctl -x I do see smart is "enabled". -- "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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-06 at 09:32 -0500, Felix Miata wrote:
Dave Plater composed on 2017-11-06 14:36 (UTC+0200):
Felix Miata wrote:
Dave Plater composed on 2017-11-06 10:17 (UTC+0200):
enabled in fact it wasn't recognized by smartctl before I used a command (I found in the man page and have since forgotten) to enable smart, now it works like a normal disk with smartctl.
Those are PCs. This is a proprietary device installation. It has no apparent "BIOS", at least, not one that is accessible for selecting various options we are used to seeing in PC BIOS setup utilities.
Looking through the output of smartctl -x I do see smart is "enabled".
Again, SMART runs inside of the disk, not on the computer. You can enable/disable SMART on the disk, and the setting holds across computers. You can enable/disable SMART on some computer BIOS. This only means that the computer will read or not the SMART data of the disk and act on that data. But again, SMART runs inside the hard disk only. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloAdMoACgkQtTMYHG2NR9XS2gCdEbl8Rtff4ymjqo66NnXVN+Ln zsUAn2JdILDQ5l0Br9i8bNGk31MOXeHC =qdIW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-06 at 03:44 -0500, Felix Miata wrote:
Dave Plater composed on 2017-11-06 10:17 (UTC+0200):
Just a thought, your device doesn't use smart on the disk but smart settings stay across resets and power cycles. Maybe if you enable smart via smartctl the disk might take better care of itself.
Is that not how WD ships? This is from before I actually installed it: http://fm.no-ip.com/Tmp/Hardware/Disk/hdpd-201301-mdr5132-wd5000avds5500.txt
Note that the DVDR keeps the disk actively recording most of the time it's powered up. Would that affect Smart being able to take care of itself?
No. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloAc7oACgkQtTMYHG2NR9XcsQCfY7/XQ1MjsCo5cfWwGGHNRMZf hsMAoIwM7alEcG0BexBh5f2U5VMovd9w =MSUX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-06 at 10:17 +0200, Dave Plater wrote:
On 06/11/2017 06:51, Felix Miata wrote:
Just a thought, your device doesn't use smart on the disk but smart settings stay across resets and power cycles. Maybe if you enable smart via smartctl the disk might take better care of itself.
No, that is not so. SMART runs directly on the hard disk, not on the computer. It does not depend at all on the computer. The computer job is solely to read the collected data and display it. A daemon may collect that data and put a big warning to the administrator. The computer may request testing to be done, but the test runs entirely on the hard disk using its own CPU, and the results are stored on the disk, again without using the host CPU at all. At some point in time, the host computer may read the collected data. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloAc30ACgkQtTMYHG2NR9UkBgCeMMpKfHhGSz90C+BX6Z7EzeuP BTQAnRo7g2xZ1vIvQDEnPcXHdUmxmTwc =0LZg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/11/17 14:36, Carlos E. R. wrote:
Just a thought, your device doesn't use smart on the disk but smart settings stay across resets and power cycles. Maybe if you enable smart via smartctl the disk might take better care of itself.
No, that is not so. SMART runs directly on the hard disk, not on the computer. It does not depend at all on the computer.
The computer job is solely to read the collected data and display it. A daemon may collect that data and put a big warning to the administrator.
Actually, in my experience (Seagate Barracuda), SMART settings do NOT survive a power cycle :-( I think the hard drive logs and stores errors, which smartctl will display, but certainly on the Seagate anything that requires active intervention by the drive is disabled by default on power-up and there is no way (that I know of) to change that. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-06 at 14:57 -0000, Wols Lists wrote:
On 06/11/17 14:36, Carlos E. R. wrote:
Just a thought, your device doesn't use smart on the disk but smart settings stay across resets and power cycles. Maybe if you enable smart via smartctl the disk might take better care of itself.
No, that is not so. SMART runs directly on the hard disk, not on the computer. It does not depend at all on the computer.
The computer job is solely to read the collected data and display it. A daemon may collect that data and put a big warning to the administrator.
Actually, in my experience (Seagate Barracuda), SMART settings do NOT survive a power cycle :-(
I think the hard drive logs and stores errors, which smartctl will display, but certainly on the Seagate anything that requires active intervention by the drive is disabled by default on power-up and there is no way (that I know of) to change that.
If you read the smartctl manual you see some settings that survive and some that don't. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloAejQACgkQtTMYHG2NR9UPRgCfSnSi+r0mapQnCxNIkO3QMMRQ eKgAoJSBuAC/aoCyXAsNnyiI1dTKnroU =kfG9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2017-11-05 at 23:51 -0500, Felix Miata wrote:
Felix Miata composed on 2017-11-05 18:12 (UTC-0500):
I found the 3 month older identical model WD3200AVVS pulled from use 3 years ago and applied essentially the same process to the same state. It appears I have a fairly matched pair doing shelf duty now:
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
# date Sun Nov 5 21:40:11 EST 2017 # dd if=/dev/zero of=/dev/sdb bs=8192
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 200 173 000 - 0
Expected. Now run the long SMART test on them. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloAck4ACgkQtTMYHG2NR9XOXACeNXp+tjsQ8doRDlEoRt3Y2BaT W6AAmwVHkBYNeWAN4JwPBAFclDZ3i+so =SR+T -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. composed on 2017-11-06 15:31 (UTC+0100):
On Sunday, 2017-11-05 at 23:51 -0500, Felix Miata wrote:
Felix Miata composed on 2017-11-05 18:12 (UTC-0500):
I found the 3 month older identical model WD3200AVVS pulled from use 3 years ago and applied essentially the same process to the same state. It appears I have a fairly matched pair doing shelf duty now:
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
# date Sun Nov 5 21:40:11 EST 2017 # dd if=/dev/zero of=/dev/sdb bs=8192
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 200 173 000 - 0
Expected.
Now run the long SMART test on them.
http://fm.no-ip.com/Tmp/Hardware/Disk/Funai/wd3200avvs-1785-postsmartlong.tx... http://fm.no-ip.com/Tmp/Hardware/Disk/Funai/wd3200avvs-8180-postsmartlong.tx... -- "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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Carlos E. R. composed on 2017-11-06 15:31 (UTC+0100):
On Sunday, 2017-11-05 at 23:51 -0500, Felix Miata wrote:
Felix Miata composed on 2017-11-05 18:12 (UTC-0500):
I found the 3 month older identical model WD3200AVVS pulled from use 3 years ago and applied essentially the same process to the same state. It appears I have a fairly matched pair doing shelf duty now:
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
# date Sun Nov 5 21:40:11 EST 2017 # dd if=/dev/zero of=/dev/sdb bs=8192
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 200 173 000 - 0
Expected.
Now run the long SMART test on them.
http://fm.no-ip.com/Tmp/Hardware/Disk/Funai/wd3200avvs-1785-postsmartlong.tx...
199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 2 I wonder about that. Also, the test does not complete: SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 27080 4117970 # 2 Extended offline Completed: read failure 90% 27080 4117968 Different bad locations on each run, but close. You could run "badblocks" on it. However, knowing that you did a dd zero on it, this means that it has developped _new_ bad blocks in this small period, so it is bad news.
http://fm.no-ip.com/Tmp/Hardware/Disk/Funai/wd3200avvs-8180-postsmartlong.tx...
199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 1 I do not know what exactly means that value, but I don't like it. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloAp5YACgkQtTMYHG2NR9We+QCglETe1Bd2KoxRl6Tprw/Z0X6m vGoAn0rF0xYtrTZL7smIEKtd4xxVI+cp =oyc+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/11/2017 19:03, Felix Miata wrote:
http://fm.no-ip.com/Tmp/Hardware/Disk/Funai/wd3200avvs-1785-postsmartlong.tx... This one looks bad.
http://fm.no-ip.com/Tmp/Hardware/Disk/Funai/wd3200avvs-8180-postsmartlong.tx...
This one looks ok, the logged command errors could be due to a faulty cable or such. My system hard drive (Seagate baracuda 500G) is fine but it has similar recorded UNC errors from a faulty cable. The one difference is that seagate also reports: 195 Hardware_ECC_Recovered -O-RC- 046 019 000 - 99970105 otherwise my smart attributes are fine. If 1785 comes from the same machine it's possible that the machine killed it by creating too many errors. It seems to be finding different bad sectors with every test and it isn't realocating them. If there really was an uncorrectable with no space to reallocate then it would stop on the same sector every time you ran the test. Try running repetitive smartctl -t long -C the -C will enable you to run in a loop. I don't think you need to do anything with wd3200avvs-8180 it looks fine apart from error log which could very well be a result of a fault in the machine it comes from. SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 27080 4117970 # 2 Extended offline Completed: read failure 90% 27080 4117968 # 3 Extended offline Completed: read failure 90% 27071 252915937 # 4 Extended offline Completed: read failure 90% 27070 252915955 # 5 Conveyance offline Completed without error 00% 27051 - # 6 Extended offline Completed: read failure 90% 27046 460886821 # 7 Short offline Completed without error 00% 3 - Regards Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-11-01 at 18:28 +0200, Dave Plater wrote:
On 01/11/2017 08:50, Felix Miata wrote:
...
197 Current_Pending_Sector -O--CK 198 198 000 - 131
...
As Carlos suggested, use dd_rhelp to recover the recoverable. Forget badblocks, if you really want to try to make the disk usable for a short time, smartctl -t long /dev/sdx and use hdparm --write-sector on the first reported bad sector (you might need to repeat),
This is not feasible, he has to repeat the operation 131 times. It is better to run badblocks: it may run for a day, and if lucky, it may trigger the relocation itself (has happened to me). - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAln6PfcACgkQtTMYHG2NR9VicACfbNzbIMTLcP1vWXNwb3c07ezO ahcAn0D+zfdvTjOUIzhYBUTqijXuTnGt =adY9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
The DVDR froze trying to play a recording, so I shut it down, pulled the HD out, and made an image of it thus:
ddrescue -d /dev/sdc dvdrfile.img dvdrfile.logfile
Rescued size while running was 10MB less than total size. Average rate was 49894kB/s. Errsize: 67072B. Errors: 81. Rescued: 320072MB. ipos/opos 314588MB. Runtime: 106min.
With default options skip-size is not one sector. So each error saw numerous sectors skipped. Also the default is to image in the forward direction. Now that you're 99.9% done, you want to override both: -- reverse causes the sectors to be read from the highest sector first. That mechanically changes how the heads move around, so it can cause unreadable sectors to become readable. -- skip-size=512,512 forces a error to only impact a single sector. So you want to rerun the command as: ddrescue -d /dev/sdc --reverse --skip-size=512,512 dvdrfile.img dvdrfile.logfile Be absolutely sure the image file and the logfile are the same as from your first run. If they are, ddrescue use the logfile to determine what you've already successfully grabbed and ignore it. Thus on the 10 MB of non-recovered space will be attempted. Anything newly recovered will be placed inside your image file. Good Luck Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer composed on 2017-11-01 12:32 (UTC-0400):
The DVDR froze trying to play a recording, so I shut it down, pulled the HD out, and made an image of it thus:
ddrescue -d /dev/sdc dvdrfile.img dvdrfile.logfile
Rescued size while running was 10MB less than total size. Average rate was 49894kB/s. Errsize: 67072B. Errors: 81. Rescued: 320072MB. ipos/opos 314588MB. Runtime: 106min.
With default options skip-size is not one sector. So each error saw numerous sectors skipped.
Also the default is to image in the forward direction.
Now that you're 99.9% done, you want to override both:
-- reverse causes the sectors to be read from the highest sector first. That mechanically changes how the heads move around, so it can cause unreadable sectors to become readable.
-- skip-size=512,512 forces a error to only impact a single sector.
So you want to rerun the command as:
ddrescue -d /dev/sdc --reverse --skip-size=512,512 dvdrfile.img dvdrfile.logfile
ddrescue: Numerical argument out of limits. :-( # ddrescue -V GNU ddrescue 1.20 Copyright (C) 2015 Antonio Diaz Diaz. License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. # zypper se -s -i rescue i+ | gnu_ddrescue | package | 1.20-4.2 | x86_64 | OSS # grep RETT /etc/os-release PRETTY_NAME="openSUSE Leap 42.3" In case it might be of use, the logfile: http://fm.no-ip.com/Tmp/Hardware/Disk/dvdrfile.logfile Some of its entries look suspiciously large, one by two digits instead of one like the rest.
Be absolutely sure the image file and the logfile are the same as from your first run. If they are, ddrescue use the logfile to determine what you've already successfully grabbed and ignore it. Thus on the 10 MB of non-recovered space will be attempted.
Anything newly recovered will be placed inside your image file. -- "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
On Wed, Nov 1, 2017 at 1:29 PM, Felix Miata
Greg Freemyer composed on 2017-11-01 12:32 (UTC-0400):
The DVDR froze trying to play a recording, so I shut it down, pulled the HD out, and made an image of it thus:
ddrescue -d /dev/sdc dvdrfile.img dvdrfile.logfile
Rescued size while running was 10MB less than total size. Average rate was 49894kB/s. Errsize: 67072B. Errors: 81. Rescued: 320072MB. ipos/opos 314588MB. Runtime: 106min.
With default options skip-size is not one sector. So each error saw numerous sectors skipped.
Also the default is to image in the forward direction.
Now that you're 99.9% done, you want to override both:
-- reverse causes the sectors to be read from the highest sector first. That mechanically changes how the heads move around, so it can cause unreadable sectors to become readable.
-- skip-size=512,512 forces a error to only impact a single sector.
So you want to rerun the command as:
ddrescue -d /dev/sdc --reverse --skip-size=512,512 dvdrfile.img dvdrfile.logfile
ddrescue: Numerical argument out of limits. :-(
My mistake, try: ddrescue -d /dev/sdc --reverse --skip-size=64KiB,64Kib dvdrfile.img dvdrfile.logfile Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer composed on 2017-11-01 13:57 (UTC-0400):
Felix Miata wrote:
Greg Freemyer composed on 2017-11-01 12:32 (UTC-0400):
The DVDR froze trying to play a recording, so I shut it down, pulled the HD out, and made an image of it thus:
ddrescue -d /dev/sdc dvdrfile.img dvdrfile.logfile
Rescued size while running was 10MB less than total size. Average rate was 49894kB/s. Errsize: 67072B. Errors: 81. Rescued: 320072MB. ipos/opos 314588MB. Runtime: 106min.
With default options skip-size is not one sector. So each error saw numerous sectors skipped.
Also the default is to image in the forward direction.
Now that you're 99.9% done, you want to override both:
-- reverse causes the sectors to be read from the highest sector first. That mechanically changes how the heads move around, so it can cause unreadable sectors to become readable.
-- skip-size=512,512 forces a error to only impact a single sector.
So you want to rerun the command as:
ddrescue -d /dev/sdc --reverse --skip-size=512,512 dvdrfile.img dvdrfile.logfile
ddrescue: Numerical argument out of limits. :-(
My mistake, try:
ddrescue -d /dev/sdc --reverse --skip-size=64KiB,64Kib dvdrfile.img dvdrfile.logfile
The early failing one seemed to make sense, limiting error size to one 512b sector. The new one seems like has a typo. I did it exactly anyway, and it finished instantly with same errors 81 and same errsize 65536B. I tried with --skip-size=64KiB,64KiB too, but still it finished instantly. I tried also --skip-size=1s,1s and --skip-size=8s,8s, and got the out of limits/immediate exit again on both. :-( -- "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
participants (6)
-
Carlos E. R. -
Dave Plater -
David Haller -
Felix Miata -
Greg Freemyer -
Wols Lists