Yesterday, several times using different ports, cables and eSATA enclosures, I tried using DFSee[1] to clone from a 320G Seagate to a 500G ST31000526SV (SV35 Surveillance series; firmware CV15; refurb acquired 5 weeks ago) Seagate. Each time, progress was horrifically slow, something like 2% in 20 minutes, and if I let it run long enough, forecasting 14+ hours to complete. I've been using DFSee for over a decade. It's far friendlier than dd. Finally I decided to just let it run to completion to see how long it would take. It's still not done. Fdisk (Knoppix 7.4, kernel 3.16.3, util-linux-2.20.1; openSUSE 12.3 & up are on the source HD) reports this to be a 512 byte sector HD, as does the Seagate PDF. Seatools long test gave it an OK. Dmesg reports nothing I recognize as out of the ordinary, but the clone is currently over 15 hours into process and reporting ETA of nearly 7 hours. I've taken smartctl -x reports before and during the clone. They are not encouraging, particularly Raw_Read_Error_Rate and Seek_Error_Rate: http://fm.no-ip.com/Tmp/Dfsee/smart-st3500411sv1.txt http://fm.no-ip.com/Tmp/Dfsee/smart-st3500411sv3.txt http://fm.no-ip.com/Tmp/Dfsee/smart-st3500411sv4.txt http://fm.no-ip.com/Tmp/Dfsee/smart-st3500411sv5.txt I don't think I've ever encountered cloning SATA speed that wasn't at least 10X what this is doing. Ideas? Suggestions? [1] http://www.dfsee.com/dfsee/ -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (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/16/2015 11:56 AM, Felix Miata wrote:
ifferent ports, cables and eSATA enclosures
Do all of these end up as USB on your machine? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen composed on 2015-06-16 12:31 (UTC-0700):
Felix Miata wrote:
ifferent ports, cables and eSATA enclosures
Do all of these end up as USB on your machine?
None do. Some are on ICH7, others SiI3114. Current target is latter, lspci 03:05.0. Current source looks like ICH7 00:1f.1, lsscsi command not found. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (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
Carlos E. R. composed on 2015-06-16 22:56 (UTC+0200):
Felix Miata wrote:
(SV35 Surveillance series; firmware CV15; refurb acquired 5 weeks ago)
Maybe it is faulty. Refurb... :-?
O_O smartctl -x excerpts (taken at successive times in the past 24 hours, from links in OP): SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE (first test) 1 Raw_Read_Error_Rate POSR-- 109 100 006 - 24389603 7 Seek_Error_Rate POSR-- 100 253 030 - 90114 (2nd test) 1 Raw_Read_Error_Rate POSR-- 118 100 006 - 174626326 7 Seek_Error_Rate POSR-- 060 060 030 - 1121189 (3rd test) 1 Raw_Read_Error_Rate POSR-- 119 100 006 - 217845607 7 Seek_Error_Rate POSR-- 061 060 030 - 1435080 (4th test) 1 Raw_Read_Error_Rate POSR-- 111 100 006 - 40230825 7 Seek_Error_Rate POSR-- 066 060 030 - 3731378 current raw 208860613 & seek 4962806 Anything unexpected here? # dmesg | grep -i ata [ 1.166964] ata1.00: FORCE: horkage modified (noncq) [ 1.166968] ata1.00: ATAPI: TSSTcorp CDDVDW SH-S202N, SB02, max UDMA/66 [ 1.166972] ata1.00: limited to UDMA/33 due to 40-wire cable [ 1.176862] ata3.00: FORCE: horkage modified (noncq) [ 1.176914] ata4.01: FORCE: horkage modified (noncq) [ 1.177155] ata4.01: ATA-8: ST3500411SV, CV15, max UDMA/133 [ 1.177160] ata4.01: 976773168 sectors, multi 16: LBA48 NCQ (not used) [ 1.177294] ata3.00: ATA-8: ST3320613AS, SD2B, max UDMA/133 [ 1.177298] ata3.00: 625142448 sectors, multi 16: LBA48 NCQ (not used) [ 1.180190] ata1.00: configured for UDMA/33 [ 1.190390] ata4.01: configured for UDMA/133 [ 1.190752] ata3.00: configured for UDMA/133 [ 1.193828] scsi 2:0:0:0: Direct-Access ATA ST3320613AS SD2B PQ: 0 ANSI: 5 [ 1.194100] scsi 3:0:1:0: Direct-Access ATA ST3500411SV CV15 PQ: 0 ANSI: 5 [ 1.323374] ata5: SATA link down (SStatus 0 SControl 310) [ 1.643376] ata6: SATA link down (SStatus 0 SControl 310) [ 1.963366] ata7: SATA link down (SStatus 0 SControl 310) [ 2.283370] ata8: SATA link down (SStatus 0 SControl 310) [ 2.283852] Write protecting the kernel read-only data: 2700k ETA on clone remains nearly 4hrs. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (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 Tue, Jun 16, 2015 at 5:19 PM, Felix Miata <mrmazda@earthlink.net> wrote:
O_O smartctl -x excerpts (taken at successive times in the past 24 hours, from links in OP):
SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE (first test) 1 Raw_Read_Error_Rate POSR-- 109 100 006 - 24389603 7 Seek_Error_Rate POSR-- 100 253 030 - 90114 (2nd test) 1 Raw_Read_Error_Rate POSR-- 118 100 006 - 174626326 7 Seek_Error_Rate POSR-- 060 060 030 - 1121189 (3rd test) 1 Raw_Read_Error_Rate POSR-- 119 100 006 - 217845607 7 Seek_Error_Rate POSR-- 061 060 030 - 1435080 (4th test) 1 Raw_Read_Error_Rate POSR-- 111 100 006 - 40230825 7 Seek_Error_Rate POSR-- 066 060 030 - 3731378 current raw 208860613 & seek 4962806
Anything unexpected here?
Those raw values are really climbing fast. The raw_read_error_rate even looks like it rolled over. Can you RMA the drive? Greg -- Greg Freemyer www.IntelligentAvatar.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-06-17 03:54, Greg Freemyer wrote:
Those raw values are really climbing fast. The raw_read_error_rate even looks like it rolled over.
Seagates have very high values there. Look at some of mine: Telcontar:~ # smartctl -a /dev/sda | grep -i Error_Rate 1 Raw_Read_Error_Rate 0x000f 119 099 006 Pre-fail Always - 233983800 7 Seek_Error_Rate 0x000f 063 060 030 Pre-fail Always - 8594177133 Telcontar:~ # smartctl -a /dev/sdb | grep -i Error_Rate 1 Raw_Read_Error_Rate 0x000f 106 099 006 Pre-fail Always - 11070088 7 Seek_Error_Rate 0x000f 066 060 030 Pre-fail Always - 4701968 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 Telcontar:~ # smartctl -a /dev/sdc | grep -i Error_Rate 1 Raw_Read_Error_Rate 0x000f 118 099 006 Pre-fail Always - 198177419 7 Seek_Error_Rate 0x000f 080 060 030 Pre-fail Always - 117310601 Telcontar:~ # smartctl -a /dev/sdd | grep -i Error_Rate 1 Raw_Read_Error_Rate 0x000f 119 099 006 Pre-fail Always - 218644298 7 Seek_Error_Rate 0x000f 079 060 030 Pre-fail Always - 99367115 Telcontar:~ # smartctl -a /dev/sde | grep -i Error_Rate 1 Raw_Read_Error_Rate 0x000f 118 099 006 Pre-fail Always - 197823840 7 Seek_Error_Rate 0x000f 075 060 030 Pre-fail Always - 8671238414 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 Telcontar:~ # It doesn't mean much. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Greg Freemyer composed on 2015-06-16 21:54 (UTC-0400):
Felix Miata wrote:
smartctl -x excerpts (taken at successive times in the past 24 hours, from links in OP):
SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE (first test) 1 Raw_Read_Error_Rate POSR-- 109 100 006 - 24389603 7 Seek_Error_Rate POSR-- 100 253 030 - 90114 (2nd test) 1 Raw_Read_Error_Rate POSR-- 118 100 006 - 174626326 7 Seek_Error_Rate POSR-- 060 060 030 - 1121189 (3rd test) 1 Raw_Read_Error_Rate POSR-- 119 100 006 - 217845607 7 Seek_Error_Rate POSR-- 061 060 030 - 1435080 (4th test) 1 Raw_Read_Error_Rate POSR-- 111 100 006 - 40230825 7 Seek_Error_Rate POSR-- 066 060 030 - 3731378 current raw 208860613 & seek 4962806 (5th) 1 Raw_Read_Error_Rate POSR-- 115 100 006 - 94249948 7 Seek_Error_Rate POSR-- 067 060 030 - 6254454 (6th) 1 Raw_Read_Error_Rate POSR-- 117 100 006 - 146687823 7 Seek_Error_Rate POSR-- 068 060 030 - 6292264
Anything unexpected here?
Those raw values are really climbing fast. The raw_read_error_rate even looks like it rolled over.
Carlos E. R. composed on 2015-06-17 04:16 (UTC+0200):
Seagates have very high values there.
I suspect Greg and Carlos are both right. It appears wrapping produces various big values that are of little use unless one knows they roll over and only uses them for comparing in a series such as I did. The fact that Seatools declared the drive good in combination with performance not booted to Knoppix on the N10/ICH7 PC seem to say the target recertified Seagate is behaving normally.
From above is suggested something about the N10/ICH7 PC booted to Knoppix 3.16.3 is buggy in some way - maybe to do with the DVD being boot device on PATA? It's the same PC that started giving me another wierd problem after the first of the year. It was subjecting me to long waits after making a Grub menu selection before the initrd would finish loading if booting installations with kernels newer than Mageia's 3.14.whatever or so. Which ones I don't remember exactly because a BIOS reset a couple of months after the problem started knocked the delays down to the vicinity of zero, lengths hard to pin down due to large but highly variable file sizes.
This is an excerpt from the cloning log begun contemporanously to OP: Size to clone : 0x2542EAB0 = 305245 MiB FROM : Store B : Whole Physical disk 1 FDISK size: 305245 MiB TO : Store A : Whole Physical disk 2 FDISK size: 476940 MiB Copy direction SN : Forward, other disk, Full -clone, buffer 63 sect = 31.5 KiB First sector todo : 0x00000000 Last sector done : 0x2542EAAF size 0x2542EAB0 = 305245 MiB Elapsed time : 20:27:21 (h:m:sec) Throughput = 4.15 MiB/sec On shutting down, removing the Knoppix DVD, disconnecting the source HD, and booting the target, I was able to boot 13.1, 13.2 and TW and see no evidence of performance issues. Before removing the target, I booted its 13.1 to tweak the UUIDs, filesystem labels, fstabs and menu.lsts, and got this result: # hdparm -Tt /dev/sda /dev/sdb /dev/sda: Timing cached reads: 4028 MB in 2.00 seconds = 2015.40 MB/sec Timing buffered disk reads: 336 MB in 3.00 seconds = 111.85 MB/sec /dev/sdb: Timing cached reads: 4064 MB in 2.00 seconds = 2033.76 MB/sec Timing buffered disk reads: 352 MB in 3.02 seconds = 116.66 MB/sec After being satisfied of normal behavior booted not to the Knoppix DVD, I moved both source and target to eSATA devices, connected them to about a 2 years older PC's (ICH5 vs post-ICH9 ICH7, iG41) SiI3512 eSATA ports, booted TW, and did selective cloning between the same source and target: First: DFSee Linux 12.4 : Executing: clone -p:74 -!- Last sector done : 0x00960524 size 0x00960525 = 4800.6 MiB Elapsed time : 1:49 (h:m:sec) Throughput = 44.04 MiB/sec Second: DFSee Linux 12.4 : Executing: clone -p:75 -!- Last sector done : 0x12A18A81 size 0x12A18A82 = 152625 MiB Elapsed time : 1:03:01 (h:m:sec) Throughput = 40.37 MiB/sec Given those speeds are about normal on that hardware, I rebooted using the Knoppix DVD and repeated the first test from previous (TW) boot: DFSee Linux 12.4 : Executing: clone -p:74 -!- Last sector done : 0x00960524 size 0x00960525 = 4800.6 MiB Elapsed time : 2:00 (h:m:sec) Throughput = 40.01 MiB/sec Next I moved source and target to an ICH8 PC, booted 13.2, cloned the same 4800 MiB partition as first done on the TW boot, and got throughput of 46.61 MiB/sec. I followed that up with a repeat of the clone that took 20.5 hours and produced 4.15 MiB/sec throughput. It's now 55% complete 75 minutes into the process, looking like it's going to net 40+ MiB/sec.
Can you RMA the drive?
The paperwork on its RMA is already complete, but it probably should be canceled. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (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 2015-06-17 10:40, Felix Miata wrote:
Greg Freemyer composed on 2015-06-16 21:54 (UTC-0400): Carlos E. R. composed on 2015-06-17 04:16 (UTC+0200):
I suspect Greg and Carlos are both right. It appears wrapping produces various big values that are of little use unless one knows they roll over and only uses them for comparing in a series such as I did.
rolling values... I never thought of that.
Can you RMA the drive?
The paperwork on its RMA is already complete, but it probably should be canceled.
Yes. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/17/2015 12:17 PM, Carlos E. R. wrote:
On 2015-06-17 10:40, Felix Miata wrote:
Greg Freemyer composed on 2015-06-16 21:54 (UTC-0400): Carlos E. R. composed on 2015-06-17 04:16 (UTC+0200):
I suspect Greg and Carlos are both right. It appears wrapping produces various big values that are of little use unless one knows they roll over and only uses them for comparing in a series such as I did.
rolling values... I never thought of that.
Can you RMA the drive?
The paperwork on its RMA is already complete, but it probably should be canceled.
Yes.
Rolling values would explain LOW readings, not necessarily high ones. Also different drive manufacturers use different units and you really have to check the specifics any time you read these. Not all of those numbers are significant as Carlos mentioned up-thread. I always check power on hours and power up count on new drives since that time Best Buy tried to slip me a referb/return. Once a drive starts dipping into its reserved space, I move off of it, and if its RMA-able I run a full surface write test before I send it back. If i can't wipe it, and the drive is in-expensive, I will forego the RMA, and offer it a sledge hammer instead. - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlWB4HEACgkQv7M3G5+2DLKHgQCcDYeBp1ekRumEoX8RudeaXlDF B9MAn0H7O5asaa6QLAj6eWoj0X2uQuwy =YaK5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 17 Jun 2015 14:02:41 -0700 John Andersen wrote: 8< - - - - - snipped - - - - - >8
Rolling values would explain LOW readings, not necessarily high ones. Also different drive manufacturers use different units and you really have to check the specifics any time you read these. Not all of those numbers are significant as Carlos mentioned up-thread.
I always check power on hours and power up count on new drives since that time Best Buy tried to slip me a referb/return.
Once a drive starts dipping into its reserved space, I move off of it, and if its RMA-able I run a full surface write test before I send it back. If i can't wipe it, and the drive is in-expensive, I will forego the RMA, and offer it a sledge hammer instead.
+ 1 My comments here are germane: http://lists.opensuse.org/opensuse/2014-09/msg00018.html regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Carl Hartung -
Carlos E. R. -
Felix Miata -
Greg Freemyer -
John Andersen