August 24, 201015 yr Hi, I've been running without problems for about a year... and I'm just today having an issue with the first drive in the array coming up as unformatted. Here is what I was doing before this happened, and what I did that probably screwed it up more =) : - Shut down the machine - Removed two drives (with nothing on them... to use for something else) - Started back up, removed the missing drives and started rebuilding parity. - Left it for a few hours. - Noticed that the first drive had loads of errors next to it. - Stoped the parity building. - Looked at the logs (i could see some messages saying "stripe read error" regarding the drive (disk1 - sdc) - Googled and read a lot... deciding it might be a cable or power problem. - Shut down and played with the cables. - Started back up.. - Drive is "unformatted" - Updated to 4.5.6 from 4.5.3 - Still unformatted - Ran reiserfsck /dev/md1, which said "The problem has occurred looks like a hardware problem." - Ran reiserfsck /dev/sdc, which said "reiserfs_open: the reiserfs superblock cannot be found on /dev/sdc." At some point in this (cant remember when), i ran reiserfsck /dev/sdc and it went through and said no problems! It listed a lot of files so I think it was reading it right. Could someone please advise what I should be checking next? Could it still be a cable thing? I'm using sas>4xsata cables but could find a sata cable to plug into the MB... syslog-2010-08-24.txt
August 24, 201015 yr Are you using Gigabyte MB? The following ata2.00 is your sdc disk which is for md1. You have same model disks however two of them have different size. that is a very big no, no in unRAID. Refer to following two links for more information. http://lime-technology.com/forum/index.php?topic=6806.0 http://lime-technology.com/forum/index.php?topic=5072.msg46903#msg46903 ---------------------------------------------------------------------------------------------------------------------------------- ata1.00: HPA detected: current 2930275055, native 2930277168 Aug 24 14:16:01 Destructor kernel: ata1.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Aug 24 14:16:01 Destructor kernel: ata1.00: 2930275055 sectors, multi 0: LBA48 NCQ (depth 31/32) Aug 24 14:16:01 Destructor kernel: ata1.00: configured for UDMA/133 ata2.00: HPA detected: current 2930275055, native 2930277168 Aug 24 14:16:01 Destructor kernel: ata2.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Aug 24 14:16:01 Destructor kernel: ata2.00: 2930275055 sectors, multi 0: LBA48 NCQ (depth 31/32) Aug 24 14:16:01 Destructor kernel: ata2.00: configured for UDMA/133 Aug 24 14:16:01 Destructor kernel: scsi 0:0:1:0: Direct-Access ATA ST31500341AS CC1H PQ: 0 ANSI: 5 Aug 24 14:16:01 Destructor kernel: md: import disk0: [8,96] (sdg) ST31500341AS 9VS1XSAK offset: 63 size: 1465138552 Aug 24 14:16:01 Destructor kernel: md: import disk1: [8,32] (sdc) ST31500341AS 9VS1SD8D offset: 63 size: 1465137496 Aug 24 14:16:01 Destructor kernel: md: import disk2: [8,16] (sdb) ST31500341AS 9VS2AG16 offset: 63 size: 1465137496 Aug 24 14:16:01 Destructor kernel: md: import disk3: [8,48] (sdd) ST31500341AS 9VS2AZ0P offset: 63 size: 1465138552 Aug 24 14:16:01 Destructor kernel: md: import disk4: [8,64] (sde) ST31500341AS 9VS2AXMV offset: 63 size: 1465138552 Aug 24 14:16:01 Destructor kernel: md: import disk5: [8,80] (sdf) ST31500341AS 9VS20CFR offset: 63 size: 1465138552
August 24, 201015 yr If I am not mistaken, you should upgrade your MB bios (if you are running a Gigabyte MB). The latest BIOS sets HPA to default to "Disabled". That way it wont write stuff to your hard drives like it is doing on sdb and sdc disks.
August 25, 201015 yr Author If I am not mistaken, you should upgrade your MB bios (if you are running a Gigabyte MB). The latest BIOS sets HPA to default to "Disabled". That way it wont write stuff to your hard drives like it is doing on sdb and sdc disks. That's a good move, one i really should have done at the beginnimg and I think ill do now but it wont fix the current problem right? Disk 1 and 2 were always slightly smaller I believe and it didn't seem to cause issues. With the parity out of action I need to fix the disk somehow. I can do that superblock fix but I thought id check first just in case it could still be fine and having trouble from cables or something.
August 30, 201015 yr So, should I attempt the superblock fix? NO... not on /dev/sdc, since it is not where the partition is located. The superblock may not be bad, you just used the wrong command. If running with the disk assigned to the array, you must use the /dev/md1 device If running reiserfsck on the raw disk partition, you must use partition1 ( /dev/sdc1 ). reiserfsck --check /dev/sdc1 (note the trailing 1 indicating the first partition) You can fix the HPA issue after you get the array back to a non-degraded state, but before you do this, you'll need to upgrade the BIOS on your MB.
August 30, 201015 yr Don't mean to hijack this thread but I have a problem also with unformatted disk. Its the first disk in my array from what it seems. My son powered down the server and when I brought it back up I had to restore. Did that but now I have this unformatted drive and a bunch of errors on my parity and disk 1. Any advice would be great now. Don't want to lose any of my data I'm not sure on what I should do now?
August 30, 201015 yr Don't mean to hijack this thread but I have a problem also with unformatted disk. Its the first disk in my array from what it seems. My son powered down the server and when I brought it back up I had to restore. Did that but now I have this unformatted drive and a bunch of errors on my parity and disk 1. Any advice would be great now. Don't want to lose any of my data I'm not sure on what I should do now? first thing... unformatted simply indicates the drive is not mounted. On my server when I had to force a power off it took nearly 15 minutes to replay all the transactions in the file-system journal before it was finally mounted. So.... Use the refresh button on your browser. It might now be mounted. If not, and if it has been more than 15-20 minutes of so, post a syslog. Instructions under troubleshooting in the wiki. Now, I'm not sure what you mean by "You had to Restore" Please elaborate on exactly what you did. If you are currently performing a parity check as a result of pressing the button labeled as "Restore" then cancel the check as soon as possible.
August 30, 201015 yr Do NOT start your array either... not until we know what you've done. From your screen shot, it might be too late for that warning.
August 30, 201015 yr OK... lots of errors... in many areas... Apparently there is an issue with IRQ19. But that is not likely to be the cause of your disk failures, but who knows??? Aug 30 12:21:36 Tower kernel: irq 19: nobody cared (try booting with the "irqpoll" option) Aug 30 12:21:36 Tower kernel: Pid: 640, comm: modprobe Not tainted 2.6.31.6-unRAID #6 Aug 30 12:21:36 Tower kernel: Call Trace: Aug 30 12:21:36 Tower kernel: [<c10432c9>] __report_bad_irq+0x2e/0x6f Aug 30 12:21:36 Tower kernel: [<c10433ff>] note_interrupt+0xf5/0x13a Aug 30 12:21:36 Tower kernel: [<c1043ab5>] handle_fasteoi_irq+0x5f/0x9d Aug 30 12:21:36 Tower kernel: [<c1004b6c>] handle_irq+0x1a/0x22 Aug 30 12:21:36 Tower kernel: [<c1004371>] do_IRQ+0x40/0x96 Aug 30 12:21:36 Tower kernel: [<c1002f29>] common_interrupt+0x29/0x30 Aug 30 12:21:36 Tower kernel: handlers: Aug 30 12:21:36 Tower kernel: [<c11dd44f>] (usb_hcd_irq+0x0/0x5d) Aug 30 12:21:36 Tower kernel: Disabling IRQ #19 As I said, IRQ 19 was disabled... but then I see that it might also be used by one of your sata controllers? Aug 30 12:21:36 Tower kernel: sata_sil24 0000:04:00.0: version 1.1 Aug 30 12:21:36 Tower kernel: sata_sil24 0000:04:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 Aug 30 12:21:36 Tower kernel: sata_sil24 0000:04:00.0: setting latency timer to 64 Aug 30 12:21:36 Tower kernel: irq 19: nobody cared (try booting with the "irqpoll" option) Aug 30 12:21:36 Tower kernel: Pid: 0, comm: swapper Not tainted 2.6.31.6-unRAID #6 Aug 30 12:21:36 Tower kernel: Call Trace: Aug 30 12:21:36 Tower kernel: [<c10432c9>] __report_bad_irq+0x2e/0x6f Aug 30 12:21:36 Tower kernel: [<c10433ff>] note_interrupt+0xf5/0x13a Aug 30 12:21:36 Tower kernel: [<c1043ab5>] handle_fasteoi_irq+0x5f/0x9d Aug 30 12:21:36 Tower kernel: [<c1004b6c>] handle_irq+0x1a/0x22 Aug 30 12:21:36 Tower kernel: [<c1004371>] do_IRQ+0x40/0x96 Aug 30 12:21:36 Tower kernel: [<c1002f29>] common_interrupt+0x29/0x30 Aug 30 12:21:36 Tower kernel: [<c1008773>] ? mwait_idle+0x4c/0x52 Aug 30 12:21:36 Tower kernel: [<c1001a06>] cpu_idle+0x3a/0x4e Aug 30 12:21:36 Tower kernel: [<c127866f>] rest_init+0x53/0x55 Aug 30 12:21:36 Tower kernel: [<c13d97e2>] start_kernel+0x27b/0x280 Aug 30 12:21:36 Tower kernel: [<c13d906a>] i386_start_kernel+0x6a/0x6f Aug 30 12:21:36 Tower kernel: handlers: Aug 30 12:21:36 Tower kernel: [<c11dd44f>] (usb_hcd_irq+0x0/0x5d) Aug 30 12:21:36 Tower kernel: [<f8245882>] (sil24_interrupt+0x0/0x44f [sata_sil24]) Aug 30 12:21:36 Tower kernel: Disabling IRQ #19 Aug 30 12:21:36 Tower kernel: ata1: SATA link down (SStatus 0 SControl 0) Aug 30 12:21:36 Tower kernel: ata2: SATA link down (SStatus 0 SControl 0) It seems to think the parity disk was replaced: Aug 30 12:21:36 Tower kernel: md: import disk0: [8,160] (sdk) ST31000340AS 9QJ0K126 offset: 63 size: 976762552 Aug 30 12:21:36 Tower kernel: md: disk0 replaced Apparently you pressed the button labeled as "Restore" It is poorly labeled. It is actually an "Initialize a New Disk Configuration and Immediately Invalidate any Parity Calculations Based on Any Prior Disk Configuration" button. Aug 30 12:22:22 Tower kernel: read_file: error 2 opening /boot/config/super.dat Aug 30 12:22:22 Tower kernel: md: could not read superblock from /boot/config/super.dat Aug 30 12:22:22 Tower kernel: md: initializing superblock Aug 30 12:22:22 Tower kernel: md: import disk0: [8,160] (sdk) ST31000340AS 9QJ0K126 offset: 63 size: 976762552 Aug 30 12:22:22 Tower kernel: md: disk0 new disk Aug 30 12:22:22 Tower kernel: md: import disk1: [8,192] (sdm) WDC WD10EACS-00ZJB0 WD-WCASJ1858813 offset: 63 size: 976762552 Aug 30 12:22:22 Tower kernel: md: disk1 new disk Aug 30 12:22:22 Tower kernel: md: import disk2: [8,176] (sdl) WDC WD10EACS-00D6B0 WD-WCAU40449714 offset: 63 size: 976762552 Aug 30 12:22:22 Tower kernel: md: disk2 new disk Aug 30 12:22:22 Tower kernel: md: import disk3: [8,208] (sdn) ST3500630AS 9QG8LSEZ offset: 63 size: 488386552 Aug 30 12:22:22 Tower kernel: md: disk3 new disk Aug 30 12:22:22 Tower kernel: md: import disk5: [8,32] (sdc) ST3500630AS 6QG1EJ77 offset: 63 size: 488386552 Aug 30 12:22:22 Tower kernel: md: disk5 new disk Aug 30 12:22:22 Tower kernel: md: import disk6: [8,48] (sdd) WDC WD10EACS-00D6B1 WD-WCAU43993513 offset: 63 size: 976762552 Aug 30 12:22:22 Tower kernel: md: disk6 new disk Aug 30 12:22:22 Tower kernel: md: import disk7: [8,80] (sdf) ST3500630AS 9QG8LSDR offset: 63 size: 488386552 Aug 30 12:22:22 Tower kernel: md: disk7 new disk Aug 30 12:22:22 Tower kernel: md: import disk8: [8,64] (sde) WDC WD10EACS-00D6B1 WD-WCAU44187381 offset: 63 size: 976762552 Aug 30 12:22:22 Tower kernel: md: disk8 new disk Aug 30 12:22:22 Tower kernel: md: import disk9: [8,112] (sdh) WDC WD10EACS-00D6B1 WD-WCAU44186592 offset: 63 size: 976762552 Aug 30 12:22:22 Tower kernel: md: disk9 new disk Aug 30 12:22:22 Tower kernel: md: import disk10: [8,96] (sdg) WDC WD10EACS-00D6B1 WD-WCAU43977062 offset: 63 size: 976762552 Aug 30 12:22:22 Tower kernel: md: disk10 new disk Aug 30 12:22:22 Tower kernel: md: import disk11: [8,128] (sdi) WDC WD10EACS-00D6B1 WD-WCAU43995695 offset: 63 size: 976762552 Aug 30 12:22:22 Tower kernel: md: disk11 new disk Aug 30 12:22:22 Tower kernel: md: import disk12: [8,0] (sda) ST31000340AS 5QJ11NW0 offset: 63 size: 976762552 Aug 30 12:22:22 Tower kernel: md: disk12 new disk So now it thinks it is a completely new set of disks. And parity was thrown away... and a new parity sync started. But... there are tons of errors and the disk controllers keep trying be reset by the kernel. Aug 30 12:23:58 Tower kernel: ata13.00: exception Emask 0x50 SAct 0x0 SErr 0x4050802 action 0xe frozen Aug 30 12:23:58 Tower kernel: ata13.00: SError: { RecovComm HostInt PHYRdyChg CommWake DevExch } Aug 30 12:23:58 Tower kernel: ata13.00: cmd ca/00:00:3f:b7:01/00:00:00:00:00/e0 tag 0 dma 131072 out Aug 30 12:23:58 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/10 Emask 0x54 (ATA bus error) Aug 30 12:23:58 Tower kernel: ata13.00: status: { DRDY } Aug 30 12:23:58 Tower kernel: ata13.00: hard resetting link Aug 30 12:23:59 Tower kernel: ata13.01: hard resetting link Aug 30 12:24:05 Tower kernel: ata13.00: link is slow to respond, please be patient (ready=0) Aug 30 12:24:09 Tower kernel: ata13.00: SRST failed (errno=-16) Aug 30 12:24:09 Tower kernel: ata13.00: hard resetting link Aug 30 12:24:09 Tower kernel: ata13.01: hard resetting link Aug 30 12:24:15 Tower kernel: ata13.00: link is slow to respond, please be patient (ready=0) Aug 30 12:24:19 Tower kernel: ata13.00: SRST failed (errno=-16) Aug 30 12:24:19 Tower kernel: ata13.00: hard resetting link Aug 30 12:24:19 Tower kernel: ata13.01: hard resetting link Aug 30 12:24:25 Tower kernel: ata13.00: link is slow to respond, please be patient (ready=0) Aug 30 12:24:29 Tower kernel: ata13.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 30 12:24:29 Tower kernel: ata13.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 30 12:24:29 Tower kernel: ata13.00: configured for UDMA/133 Aug 30 12:24:29 Tower kernel: ata13.01: configured for UDMA/133 Aug 30 12:24:29 Tower kernel: ata13.00: device reported invalid CHS sector 0 Aug 30 12:24:29 Tower kernel: ata13: EH complete Aug 30 12:25:31 Tower kernel: ata13.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0xe frozen Aug 30 12:25:31 Tower kernel: ata13.00: SError: { RecovComm PHYRdyChg CommWake DevExch } Aug 30 12:25:31 Tower kernel: ata13.00: cmd ca/00:00:3f:c0:01/00:00:00:00:00/e0 tag 0 dma 131072 out Aug 30 12:25:31 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/10 Emask 0x14 (ATA bus error) Aug 30 12:25:31 Tower kernel: ata13.00: status: { DRDY } Aug 30 12:25:31 Tower kernel: ata13.00: hard resetting link Aug 30 12:25:31 Tower kernel: ata14.00: exception Emask 0x50 SAct 0x0 SErr 0x4050802 action 0xe frozen Aug 30 12:25:31 Tower kernel: ata14.00: SError: { RecovComm HostInt PHYRdyChg CommWake DevExch } Aug 30 12:25:31 Tower kernel: ata14.00: cmd c8/00:10:57:c4:00/00:00:00:00:00/e0 tag 0 dma 8192 in Aug 30 12:25:31 Tower kernel: res 40/00:ff:00:00:00/00:00:00:00:00/10 Emask 0x54 (ATA bus error) Aug 30 12:25:31 Tower kernel: ata14.00: status: { DRDY } Aug 30 12:25:31 Tower kernel: ata14.00: hard resetting link Aug 30 12:25:33 Tower kernel: ata13.01: hard resetting link Aug 30 12:25:33 Tower kernel: ata14.00: COMRESET failed (errno=-32) Aug 30 12:25:33 Tower kernel: ata14.00: reset failed (errno=-32), retrying in 8 secs Aug 30 12:25:41 Tower kernel: ata14.00: limiting SATA link speed to 1.5 Gbps Aug 30 12:25:41 Tower kernel: ata14.00: hard resetting link Aug 30 12:25:41 Tower kernel: ata13.00: SRST failed (errno=-16) Aug 30 12:25:41 Tower kernel: ata13.00: hard resetting link Aug 30 12:25:42 Tower kernel: ata14.01: hard resetting link Aug 30 12:25:42 Tower kernel: ata13.01: hard resetting link Aug 30 12:25:42 Tower kernel: ata14.00: SATA link down (SStatus 0 SControl 310) Aug 30 12:25:42 Tower kernel: ata14.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 30 12:25:42 Tower kernel: ata13.00: SATA link down (SStatus 0 SControl 300) Aug 30 12:25:42 Tower kernel: ata13.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 30 12:25:47 Tower kernel: ata14.00: hard resetting link Aug 30 12:25:47 Tower kernel: ata13.00: hard resetting link Aug 30 12:25:48 Tower kernel: ata14.01: hard resetting link Aug 30 12:25:48 Tower kernel: ata13.01: hard resetting link Aug 30 12:25:48 Tower kernel: ata14.00: SATA link down (SStatus 0 SControl 310) Aug 30 12:25:48 Tower kernel: ata14.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 30 12:25:48 Tower kernel: ata13.00: SATA link down (SStatus 0 SControl 300) Aug 30 12:25:48 Tower kernel: ata13.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 30 12:25:48 Tower kernel: ata13.00: limiting SATA link speed to 1.5 Gbps Aug 30 12:25:53 Tower kernel: ata14.00: hard resetting link Aug 30 12:25:53 Tower kernel: ata13.00: hard resetting link Aug 30 12:25:54 Tower kernel: ata14.01: hard resetting link Aug 30 12:25:54 Tower kernel: ata13.01: hard resetting link Aug 30 12:25:54 Tower kernel: ata14.00: SATA link down (SStatus 0 SControl 310) Aug 30 12:25:54 Tower kernel: ata14.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 30 12:25:54 Tower kernel: ata13.00: SATA link down (SStatus 0 SControl 310) Aug 30 12:25:54 Tower kernel: ata13.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 30 12:25:54 Tower kernel: ata14.00: disabled Aug 30 12:25:54 Tower kernel: ata13.00: disabled Aug 30 12:25:59 Tower kernel: ata14.00: hard resetting link Aug 30 12:25:59 Tower kernel: ata13.00: hard resetting link Aug 30 12:25:59 Tower kernel: ata14.01: hard resetting link Aug 30 12:25:59 Tower kernel: ata13.01: hard resetting link Aug 30 12:26:00 Tower kernel: ata14.00: SATA link down (SStatus 0 SControl 300) Aug 30 12:26:00 Tower kernel: ata14.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 30 12:26:00 Tower kernel: ata13.00: SATA link down (SStatus 0 SControl 300) Aug 30 12:26:00 Tower kernel: ata13.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Aug 30 12:26:00 Tower emhttp: disk_temperature: open: No such device or address Aug 30 12:26:00 Tower kernel: ata13.01: configured for UDMA/133 Aug 30 12:26:00 Tower kernel: ata13.00: device reported invalid CHS sector 0 Aug 30 12:26:00 Tower kernel: sd 13:0:0:0: [sdk] Result: hostbyte=0x00 driverbyte=0x08 Aug 30 12:26:00 Tower kernel: sd 13:0:0:0: [sdk] Sense Key : 0xb [current] [descriptor] Aug 30 12:26:00 Tower kernel: Descriptor sense data with sense descriptors (in hex): Aug 30 12:26:00 Tower kernel: 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 Aug 30 12:26:00 Tower kernel: 00 00 00 00 Aug 30 12:26:00 Tower kernel: sd 13:0:0:0: [sdk] ASC=0x0 ASCQ=0x0 Aug 30 12:26:00 Tower kernel: end_request: I/O error, dev sdk, sector 114751 Aug 30 12:26:00 Tower kernel: sd 13:0:0:0: rejecting I/O to offline device Aug 30 12:26:00 Tower kernel: ata13: EH complete Aug 30 12:26:00 Tower kernel: sd 13:0:0:0: rejecting I/O to offline device Aug 30 12:26:00 Tower last message repeated 13 times Aug 30 12:26:00 Tower kernel: sd 13:0:0:0: [sdk] Unhandled error code Aug 30 12:26:00 Tower kernel: sd 13:0:0:0: [sdk] Result: hostbyte=0x01 driverbyte=0x00 Aug 30 12:26:00 Tower kernel: end_request: I/O error, dev sdk, sector 115007 Aug 30 12:26:00 Tower kernel: md: disk0 write error Aug 30 12:26:00 Tower kernel: handle_stripe write error: 114688/0, count: 1 Aug 30 12:26:00 Tower kernel: md: disk0 write error Aug 30 12:26:00 Tower kernel: md: md_do_sync: got signal, exit... Aug 30 12:26:00 Tower kernel: handle_stripe write error: 114696/0, count: 1 Aug 30 12:26:00 Tower kernel: md: disk0 write error Aug 30 12:26:00 Tower kernel: handle_stripe write error: 114704/0, count: 1 Aug 30 12:26:00 Tower kernel: md: disk0 write error And all the writes to the parity disk fail... so it is taken off-line. AND the attempt to mount disk2 fails as there is file-system damage Aug 30 12:26:00 Tower kernel: lost page write due to I/O error on md1 Aug 30 12:26:00 Tower kernel: REISERFS warning (device md1): journal-1226 journal_read_transaction: REPLAY FAILURE, fsck required! buffer write failed Aug 30 12:26:00 Tower kernel: REISERFS warning (device md1): reiserfs-2006 journal_init: Replay Failure, unable to mount Aug 30 12:26:00 Tower kernel: REISERFS warning (device md1): sh-2022 reiserfs_fill_super: unable to initialize journal space Aug 30 12:26:00 Tower kernel: sd 14:0:0:0: rejecting I/O to offline device Aug 30 12:26:00 Tower last message repeated 2 times Aug 30 12:26:00 Tower kernel: sd 14:0:0:0: [sdm] READ CAPACITY(16) failed Aug 30 12:26:00 Tower kernel: sd 14:0:0:0: [sdm] Result: hostbyte=0x01 driverbyte=0x00 Aug 30 12:26:00 Tower kernel: sd 14:0:0:0: [sdm] Sense not available. Aug 30 12:26:00 Tower kernel: sd 14:0:0:0: rejecting I/O to offline device Aug 30 12:26:00 Tower last message repeated 2 times Aug 30 12:26:00 Tower kernel: sd 14:0:0:0: [sdm] READ CAPACITY failed Aug 30 12:26:00 Tower kernel: sd 14:0:0:0: [sdm] Result: hostbyte=0x01 driverbyte=0x00 Aug 30 12:26:00 Tower kernel: sd 14:0:0:0: [sdm] Sense not available. Aug 30 12:26:00 Tower kernel: sd 14:0:0:0: rejecting I/O to offline device With all this in mind... you've got a pretty decent mess. You've got hardware issues, and software ones. You probably do not have any parity protection at all. (You asked it be invalidated when you pressed "Restore") Therefore, the only thing you can do right now is to attempt to fix the file-system on disk2. (If it responds) You can try the procedure described in the wiki here: http://lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems You'll be operating on /dev/md2 since disk2 is the one needing repair. Post back the results of the initial reiserfsck --check /dev/md2 command. Do not proceed until you get guidance. Whatever you do, do not press the "format" button. (or unRAID will format the drive reported as unformatted, and you might lose all the data on it) Again.... please fill in what you actually did... I'm just guessing from the log entries. Joe L.
August 30, 201015 yr This is what I got. What is the next step Joe? Replaying journal.. Reiserfs journal '/dev/md2' in blocks [18..8211]: 0 transactions replayed Checking internal tree../ 1 (of 9)/ 74/ 7 (of 9)/ 16 (ofinished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 219201 Internal nodes 1323 Directories 86 Other files 419 Data block pointers 221784448 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Mon Aug 30 16:42:05 2010
August 30, 201015 yr This is what I got. What is the next step Joe? Replaying journal.. Reiserfs journal '/dev/md2' in blocks [18..8211]: 0 transactions replayed Checking internal tree../ 1 (of 9)/ 74/ 7 (of 9)/ 16 (ofinished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 219201 Internal nodes 1323 Directories 86 Other files 419 Data block pointers 221784448 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Mon Aug 30 16:42:05 2010 It is good that there is no corruption. You can try to mount it yourself, or, it is probably easier just to stop the array and then press "Start" once more.
August 30, 201015 yr I hit stop and then Start again. I'm left with the option to start the array or hit the check box and restore.... Mind you all my disks are fine now except the parity is red.
August 30, 201015 yr Parity is "red" because writes to it failed. That guarantees it is out-of-date, so you can either: 1. Check the box under Restore and press it OR 2. Stop the array, un-assign the parity drive, Start the array with it un-assigned, then Stop the array once more re-assign the parity drive, then re-start the array.
August 30, 201015 yr Sorry to be difficult but I tried clicked the box and then restore. Now it says parity and disk 1 not installed and all orbs are blue.
August 30, 201015 yr Sorry to be difficult but I tried clicked the box and then restore. Now it says parity and disk 1 not installed and all orbs are blue. It sounds to me as if your prior statement that all your disks were OK was incorrect. Post a new syslog. Only then can we even have a clue about what is happening. Perhaps you forgot all the hardware related errors I pointed out earlier. They have apparently not gone away. If the parity disk AND disk1 are not found, then you have some hardware issues to resolve. It could be memory, a disk controller, one disk interfering with the other sharing the controller, the power supply... etc. Remember all those conflicts and resets with IRQ-19. have they always been there? Or are they new?
August 30, 201015 yr Yea I'm getting a click sound from my parity drive so its possible the HD might be going. I did attach another syslog. Also I didn't have this problem. You could be right about the hardware, and I guess its up to me to narrow it down. syslog.zip
August 30, 201015 yr The other item that doesn't sound right is you said you upgraded to unRAID 4.5.6, which can not be the case if you see any sort of "restore" button at all on the management console. Please update the title to indicate you are not running 4.5.6. Your syslog indicates you are running 4.5.0.
August 31, 201015 yr I'm not the original OP lol. I just saw that the title was similar to my issue so I guess you can say I hijacked the thread.
August 31, 201015 yr there have been some very different causes for "unformatted" drives between 4.5 and 4.5.6. Notably 4.5.3 would often report ALL disks as unformatted. In any case, you can try to see if the disks are responding at all. Odds are they are not. smartctl -d ata -a /dev/sdk and smartctl -d ata -a /dev/sdm The syslog is complaining about IRQ19 and constantly disabling it. It is probably the IRQ used by the SATA controller for those two disks. You could try to power cycle the server. (Stop the array, power down, power back up) to see if the error in the syslog goes away. Joe L.
August 31, 201015 yr Ok Joe, I power cycled my server and now all the disks are showing but they are all blue. I have not touched anything yet. Now I can either start the array or restore and then start I guess. I just want to make sure I'm doing everything properly since I have almost 10tb of data on this server.
August 31, 201015 yr Ok Joe, I power cycled my server and now all the disks are showing but they are all blue. I have not touched anything yet. Now I can either start the array or restore and then start I guess. I just want to make sure I'm doing everything properly since I have almost 10tb of data on this server. First run the two smartctl commands I listed AND post a new syslog. At this point you've already invalidated parity when you originally pressed the "restore" button, so with everything "blue" a "Start" is the only action you can take. Joe L.
August 31, 201015 yr Ok so does that mean that I've lost everything? Here is a new syslog. syslog.zip
August 31, 201015 yr Ok so does that mean that I've lost everything? Here is a new syslog. No, you just do not have any parity protection at this time and will not until you re-calculate parity by pressing "Start"
Archived
This topic is now archived and is closed to further replies.