Hi, My only 3 TB Seagate disk died suddenly, at 19447 hours of use. Smartctl was perfect one day, thousand of bad sectors the next day. Report attached. I bought a new disk and tried dd_rhelp to try recover some. It coredumped after a while. So I switched to ddrescue instead, which did finished - but it recovered less than 1%. Telcontar:~/Rescate_sde # time ddrescue --force /dev/sdf /dev/sde mapfile GNU ddrescue 1.23 Press Ctrl-C to interrupt ipos: 3000 GB, non-trimmed: 0 B, current rate: 0 B/s opos: 3000 GB, non-scraped: 0 B, average rate: 270 kB/s non-tried: 0 B, bad-sector: 2975 GB, error rate: 15374 kB/s rescued: 24785 MB, bad areas: 6, run time: 1d 1h 29m pct rescued: 0.82%, read errors:5857531191, remaining time: n/a time since last successful read: 1d 53m 36s Finished real 1529m30.632s user 135m6.844s sys 750m55.166s Telcontar:~/Rescate_sde # On syslog, tons of errors - I copy the end of it: <1.4> 2019-06-06 17:47:33 Telcontar udisksd 4343 - - Error performing housekeeping for drive /org/freedesktop/UDisks2/drives/ST3000DM001_1CH166_Z1F42M6N: Error updating SMART data: Error sending ATA command CHECK POWER MODE: Unexpected sense data returned:#0120000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................#0120010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................#012 (g-io-error-quark, 0) <1.4> 2019-06-06 17:57:33 Telcontar udisksd 4343 - - Error performing housekeeping for drive /org/freedesktop/UDisks2/drives/ST3000DM001_1CH166_Z1F42M6N: Error updating SMART data: Error sending ATA command CHECK POWER MODE: Unexpected sense data returned:#0120000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................#0120010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................#012 (g-io-error-quark, 0) <0.6> 2019-06-06 17:57:33 Telcontar kernel - - - [156725.304768] sd 7:0:0:0: [sdf] tag#17 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK <0.6> 2019-06-06 17:57:33 Telcontar kernel - - - [156725.304772] sd 7:0:0:0: [sdf] tag#17 CDB: ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00 <1.4> 2019-06-06 18:07:33 Telcontar udisksd 4343 - - Error performing housekeeping for drive /org/freedesktop/UDisks2/drives/ST3000DM001_1CH166_Z1F42M6N: Error updating SMART data: Error sending ATA command CHECK POWER MODE: Unexpected sense data returned:#0120000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................#0120010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................#012 (g-io-error-quark, 0) <0.6> 2019-06-06 18:07:33 Telcontar kernel - - - [157325.363715] sd 7:0:0:0: [sdf] tag#19 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK <0.6> 2019-06-06 18:07:33 Telcontar kernel - - - [157325.363719] sd 7:0:0:0: [sdf] tag#19 CDB: ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00 <1.4> 2019-06-06 18:17:34 Telcontar udisksd 4343 - - Error performing housekeeping for drive /org/freedesktop/UDisks2/drives/ST3000DM001_1CH166_Z1F42M6N: Error updating SMART data: Error sending ATA command CHECK POWER MODE: Unexpected sense data returned:#0120000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................#0120010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................#012 (g-io-error-quark, 0) <0.6> 2019-06-06 18:17:34 Telcontar kernel - - - [157925.740068] sd 7:0:0:0: [sdf] tag#21 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK <0.6> 2019-06-06 18:17:34 Telcontar kernel - - - [157925.740072] sd 7:0:0:0: [sdf] tag#21 CDB: ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00 <1.4> 2019-06-06 18:27:34 Telcontar udisksd 4343 - - Error performing housekeeping for drive /org/freedesktop/UDisks2/drives/ST3000DM001_1CH166_Z1F42M6N: Error updating SMART data: Error sending ATA command CHECK POWER MODE: Unexpected sense data returned:#0120000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................#0120010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................#012 (g-io-error-quark, 0) <0.6> 2019-06-06 18:27:34 Telcontar kernel - - - [158526.004939] sd 7:0:0:0: [sdf] tag#23 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK <0.6> 2019-06-06 18:27:34 Telcontar kernel - - - [158526.004944] sd 7:0:0:0: [sdf] tag#23 CDB: ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00 <1.4> 2019-06-06 18:37:33 Telcontar udisksd 4343 - - Error performing housekeeping for drive /org/freedesktop/UDisks2/drives/ST3000DM001_1CH166_Z1F42M6N: Error updating SMART data: Error sending ATA command CHECK POWER MODE: Unexpected sense data returned:#0120000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................#0120010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................#012 (g-io-error-quark, 0) <0.6> 2019-06-06 18:37:33 Telcontar kernel - - - [159125.573187] sd 7:0:0:0: [sdf] tag#25 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK <0.6> 2019-06-06 18:37:33 Telcontar kernel - - - [159125.573191] sd 7:0:0:0: [sdf] tag#25 CDB: ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00 I attach what I think is the start section of the log when I connected the disk. How can a disk get that amount of bad data? The surface can not go bad entirely except for a few megabytes at the start of the disk, it has to be the electronics. Any ideas? I want to know if it is possible to power cycle the disk, then use ddrescue again in some form so that it ignores previously read sectors and goes for the bad areas directly. The data is just multimedia, no big deal - I hope - so I'm mostly playing with the disk. Apparently I don't have any other 3TB unit (I know they were bad, but hey, this unit is years old) to switch the board. I do have a 2TB unit with true surface defects. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Am 06.06.19 um 19:00 schrieb Carlos E. R.:
Hi,
My only 3 TB Seagate disk died suddenly, at 19447 hours of use. Smartctl was perfect one day, thousand of bad sectors the next day. Report attached.
I bought a new disk and tried dd_rhelp to try recover some. It coredumped after a while. So I switched to ddrescue instead, which did finished - but it recovered less than 1%.
The data is just multimedia, no big deal - I hope - so I'm mostly playing with the disk. Apparently I don't have any other 3TB unit (I know they were bad, but hey, this unit is years old) to switch the board. I do have a 2TB unit with true surface defects.
yep i would try switching the board, search in ebay to find one.... good luck.... simoN -- www.becherer.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/06/2019 12:00 PM, Carlos E. R. wrote:
Hi,
My only 3 TB Seagate disk died suddenly, at 19447 hours of use. Smartctl was perfect one day, thousand of bad sectors the next day. Report attached.
I bought a new disk and tried dd_rhelp to try recover some. It coredumped after a while. So I switched to ddrescue instead, which did finished - but it recovered less than 1%.
Ouch! I feel your pain. I just had a 42.3 box scatter in the most bizarre way I've ever seen. Was rsync'ing files to it. (no doubt a capacitor was getting flaky) The machine froze during rsync, would boot just fine, but then would not allow a user login (boots fine to kdm or to console). It's like it no longer has the links/whatever needed to authenticate. I booted via the install, chrooted, ran zypper up, and there were a number of shared-object files reported as zero-length, e.g.: Additional rpm output: /sbin/ldconfig: File /usr/lib64/libwiretap.so.7 is empty, not checked. /sbin/ldconfig: File /usr/lib64/libwscodecs.so.1.1.0 is empty, not checked. /sbin/ldconfig: File /usr/lib64/libwiretap.so.7.0.14 is empty, not checked. /sbin/ldconfig: File /usr/lib64/libwiretap.so.7 is empty, not checked. /sbin/ldconfig: File /usr/lib64/libwscodecs.so.1.1.0 is empty, not checked. /sbin/ldconfig: File /usr/lib64/libwiretap.so.7.0.14 is empty, not checked. So something is FUBAR. The chroot went fine and running zypper-up went fine, but clearly there were libraries that got hosed somehow. (? bad/corrupt address caused files to be written wiping out libs? -- never thought that was possible running rsync as a non-privileged user) So a board issue can radically affect how/what the disk does. This was on an old laptop (probably 12 years old or so), so board replacement is a nogo. Just sucks to lose a beautiful 17" display (even if the little ticks on the 'F' and 'J' keys are worn off, just improved your hand position :) -- David C. Rankin, J.D.,P.E.
On 06/08/2019 12:26 AM, David C. Rankin wrote:
Just sucks to lose a beautiful 17" display (even if the little ticks on the 'F' and 'J' keys are worn off, just improved your hand position:
I've worn off my "ticks" too! It really impressed some of my users, they couldn't believe I've been so productive. It's tempting to sand off the ticks on new keyboards just to keep my users in awe! (we old-farts need to be creative to keep convincing users that they need to keep us around) Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Carlos E. R. -
David C. Rankin -
Lew Wolfgang -
Simon Becherer