dwoods99

I have done this but I still got Too many wrong and/or missing disks!. I put disk 7 and 8 back the way it was, did 'new config' and now fixing parity. I am sure the contents of disk 7 was correct so I am taking the risk that I won't lose data -- no other choice anymore. @RobJ, It just seems that disk 8 was being spun up or down and hanging during rebuild of data on disk 7, causing the rebuild to fail. As for disk 8 'failed', I was referring to smartctl output when short test run from the simplefeatures web menu. I previously posted what was most likely the only relevant parts to the syslog that might indicate disk7/8 problems. I am no expert on smartctl but pretty knowledgeable with servers and unix. The original 2TB disk 7 has already been allocated and used in my second unRaid server. Thanks to all who have been helping me with this problem.

When I tried to replace disk8, I now get Too many wrong and/or missing disks! after selecting the new one. To me this means that my fears of losing data on disk7 *and* disk8 are valid. I don't think I can do anything else but replace disk7 first in order to rebuild the data, and then disk8. Open to other suggestions.

I understand that however since I see disk7 being the one trying to rebuild data, I am worried that removing disk8 and rebuilding it would cause data loss from disk7. Is that wrong?

It seems that disk7 (3TB) checks out ok with smartctl but disk8 (3TB) failed -- these are both new drives this month. Problem is that the data rebuild is doing many writes on disk7 to rebuild and fix. I have a third 3TB drive, pre-cleared and ready to use. Does it make sense to swap out disk7 with the new one, let it rebuild and hopefully this time no more hanging. And then once completed, pre-clear the old disk7, and swap it with disk8 and rebuild again. Then I'll be able to send disk8 back to the store. Obviously I'm trying to avoid losing any data in disk7 or disk8. Is this a good approach?

As expected it made no difference. Stuck again with hung hdparm processes. I will try to move drive connection to the sata expansion boards.

The parity drive is 3TB Seagate and there were already 2 x 3TB WD Green drives in the mix. No, I was replacing a 2TB with a 3TB to provide more space in the array. I did not pre-clear it. Edit: I checked and 3TB drives are on motherboard as well as new drive but new one is not using blue sata cable into blue ports. Changed and trying rebuild again.

I replaced a 2TB WD green drive with a 3TB version and while doing a rebuild of the data, it seems to hang after 70%. The web interface does not want to respond and all I can see with ps -ef are processes like hdparm -C /dev/sdl that appear to be hung or defunct root 5112 2190 0 06:40 ? 00:00:00 /usr/sbin/hdparm -C /dev/sdl root 5113 2190 0 06:40 ? 00:00:00 [hdparm] <defunct> root 5114 2190 0 06:40 ? 00:00:00 [hdparm] <defunct> root 5115 2190 0 06:40 ? 00:00:00 [hdparm] <defunct> root 5123 2193 0 06:41 ? 00:00:00 /bin/bash ./s3.sh root 5124 5123 0 06:41 ? 00:00:00 /bin/bash ./s3.sh root 5125 5124 0 06:41 ? 00:00:00 /bin/bash ./s3.sh root 5126 5124 0 06:41 ? 00:00:00 wc -l root 5150 5125 0 06:41 ? 00:00:00 hdparm -C /dev/sdl I can't stop the array and I can't powerdown even from a telnet shell. I've tried hard reboots but the problem persists. Any ideas? I could not spot anything in the syslog Aug 18 15:45:25 Moat emhttp: ST3000DM001-1CH166_####HVN (sda) 2930266584 Aug 18 15:45:25 Moat emhttp: WDC_WD30EZRX-00DC0B0_WD-####6740 (sdb) 2930266584 Aug 18 15:45:25 Moat emhttp: WDC_WD30EZRX-00DC0B0_WD-####3952 (sdc) 2930266584 Aug 18 15:45:25 Moat emhttp: WDC_WD20EARS-00MVWB0_WD-####7613 (sdd) 1953514584 Aug 18 15:45:25 Moat emhttp: WDC_WD20EARS-00MVWB0_WD-####3254 (sdf) 1953514584 Aug 18 15:45:25 Moat emhttp: WDC_WD20EFRX-68AX9N0_WD-####0521 (sdg) 1953514584 Aug 18 15:45:25 Moat emhttp: WDC_WD20EARS-00MVWB0_WD-####1569 (sdh) 1953514584 Aug 18 15:45:25 Moat emhttp: WDC_WD20EARS-00MVWB0_WD-####9546 (sdi) 1953514584 Aug 18 15:45:25 Moat emhttp: WDC_WD20EARS-00S8B1_WD-####7510 (sdj) 1953514584 Aug 18 15:45:25 Moat emhttp: WDC_WD20EARX-00PASB0_WD-####7189 (sdk) 1953514584 Aug 18 15:45:25 Moat emhttp: WDC_WD20EARS-00MVWB0_WD-####5888 (sdl) 1953514584 Aug 18 15:45:25 Moat emhttp: WDC_WD30EZRX-00DC0B0_WD-####3235 (sdm) 2930266584 Aug 18 15:45:25 Moat kernel: mdcmd (1): import 0 8,0 2930266532 ST3000DM001-1CH166_####QHVN Aug 18 15:45:25 Moat kernel: md: import disk0: [8,0] (sda) ST3000DM001-1CH166_####QHVN size: 2930266532 Aug 18 15:45:25 Moat kernel: mdcmd (2): import 1 8,96 1953514552 WDC_WD20EFRX-68AX9N0_WD-####0521 Aug 18 15:45:25 Moat kernel: md: import disk1: [8,96] (sdg) WDC_WD20EFRX-68AX9N0_WD-####0521 size: 1953514552 Aug 18 15:45:25 Moat kernel: mdcmd (3): import 2 8,112 1953514552 WDC_WD20EARS-00MVWB0_WD-####1569 Aug 18 15:45:25 Moat kernel: md: import disk2: [8,112] (sdh) WDC_WD20EARS-00MVWB0_WD-####1569 size: 1953514552 Aug 18 15:45:25 Moat kernel: mdcmd (4): import 3 8,80 1953514552 WDC_WD20EARS-00MVWB0_WD-####3254 Aug 18 15:45:25 Moat kernel: md: import disk3: [8,80] (sdf) WDC_WD20EARS-00MVWB0_WD-####3254 size: 1953514552 Aug 18 15:45:25 Moat kernel: mdcmd (5): import 4 8,128 1953514552 WDC_WD20EARS-00MVWB0_WD-####9546 Aug 18 15:45:25 Moat kernel: md: import disk4: [8,128] (sdi) WDC_WD20EARS-00MVWB0_WD-####9546 size: 1953514552 Aug 18 15:45:25 Moat kernel: mdcmd (6): import 5 8,144 1953514552 WDC_WD20EARS-00S8B1_WD-####7510 Aug 18 15:45:25 Moat kernel: md: import disk5: [8,144] (sdj) WDC_WD20EARS-00S8B1_WD-####7510 size: 1953514552 Aug 18 15:45:25 Moat kernel: mdcmd (7): import 6 8,48 1953514552 WDC_WD20EARS-00MVWB0_WD-####7613 Aug 18 15:45:25 Moat kernel: md: import disk6: [8,48] (sdd) WDC_WD20EARS-00MVWB0_WD-####7613 size: 1953514552 Aug 18 15:45:25 Moat kernel: mdcmd (: import 7 8,32 2930266532 WDC_WD30EZRX-00DC0B0_WD-####3952 Aug 18 15:45:25 Moat kernel: md: import disk7: [8,32] (sdc) WDC_WD30EZRX-00DC0B0_WD-####3952 size: 2930266532 Aug 18 15:45:25 Moat kernel: mdcmd (9): import 8 8,192 2930266532 WDC_WD30EZRX-00DC0B0_WD-####3235 Aug 18 15:45:25 Moat kernel: md: import disk8: [8,192] (sdm) WDC_WD30EZRX-00DC0B0_WD-####3235 size: 2930266532 Aug 18 15:45:25 Moat kernel: mdcmd (10): import 9 8,176 1953514552 WDC_WD20EARS-00MVWB0_WD-####5888 Aug 18 15:45:25 Moat kernel: md: import disk9: [8,176] (sdl) WDC_WD20EARS-00MVWB0_WD-####5888 size: 1953514552 Aug 18 15:45:25 Moat kernel: mdcmd (11): import 10 8,16 2930266532 WDC_WD30EZRX-00DC0B0_WD-####6740 Aug 18 15:45:25 Moat kernel: md: import disk10: [8,16] (sdb) WDC_WD30EZRX-00DC0B0_WD-####6740 size: 2930266532 Aug 18 15:45:25 Moat kernel: mdcmd (12): import 11 8,160 1953514552 WDC_WD20EARX-00PASB0_WD-####7189 Aug 18 15:45:25 Moat kernel: md: import disk11: [8,160] (sdk) WDC_WD20EARX-00PASB0_WD-####7189 size: 1953514552 Aug 18 15:45:03 Moat kernel: sd 1:0:4:0: [sdj] Attached SCSI disk Aug 18 15:45:03 Moat kernel: sd 1:0:5:0: [sdk] Attached SCSI disk Aug 18 15:45:03 Moat logger: /etc/rc.d/rc.inet1: /sbin/ifconfig lo 127.0.0.1 Aug 18 15:45:03 Moat logger: /etc/rc.d/rc.inet1: /sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo Aug 18 15:45:03 Moat logger: /etc/rc.d/rc.inet1: /sbin/ifconfig eth0 192.168.1.55 broadcast 192.168.1.255 netmask 255.255.255.0 Aug 18 15:45:03 Moat kernel: r8168: eth0: link down Aug 18 15:45:03 Moat logger: /etc/rc.d/rc.inet1: /sbin/route add default gw 192.168.1.1 metric 1 Aug 18 15:45:03 Moat rpc.statd[1222]: Version 1.2.2 starting Aug 18 15:45:03 Moat sm-notify[1223]: Version 1.2.2 starting Aug 18 15:45:03 Moat rpc.statd[1222]: Failed to read /var/lib/nfs/state: Success Aug 18 15:45:03 Moat rpc.statd[1222]: Initializing NSM state Aug 18 15:45:03 Moat rpc.statd[1222]: Running as root. chown /var/lib/nfs to choose different user Aug 18 15:45:03 Moat ntpd[1238]: ntpd [email protected] Sat Apr 24 19:01:14 UTC 2010 (1) Aug 18 15:45:03 Moat ntpd[1239]: proto: precision = 0.260 usec Aug 18 15:45:03 Moat ntpd[1239]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 Aug 18 15:45:03 Moat ntpd[1239]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 Aug 18 15:45:03 Moat ntpd[1239]: Listen normally on 1 lo 127.0.0.1 UDP 123 Aug 18 15:45:03 Moat ntpd[1239]: Listen normally on 2 eth0 192.168.1.55 UDP 123 Aug 18 15:45:03 Moat acpid: starting up with proc fs Aug 18 15:45:03 Moat acpid: skipping conf file /etc/acpi/events/. Aug 18 15:45:03 Moat acpid: skipping conf file /etc/acpi/events/.. Aug 18 15:45:03 Moat acpid: 1 rule loaded Aug 18 15:45:03 Moat acpid: waiting for events: event logging is off Aug 18 15:45:03 Moat crond[1261]: /usr/sbin/crond 4.4 dillon's cron daemon, started with loglevel notice Aug 18 15:45:06 Moat kernel: r8168: eth0: link up Aug 18 15:45:06 Moat kernel: r8168: eth0: link up Aug 18 15:45:25 Moat logger: installing plugin: * Aug 18 15:45:25 Moat logger: Aug 18 15:45:25 Moat logger: Warning: simplexml_load_file(): I/O warning : failed to load external entity "/boot/config/plugins/ *.plg" in /usr/local/sbin/installplg on line 13 Aug 19 01:57:47 Moat kernel: sd 1:0:7:0: task abort: SUCCESS scmd(f0cac180) ... repeating ... Aug 19 13:43:59 Moat kernel: sd 1:0:7:0: attempting task abort! scmd(f0dea180) Aug 19 13:43:59 Moat kernel: sd 1:0:7:0: [sdm] CDB: cdb[0]=0x28: 28 00 f8 9f 44 d0 00 04 00 00 Aug 19 13:43:59 Moat kernel: scsi target1:0:7: handle(0x0010), sas_address(0x4433221105000000), phy(5) Aug 19 13:43:59 Moat kernel: scsi target1:0:7: enclosure_logical_id(0x500304800ee2af00), slot(5) Aug 19 13:43:59 Moat kernel: sd 1:0:7:0: task abort: SUCCESS scmd(f0dea180) Aug 19 13:44:30 Moat kernel: sd 1:0:7:0: attempting task abort! scmd(f0dea180) Aug 19 13:44:30 Moat kernel: sd 1:0:7:0: [sdm] CDB: cdb[0]=0x28: 28 00 f8 9f 44 d0 00 04 00 00 Aug 19 13:44:30 Moat kernel: scsi target1:0:7: handle(0x0010), sas_address(0x4433221105000000), phy(5) Aug 19 13:44:30 Moat kernel: scsi target1:0:7: enclosure_logical_id(0x500304800ee2af00), slot(5) Aug 19 13:44:30 Moat kernel: sd 1:0:7:0: task abort: SUCCESS scmd(f0dea180)

COOLER MASTER GX 450W RS450-ACAAD3-US This is a deal on newegg.ca not .com and it expires Jan 31st. Price is regularly $60, now $45 CDN plus manufacturer $15 USD credit card, so effectively $15 for 450W High Efficiency Design

Just wait, no doubt it's because they will put out an Antec 1200 Two, like the ANtec 300 Too and Antec 900 Two, which have hardware support for USB 3.0 at the front. I love the Antec 900s (got 3) but you do need to flatten the 4 tabs to fit in the 5x3 cages. Once in they slide in and out no problem. I am now looking to replace 120mm fans for quieter ones.

I don't see mention of Startech's cages. I have 2 SATABAY5BK and was quite happy with them except I learned trayless is much easier for swapping, Temperature of fans is adjustable with L/M/H and I had no problems with them. Discontinued now. I also have a SBAY5BK (just been discontinued) which is trayless. Works great but no fan control. The two 3" fans are not enough and I found my drives going to 35-40C compared to 27-35C for other drives in the case. Even though they are both discontinued now, their website has no 5x3 replacement for them. EDIT: modified post to include links to the products.

I am unable to determine if this one is trayless, is it?

Just noticed the 1.1 release changes -- thanks for -W and -V A few posts back you say we no longer need to use -A if no jumper is installed -- could you please add that to release notes. Now a problem: I was in Step 2 of pre-clearing a WD Green 2 TB (previously used with content) and the server did an emergency shutdown on me. Normally I would just go ahead and restart all over, but the problem is that 'fdisk -l' is showing me strange results: Disk /dev/sde: 2000.3 GB, 2000398934016 bytes 255 heads, 63 sectors/track, 243201 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System Disk /dev/sdf: 2000.3 GB, 2000397852160 bytes 255 heads, 63 sectors/track, 243201 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Disk sde is the one I was working on, but sdf is supposed to a previously pre-cleared 1 TB Seagate HDD. I was going to add sdf to the array but can't now, even though the unRAID menu shows sdf correctly listed as expected. Should I just go ahead and redo sde and then reboot -- hopefully things will work out, or what else should I try?

Well, the first disk finished ok, but the 2nd disk continued to run at 4 MB/s in Step 2. Even though it's a writing to disk stage, I decided to kill it at 15%. I am now running 2nd disk alone -- hopefully no slow access this time.

No, running on 4.7b1. After 32 hrs, the first disk moved on to Step 10 and is running at 71 MB/s, but the second disk is still on Step 2 running at 4 MB/s. Hopefully disk 2 speeds up when the first disk is finished. For now I'm not too worried about it, I just find it odd.

No, nothing in dmesg or syslog since the process started last night.

This seems odd to me... I previously had 2 x WD Green 2TB HDD pre-cleared for 5.0b2, and now I am using the latest script with -A option to pre-clear them for 4.7b1. I started both at the same time, expecting to take 2 full days (48 hours), usually 30-33 hrs individually. During step 2 I get Disk 2 Disk Temperature: 31C, Elapsed Time: 20:20:41 942476+0 records in 942476+0 records out 1976515428352 bytes (2.0 TB) copied, 36267.5 s, 54.5 MB/s Wrote 1,976,515,428,352 bytes out of 2,000,398,934,016 bytes (98% Done) And disk 1 is *slow* with Disk Temperature: 30C, Elapsed Time: 20:24:23 66187+1 records in 66187+1 records out 138805964800 bytes (139 GB) copied, 34047.7 s, 4.1 MB/s Wrote 138,805,964,800 bytes out of 2,000,398,934,016 bytes (6% Done) As you can see, one is almost done (at 55MB/s) while the other is only 6% (at 4.1 MB/s). Hopefully this is just system related with priority allocation and not an indication of potential HDD problem.

Nothing special need be done with the Samsung, unless it is their F4 model. It must have its firmware updated as it silently may corrupt your data if not updated. See this thread: http://lime-technology.com/forum/index.php?topic=9339.0 Then, just use the "-A" option. Ok, but I did mention Seagate, not Samsung

If we currently have an unjumpered WD Green drive not in the array, and it has already been pre-cleared for 4.6, what do we need to do before using the .99c pre-cleared.sh with the -A for sector 64 use in 4.7b1? Do we need to use "dd ..." to clear the first sector, or just go ahead and use the "-A" option? Is it the same for a 2TB Seagate HDD which has no jumper option?

The difference is that I get out4= 00000 and out5= 00000, 0+0 records in & out, 0 bytes copied. I tried some commands and got a script error... root@Tower:/boot/config# ./preclear_disk.sh -v ./preclear_disk.sh version: .9.8 root@Tower:/boot/config# ./preclear_disk.sh -t /dev/sda Pre-Clear unRAID Disk ######################################################################## ######################################################################## ./preclear_disk.sh: line 825: [: too many arguments ============================================================================ == == Disk /dev/sda is NOT precleared == ============================================================================ I was running this pre-clear at the same time as other disks. Should I try again by itself? Is there a way to bypass *all* the tests? BTW, I did not jumper it because I am setting things up to get ready for 5.0b3 to support these WD Green drives. Yes, the drive has stopped responding. (and the script was not coded to deal with that very elegantly) Most people find they'll need to power cycle the drive to get it to respond again. Even after that, many have had to clear the first few sectors to get it to respond sanely after changing the jumper (or adding it after the drive has been used without it being installed) Basically, we've found it does not even respond to anything when locked up. Not even an fdisk -l /dev/sdb will get complete results until you power cycle. As far as skipping "tests" sorry... can't unless you don't want to clear the drive and ensure it is cleared. Joe L. I hate re-quoting long posts but this goes back 4-5 pages. Anyways, after rebooting I went into fdisk and removed the existing empty NTFS partition that I had previously created when I first got it. Now after 30+ hours with a preclear check (w/o jumper), it comes out just fine... ready to use.

I would search in this thread but 38 pages is too much and I haven't found a way for this forum to allow me to search in a specific thread. I started a preclear -c 3 on a drive but it's only nearing the end of the first cycle. Could I kill the script during the 2nd cycle in order to do a reboot, and then I can rerun preclear again? One more... If I have already run a full cycle, is it acceptabe to use the '-n' next time to speed things up?

Here's some results from a 1TB Seagate, not sure what to make of the "Raw_Read_Error_Rate" root@Tower:/tmp# diff smart_start2036 smart_finish2036 |more 54c54 < 1 Raw_Read_Error_Rate 0x000f 117 099 006 Pre-fail Always - 143105661 --- > 1 Raw_Read_Error_Rate 0x000f 114 099 006 Pre-fail Always - 78689498 58c58 < 7 Seek_Error_Rate 0x000f 075 060 030 Pre-fail Always - 36206913 --- > 7 Seek_Error_Rate 0x000f 075 060 030 Pre-fail Always - 36319190 And running smartctl --all /dev/sdd gives User Capacity: 1,000,204,886,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is: Wed Jan 5 00:26:03 2011 MST SMART support is: Available - device has SMART capability. SMART support is: Enabled ... SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 114 099 006 Pre-fail Always - 78711073 3 Spin_Up_Time 0x0003 100 100 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 101 5 Reallocated_Sector_Ct 0x0033 095 095 036 Pre-fail Always - 216 7 Seek_Error_Rate 0x000f 075 060 030 Pre-fail Always - 36349186 9 Power_On_Hours 0x0032 089 089 000 Old_age Always - 9676 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 037 020 Old_age Always - 101 ... SMART Error Log Version: 1 No Errors Logged ... There are a lot of Raw_Read_Error_Rate however it went down?

Sure, post here or PM me with attachment.

OK thanks for info on /tmp files, I got info from them although it's hard to tell which drive it belongs to. It would be helpful to new users about syslog output if it was mentioned in the script's help output. BTW, shift-PageUp etc does not work on console. I only have 5.0b2 with nothing else installed.

Looks like you're right about that, 'fdisk -l' no longer shows sda. I'll reboot once the other drive is done with preclear'ing.

I am getting similar results (after 45 hours) like this on a WD Green 2TB drive (no jumpers) The difference is that I get out4= 00000 and out5= 00000, 0+0 records in & out, 0 bytes copied. I tried some commands and got a script error... root@Tower:/boot/config# ./preclear_disk.sh -v ./preclear_disk.sh version: .9.8 root@Tower:/boot/config# ./preclear_disk.sh -t /dev/sda Pre-Clear unRAID Disk ######################################################################## ######################################################################## ./preclear_disk.sh: line 825: [: too many arguments ============================================================================ == == Disk /dev/sda is NOT precleared == ============================================================================ I was running this pre-clear at the same time as other disks. Should I try again by itself? Is there a way to bypass *all* the tests? BTW, I did not jumper it because I am setting things up to get ready for 5.0b3 to support these WD Green drives.