October 17, 201213 yr Hey folks, after finally fixing most of my problems with unraid I though I can just take a break and just use my media without worrying too much...guess not. So, here is what i did - because there was virtually no cooling in my case, and disks were running at near 50C degrees, i have purchased Xigmatek 4in3 cage - I shut down unraid server via the menu - I unplugged all my drives (there are only 3) - I mounted them inside the cage, plugged power and sata cables back - started server - here is what I saw: I did check sata and power cables, and yeah, I plugged them in correct order. I can mount /dev/sdc1 manually and access the data. Yeah, I have no parity disk assigned at the moment. It was running fine before I shut the server down...Any hints?
October 17, 201213 yr If you have only 3 disks, and disk2 (the 3rd disk) is in the right spot, and you have no parity disk assigned, logic dictates that you have switched disk1 with the parity disk
October 17, 201213 yr Author Thanks for the reply. There are two WD drives - /dev/sdc, WD20EARX and /dev/sda, WD15EADS. There is no parity drive at all, that's why it's unassigned. My array is unprotected. Third drive is a small Hitachi 2.5" disk, that I mount via /boot/config/go, I use it to store Plex Media Server, so array disks can spin down.
October 17, 201213 yr Still, you have disconnected all disks when you placed the cage, and put ONE disk back in the right place (disk2), my guess is that means the other two are switched... what you NOW see as parity WAS your disk1, what you NOW see as disk1 IS your former NON-assigned parity disk. Elementary, my dear Watson... Best thing to do before removing disks is to write down the slot nr and corresponding serial number so you know what went where. Or make a screenshot like you did, but beforehand.
October 17, 201213 yr Unless you are using unraid version 4.7 the location of the disk does not matter, unraid decides on where what disk goes based on its serialnumber.. That by the way does not help you now... But somehow unraid thinks that you have removed a drive and entered a new one.. That can happen if the charistics of the drive have changed somehow.. You did not do anything else like changed unraid version for example ?
October 17, 201213 yr Author I didn't do anything, but unplugging SATA cables and plugging them back 15 minutes later. Still running 5.0-rc8a. When switching SATA cables I noticed that it indeed does not matter which drive i plug where - WD15EADS is always recognized as array Disk 2, regardless if its /dev/sda/b/c, WD20EARX is always listed as wrong, regardless if its /dev/sda/b/c. Still looking for some help guys, i'm not even sure where should is start looking
October 17, 201213 yr I didn't do anything, but unplugging SATA cables and plugging them back 15 minutes later. Still running 5.0-rc8a. When switching SATA cables I noticed that it indeed does not matter which drive i plug where - WD15EADS is always recognized as array Disk 2, regardless if its /dev/sda/b/c, WD20EARX is always listed as wrong, regardless if its /dev/sda/b/c. Still looking for some help guys, i'm not even sure where should is start looking Odds are the disk is now presenting itself as a different size. (That is the usual case) OR the disk controller wrote to the MBR and it now looks different OR your BIOS added an HPA (or now is ignoring one) and the drive is a different size then previously. Looking in your syslog, I see several disks with HPAs. ct 17 19:54:46 UNRAID kernel: ata1.01: HPA detected: current 488395055, native 488397168 Oct 17 19:54:46 UNRAID kernel: ata1.01: ATA-8: Hitachi HTS545025B9SA02, PB2AC60W, max UDMA/133 Oct 17 19:54:46 UNRAID kernel: ata1.01: 488395055 sectors, multi 16: LBA48 NCQ (depth 0/32) Oct 17 19:54:46 UNRAID kernel: ata2.00: HPA detected: current 2930275055, native 2930277168 Oct 17 19:54:46 UNRAID kernel: ata2.00: ATA-8: WDC WD15EADS-00S2B0, 01.00A01, max UDMA/133 Oct 17 19:54:46 UNRAID kernel: ata2.00: 2930275055 sectors, multi 16: LBA48 NCQ (depth 0/32) Oct 17 19:54:46 UNRAID kernel: sda: sda1 Oct 17 19:54:46 UNRAID kernel: sda: p1 size 488397104 extends beyond EOD, enabling native capacity Oct 17 19:54:46 UNRAID kernel: ata2.01: HPA detected: current 1953569134, native 3907029168 Oct 17 19:54:46 UNRAID kernel: ata2.01: ATA-8: WDC WD20EARX-00PASB0, 51.0AB51, max UDMA/133 Oct 17 19:54:46 UNRAID kernel: ata2.01: 1953569134 sectors, multi 16: LBA48 NCQ (depth 0/32) Oct 17 19:54:46 UNRAID kernel: ata2.00: configured for UDMA/133 Oct 17 19:54:46 UNRAID kernel: ata2.01: configured for UDMA/133 Oct 17 19:54:46 UNRAID kernel: sd 1:0:1:0: [sdc] Write Protect is off Oct 17 19:54:46 UNRAID kernel: sd 1:0:1:0: [sdc] Mode Sense: 00 3a 00 00 Oct 17 19:54:46 UNRAID kernel: sd 1:0:1:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Oct 17 19:54:46 UNRAID kernel: sdb: sdb1 Oct 17 19:54:46 UNRAID kernel: sdc: sdc1 Oct 17 19:54:46 UNRAID kernel: sdc: p1 size 3907026991 extends beyond EOD, enabling native capacity You need to get rid of the HPA, reset the proper MBR, run a reiserfsck on the file-system to repair it, and then the disk will be accepted once more. Since there is also an HPA on the Hitachi disk, and on the EADS disk, they were probably unplugged at one point, your motherboard BIOS probably decided to add one to the only available disk. (Just guessing) Oh yes, your BIOS needs to have that option disabled. (The one that copies the BIOS to an HPA it creates) Joe L.
October 18, 201213 yr Author Joe, thanks (again) for your help. I ended up doing new configuration, seems it did the trick, for a while at least. As I don't like to leave things unfinished I fired up reiserfsck this morning, I will also read up on HPA and try to see if it had anything to do with my situation. edit: reiserfsck didn't find anything ########### reiserfsck --check started at Thu Oct 18 09:28:34 2012 ########### Replaying journal: Trans replayed: mountid 31, transid 52133, desc 5275, len 1, commit 5277, next trans offset 5260 Trans replayed: mountid 31, transid 52134, desc 5278, len 1, commit 5280, next trans offset 5263 Trans replayed: mountid 31, transid 52135, desc 5281, len 1, commit 5283, next trans offset 5266 Trans replayed: mountid 31, transid 52136, desc 5284, len 25, commit 5310, next trans offset 5293 Replaying journal: Done. Reiserfs journal '/dev/sdc1' in blocks [18..8211]: 4 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 424320 Internal nodes 2755 Directories 94502 Other files 255475 Data block pointers 365004219 (12 of them are zero) Safe links 0 ########### reiserfsck finished at Thu Oct 18 11:32:34 2012 ###########
Archived
This topic is now archived and is closed to further replies.