January 14, 200917 yr UNRAID Version 4.5-beta1 I had a drive that had some write errors last night. I moved the data from the bad drive to another drive over night, through telnet. I went to stop the array and remove the bad disk from the system but when I clicked stop array, it didn't stop the array but then showed all my disks as being unformatted. I rebooted the machined and all disks are showing as new. I can not run reiserfsck because their is no MD devices in the system. Below is a section of my log that shows the disks being seen as new. I did notice it says invalid superblock checksum. Thanks for the help Jan 15 07:32:25 Tower emhttp: shcmd: shcmd (1): exit status: 1 Jan 15 07:32:25 Tower emhttp: shcmd (2): modprobe md-mod super=/boot/config/super.dat slots=8,112,8,96,8,144,8,128,8,160,8,176,8,16,8,64,8,0,8,32,8,48,0,0,0,0,0,0,0,0,0,0 >>/var /log/go 2>&1 Jan 15 07:32:25 Tower kernel: md: unRAID driver 0.95.0 installed Jan 15 07:32:25 Tower kernel: md: xor using function: p5_mmx (8962.800 MB/sec) Jan 15 07:32:25 Tower kernel: md: invalid superblock checksum Jan 15 07:32:25 Tower kernel: md: initializing superblock Jan 15 07:32:25 Tower kernel: md: import disk0: [8,112] (sdh) ST31000340AS 9QJ1YGS0 offset: 63 size: 976762552 Jan 15 07:32:25 Tower kernel: md: disk0 new disk Jan 15 07:32:25 Tower kernel: md: import disk1: [8,96] (sdg) ST31000340AS 9QJ24CB7 offset: 63 size: 976761496 Jan 15 07:32:25 Tower kernel: md: disk1 new disk Jan 15 07:32:25 Tower kernel: md: import disk2: [8,144] (sdj) WDC WD5000AAKS-00TMA0 WD-WCAPW2464785 offset: 63 size: 488386552 Jan 15 07:32:25 Tower kernel: md: disk2 new disk Jan 15 07:32:25 Tower kernel: md: import disk3: [8,128] (sdi) WDC WD5000AAKS-00TMA0 WD-WCAPW2408845 offset: 63 size: 488386552 Jan 15 07:32:25 Tower kernel: md: disk3 new disk Jan 15 07:32:25 Tower kernel: md: import disk4: [8,160] (sdk) ST31000340AS 9QJ1V3G2 offset: 63 size: 976762552 Jan 15 07:32:25 Tower kernel: md: disk4 new disk Jan 15 07:32:25 Tower kernel: md: import disk5: [8,176] (sdl) ST31000340AS 9QJ23528 offset: 63 size: 976762552 Jan 15 07:32:25 Tower kernel: md: disk5 new disk Jan 15 07:32:25 Tower kernel: md: import disk6: [8,16] (sdb) WDC WD5000AAKS-22YGA0 WD-WCAS81394043 offset: 63 size: 488386552 Jan 15 07:32:25 Tower kernel: md: disk6 new disk Jan 15 07:32:25 Tower kernel: md: import disk7: [8,64] (sde) WDC WD5000AAKS-00TMA0 WD-WCAPW2462584 offset: 63 size: 488386552 Jan 15 07:32:25 Tower kernel: md: disk7 new disk Jan 15 07:32:25 Tower kernel: md: import disk8: [8,0] (sda) WDC WD5000AAKS-00YGA0 WD-WCAS81172279 offset: 63 size: 488386552 Jan 15 07:32:25 Tower kernel: md: disk8 new disk Jan 15 07:32:25 Tower kernel: md: import disk9: [8,32] (sdc) WDC WD5000AAKS-00YGA0 WD-WCAS81172224 offset: 63 size: 488386552 Jan 15 07:32:25 Tower kernel: md: disk9 new disk Jan 15 07:32:25 Tower kernel: md: import disk10: [8,48] (sdd) ST31000340AS 5QJ08QQV offset: 63 size: 976762552 Jan 15 07:32:25 Tower kernel: md: disk10 new disk
January 15, 200917 yr UNRAID Version 4.5-beta1 I had a drive that had some write errors last night. I moved the data from the bad drive to another drive over night, through telnet. I went to stop the array and remove the bad disk from the system but when I clicked stop array, it didn't stop the array but then showed all my disks as being unformatted. I rebooted the machined and all disks are showing as new. I can not run reiserfsck because their is no MD devices in the system. Below is a section of my log that shows the disks being seen as new. I did notice it says invalid superblock checksum. Thanks for the help Jan 15 07:32:25 Tower emhttp: shcmd: shcmd (1): exit status: 1 Jan 15 07:32:25 Tower emhttp: shcmd (2): modprobe md-mod super=/boot/config/super.dat slots=8,112,8,96,8,144,8,128,8,160,8,176,8,16,8,64,8,0,8,32,8,48,0,0,0,0,0,0,0,0,0,0 >>/var /log/go 2>&1 Jan 15 07:32:25 Tower kernel: md: unRAID driver 0.95.0 installed Jan 15 07:32:25 Tower kernel: md: xor using function: p5_mmx (8962.800 MB/sec) Jan 15 07:32:25 Tower kernel: md: invalid superblock checksum Jan 15 07:32:25 Tower kernel: md: initializing superblock Jan 15 07:32:25 Tower kernel: md: import disk0: [8,112] (sdh) ST31000340AS 9QJ1YGS0 offset: 63 size: 976762552 Jan 15 07:32:25 Tower kernel: md: disk0 new disk Jan 15 07:32:25 Tower kernel: md: import disk1: [8,96] (sdg) ST31000340AS 9QJ24CB7 offset: 63 size: 976761496 Jan 15 07:32:25 Tower kernel: md: disk1 new disk Jan 15 07:32:25 Tower kernel: md: import disk2: [8,144] (sdj) WDC WD5000AAKS-00TMA0 WD-WCAPW2464785 offset: 63 size: 488386552 Jan 15 07:32:25 Tower kernel: md: disk2 new disk Jan 15 07:32:25 Tower kernel: md: import disk3: [8,128] (sdi) WDC WD5000AAKS-00TMA0 WD-WCAPW2408845 offset: 63 size: 488386552 Jan 15 07:32:25 Tower kernel: md: disk3 new disk Jan 15 07:32:25 Tower kernel: md: import disk4: [8,160] (sdk) ST31000340AS 9QJ1V3G2 offset: 63 size: 976762552 Jan 15 07:32:25 Tower kernel: md: disk4 new disk Jan 15 07:32:25 Tower kernel: md: import disk5: [8,176] (sdl) ST31000340AS 9QJ23528 offset: 63 size: 976762552 Jan 15 07:32:25 Tower kernel: md: disk5 new disk Jan 15 07:32:25 Tower kernel: md: import disk6: [8,16] (sdb) WDC WD5000AAKS-22YGA0 WD-WCAS81394043 offset: 63 size: 488386552 Jan 15 07:32:25 Tower kernel: md: disk6 new disk Jan 15 07:32:25 Tower kernel: md: import disk7: [8,64] (sde) WDC WD5000AAKS-00TMA0 WD-WCAPW2462584 offset: 63 size: 488386552 Jan 15 07:32:25 Tower kernel: md: disk7 new disk Jan 15 07:32:25 Tower kernel: md: import disk8: [8,0] (sda) WDC WD5000AAKS-00YGA0 WD-WCAS81172279 offset: 63 size: 488386552 Jan 15 07:32:25 Tower kernel: md: disk8 new disk Jan 15 07:32:25 Tower kernel: md: import disk9: [8,32] (sdc) WDC WD5000AAKS-00YGA0 WD-WCAS81172224 offset: 63 size: 488386552 Jan 15 07:32:25 Tower kernel: md: disk9 new disk Jan 15 07:32:25 Tower kernel: md: import disk10: [8,48] (sdd) ST31000340AS 5QJ08QQV offset: 63 size: 976762552 Jan 15 07:32:25 Tower kernel: md: disk10 new disk If you have a copy of the super.dat file from in the config folder on the flash you could restore it. Basically, as the syslog said, it has a bad checksum, and therefore is being ignored. It is exactly as if you had just assigned your drives for the first time. If you have a copy of the super.dat file, replace the corrupt one and reboot. If not, your only choice is to press the start button.... but first... make absolutely sure the parity drive is assigned to the parity slot. If the device assignments are all correct, (especially the parity drive) you can use the "Trust My Parity" procedure before you press the "Start" button, but because you had to reboot, let it finish the parity check. It is described here The disks showed as unformatted because you still had some files open when you went to stop the array. This is not an issue unless you pressed the button to format them again. (that would have been a mistake) Next time, log off and shut down and extras you might have running that have open files on your array. Joe L.
January 15, 200917 yr Author Hi Joe, How do I restore the super.dat. I can see a copy of it on my flash drive in the config folder. Thanks
January 15, 200917 yr Hi Joe, How do I restore the super.dat. I can see a copy of it on my flash drive in the config folder. Thanks That is the one that is corrupt. You would have to have made a copy of it before it was corrupted, but after you had assigned all the drives. It is not a big deal, since if you delete the one there the unRAID software will create a new one for you based on the current drive assignments. It does contain the "indicator" that shows parity was successfully computed on your array... because that indicator is not set, a new parity calc will start when you start the array and you will not be protected until it completes... Unless you use the Trust-My-Parity" process I linked to above. It is probably useful in your situation. Since you did reboot, let it complete the parity check. At least while it is "checking" you are protected from another disk failure. Joe L.
January 15, 200917 yr Author Thanks Joe, The array is back online the parity is rebuilding, all is good.
January 15, 200917 yr A suggestion, check the Improving unRAID Performance wiki page, for the tip about removing the SATA150 jumper. Your Seagates connected to the onboard ports appear to still have their speed limiting jumpers installed, which slows them down slightly. You don't need to remove the jumpers from the Seagates attached to the Silicon Image controllers (a pair of SiI3114's I believe), because that is as fast as that controller can do.
Archived
This topic is now archived and is closed to further replies.