January 16, 201115 yr Just built m UnRaid machine, and am trying to copy all of my existing media from my current storage solution, connected to my iMac. I select everything I want to copy over, approx 350 files and 1.5 tb, and start copying over my network. Starts out great, says it will take 8 hours, and once it gets to 9.94 GB's, the transfer stalls. This happens every time, after multiple reboots on both machines. Any help would be really appreciated. If I can get this to work, I'm a believe and a pro license will be in my future. Currently installed 4.7 beta 1, the stable release wasn't available when I went to set it up. Thanks. http://www.thehtpc.net/htpc-tips-and-tweaks/resolving-unraid-and-windows-file-transfer-issues/ This sounded like the closest solution that I found, but it is a Windows 7 problem.
January 16, 201115 yr Author I think I discovered the problem. I tried copying the same data directly to disk2 (Hitachi 1tb) and it transfers without a problem. Tried copying directly to disk1 (WD20EARS) and that's when it fails at around 10gb's. Bad drive? Or do I have something configured wrong? Thanks for any help.
January 16, 201115 yr I think I discovered the problem. I tried copying the same data directly to disk2 (Hitachi 1tb) and it transfers without a problem. Tried copying directly to disk1 (WD20EARS) and that's when it fails at around 10gb's. Bad drive? Or do I have something configured wrong? Thanks for any help. I've often found inconsistencies when copying on OS X (10.6 on my hack) and have found that restarting the server or the hack, or both often solves the issue. However, before I precleared all my new drives for a minimum of ten days, I found that most of the new EARS, EADS and EVDS drives I was installing were in fact littered with bad sectors. Bad in that they were unrecoverable after days of trying. I sent all but one of my 8-most-recent purchases back for RMA (so far, & some twice). Anyway, when I was having issues with bad sectors, I noticed what you are noticing, sometimes with excrutiatingly-long copy times, and eventual failures if left for days to try to complete. I'd check your smart history on your disk1 and see if it shows anything up front. If SMART says something is wrong, then remove the drive from your array, and run the manufacturer's disk test utility on a full surface scan and see if it agrees. When I did so on my failing drives, the WD Diagnostics software came up with "irreparable bad sectors" more often than not. Now that my array is stable, I have experienced far fewer issues like this.
January 17, 201115 yr Author bman, thanks for your response/help. I ran the SMART scan and here is the results. Anything out of the ordinary? === START OF INFORMATION SECTION === Device Model: WDC WD20EARS-00MVWB0 Serial Number: WD-WCAZA2168382 Firmware Version: 51.0AB51 User Capacity: 2,000,398,934,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Sun Jan 16 19:12:51 2011 Local time zone must be set--see zic m SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x85) Offline data collection activity was aborted by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (37680) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 255) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x3035) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 253 253 021 Pre-fail Always - 1200 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 36 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 14 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 33 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 27 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 91 194 Temperature_Celsius 0x0022 122 119 000 Old_age Always - 28 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 14 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay.
January 17, 201115 yr Author Interesting to note, I transfered files over to my WD20EARS under 10gb, and the files succeeded, and then I transferred another batch of files, and it stalled at 650ish mb's. What in the world is going on. Here is my syslog: Jan 16 19:10:14 Tower kernel: xor: using function: pIII_sse (10985.600 MB/sec) Jan 16 19:10:14 Tower kernel: md: unRAID driver 1.1.1 installed Jan 16 19:10:14 Tower kernel: read_file: error 2 opening /boot/config/super.dat Jan 16 19:10:14 Tower kernel: md: could not read superblock from /boot/config/super.dat Jan 16 19:10:14 Tower kernel: md: initializing superblock Jan 16 19:10:14 Tower kernel: md: import disk1: [3,64] (hdb) WDC WD20EARS-00MVWB0 WD-WCAZA2168382 size: 1953514552 Jan 16 19:10:14 Tower kernel: md: disk1 new disk Jan 16 19:10:14 Tower kernel: md: import disk2: [8,0] (sda) Hitachi HDT72101 STF607MH3M896K size: 976762552 Jan 16 19:10:14 Tower kernel: md: disk2 new disk Jan 16 19:10:14 Tower kernel: mdcmd (1): set md_num_stripes 1280 Jan 16 19:10:14 Tower kernel: mdcmd (2): set md_write_limit 768 Jan 16 19:10:14 Tower kernel: mdcmd (3): set md_sync_window 288 Jan 16 19:10:14 Tower kernel: mdcmd (4): set spinup_group 1 0 Jan 16 19:10:14 Tower kernel: mdcmd (5): set spinup_group 2 0 Jan 16 19:10:19 Tower emhttp: shcmd (77): modprobe -rw md-mod 2>&1 | logger Jan 16 19:10:19 Tower emhttp: shcmd (78): modprobe md-mod super=/boot/config/super.dat slots=3,0,3,64,8,0 2>&1 | logger Jan 16 19:10:19 Tower kernel: md: unRAID driver removed Jan 16 19:10:19 Tower kernel: xor: automatically using best checksumming function: pIII_sse Jan 16 19:10:19 Tower kernel: pIII_sse : 10985.600 MB/sec Jan 16 19:10:19 Tower kernel: xor: using function: pIII_sse (10985.600 MB/sec) Jan 16 19:10:19 Tower kernel: md: unRAID driver 1.1.1 installed Jan 16 19:10:19 Tower kernel: read_file: error 2 opening /boot/config/super.dat Jan 16 19:10:19 Tower kernel: md: could not read superblock from /boot/config/super.dat Jan 16 19:10:19 Tower kernel: md: initializing superblock Jan 16 19:10:19 Tower kernel: md: import disk0: [3,0] (hda) WDC WD20EARS-00MVWB0 WD-WCAZA2072628 size: 1953514552 Jan 16 19:10:19 Tower kernel: md: disk0 new disk Jan 16 19:10:19 Tower kernel: md: import disk1: [3,64] (hdb) WDC WD20EARS-00MVWB0 WD-WCAZA2168382 size: 1953514552 Jan 16 19:10:19 Tower kernel: md: disk1 new disk Jan 16 19:10:19 Tower kernel: md: import disk2: [8,0] (sda) Hitachi HDT72101 STF607MH3M896K size: 976762552 Jan 16 19:10:19 Tower kernel: md: disk2 new disk Jan 16 19:10:19 Tower kernel: mdcmd (1): set md_num_stripes 1280 Jan 16 19:10:19 Tower kernel: mdcmd (2): set md_write_limit 768 Jan 16 19:10:19 Tower kernel: mdcmd (3): set md_sync_window 288 Jan 16 19:10:19 Tower kernel: mdcmd (4): set spinup_group 0 2 Jan 16 19:10:19 Tower kernel: mdcmd (5): set spinup_group 1 1 Jan 16 19:10:19 Tower kernel: mdcmd (6): set spinup_group 2 0 Jan 16 19:10:24 Tower emhttp: shcmd (79): /usr/local/sbin/set_ncq hda 1 >/dev/null Jan 16 19:10:24 Tower emhttp: shcmd (80): /usr/local/sbin/set_ncq hdb 1 >/dev/null Jan 16 19:10:24 Tower emhttp: shcmd (81): /usr/local/sbin/set_ncq sda 1 >/dev/null Jan 16 19:10:24 Tower kernel: mdcmd (7): start NEW_ARRAY Jan 16 19:10:24 Tower kernel: unraid: allocating 18360K for 1280 stripes (3 disks) Jan 16 19:10:24 Tower kernel: md1: running, size: 1953514552 blocks Jan 16 19:10:24 Tower kernel: md2: running, size: 976762552 blocks Jan 16 19:10:25 Tower emhttp: shcmd (82): udevadm settle Jan 16 19:10:25 Tower emhttp: shcmd (83): mkdir /mnt/disk2 Jan 16 19:10:25 Tower emhttp: shcmd (83): mkdir /mnt/disk1 Jan 16 19:10:25 Tower emhttp: shcmd (84): set -o pipefail ; mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md2 /mnt/disk2 2>&1 | logger Jan 16 19:10:25 Tower emhttp: shcmd (85): set -o pipefail ; mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md1 /mnt/disk1 2>&1 | logger Jan 16 19:10:25 Tower kernel: mdcmd (: check Jan 16 19:10:25 Tower kernel: md: recovery thread woken up ... Jan 16 19:10:25 Tower kernel: md: recovery thread syncing parity disk ... Jan 16 19:10:25 Tower kernel: md: using 1152k window, over a total of 1953514552 blocks. Jan 16 19:10:25 Tower kernel: REISERFS (device md1): found reiserfs format "3.6" with standard journal Jan 16 19:10:25 Tower kernel: REISERFS (device md1): using ordered data mode Jan 16 19:10:25 Tower kernel: REISERFS (device md2): found reiserfs format "3.6" with standard journal Jan 16 19:10:25 Tower kernel: REISERFS (device md2): using ordered data mode Jan 16 19:10:25 Tower kernel: REISERFS (device md1): journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Jan 16 19:10:25 Tower kernel: REISERFS (device md1): checking transaction log (md1) Jan 16 19:10:25 Tower kernel: REISERFS (device md2): journal params: device md2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Jan 16 19:10:25 Tower kernel: REISERFS (device md2): checking transaction log (md2) Jan 16 19:10:25 Tower kernel: REISERFS (device md2): Using r5 hash to sort names Jan 16 19:10:25 Tower kernel: REISERFS (device md1): Using r5 hash to sort names Jan 16 19:10:26 Tower emhttp: shcmd (87): rm /etc/samba/smb-shares.conf >/dev/null 2>&1 Jan 16 19:10:26 Tower emhttp: shcmd (88): cp /etc/exports- /etc/exports Jan 16 19:10:26 Tower emhttp: shcmd (89): mkdir /mnt/user Jan 16 19:10:26 Tower emhttp: shcmd (90): /usr/local/sbin/shfs /mnt/user -o noatime,big_writes,allow_other,default_permissions Jan 16 19:10:27 Tower emhttp: shcmd (91): killall -HUP smbd Jan 16 19:10:27 Tower emhttp: shcmd (92): /etc/rc.d/rc.nfsd restart | logger Jan 16 19:10:32 Tower kernel: mdcmd (9): nocheck Jan 16 19:10:32 Tower kernel: md: md_do_sync: got signal, exit... Jan 16 19:10:32 Tower kernel: md: recovery thread sync completion status: -4
January 17, 201115 yr Does the WD20EARS have the 7-8 jumper installed? I guess it wouldn't work at all if it didn't though...
January 17, 201115 yr Does the WD20EARS have the 7-8 jumper installed? I guess it wouldn't work at all if it didn't though... It would work either way. DO NOT CHANGE THE JUMPER IF THE DRIVE IS CURRENTLY ASSIGNED TO THE ARRAY.
January 17, 201115 yr Does the WD20EARS have the 7-8 jumper installed? I guess it wouldn't work at all if it didn't though... It would work either way. DO NOT CHANGE THE JUMPER IF THE DRIVE IS CURRENTLY ASSIGNED TO THE ARRAY. Thanks for the info. What would happen if some idiot put the jumper on after running the drive in the array without it...? That idiot is me btw.
January 17, 201115 yr Author Does the WD20EARS have the 7-8 jumper installed? I guess it wouldn't work at all if it didn't though... Yes, I have the jumper installed, and using 4.7beta1
Archived
This topic is now archived and is closed to further replies.