Tophicles

Ok, I'll try that! Sorry to be such a newb pain in the arse...

*bump*

I have the original disk still, but when I moved the partition on that one, that's when it showed as unformatted. I think maybe the best option is to format the new disk, then put the old disk on a different system and try to recover what is/was on it, sound good?

*BUMP* No answers from Tom - need to figure out what to do here before I am out of space... any takers?

No dice: SASFLASH - Cannit initialize PAL, aborting... That's all I get.

Will this work even if I have a 1608E?

Not sure which to download: http://www.lsi.com/support/products/Pages/LSISAS1068E.aspx Anyone have a pointer for me?

I am using two LSI controllers, I am not sure how to flash them, but I will Googlify it

Just for further information, I re-ran Joe L's SED command: root@Angband:~# dd if=/dev/sdj count=195 | od -c -A d | sed 30q 195+0 records in 195+0 records out 99840 bytes (100 kB) copied, 0.00294673 s, 33.9 MB/s 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000448 \0 \0 203 \0 \0 \0 @ \0 \0 \0 p 210 340 350 \0 \0 0000464 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000496 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U 252 0000512 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0066048 020 021 034 035 P U 243 \n 323 375 \f \0 022 \0 \0 \0 0066064 \0 \0 \0 \0 \0 \0 \0 \0 004 \0 \0 \0 \0 \0 \0 0066080 204 003 \0 \0 036 \0 \0 \0 \0 \0 \0 \0 \0 020 314 003 0066096 314 003 001 \0 R e I s E r 2 F s \0 \0 \0 0066112 003 \0 \0 \0 005 \0 9 : 002 \0 \0 \0 \0 \0 \0 \0 0066128 \0 \0 \0 \0 ( N 330 ^ 032 332 O 223 214 = 345 L 0066144 022 262 022 E \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0066160 \0 \0 \0 \0 001 \0 036 \0 036 031 P O \0 N 355 \0 0066176 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0066240 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 0066256 0 \0 \0 \0 1 \0 \0 \0 W \0 \0 \0 X \0 \0 \0 0066272 204 \0 \0 \0 205 \0 \0 \0 206 \0 \0 \0 207 \0 \0 \0 0066288 245 \0 \0 \0 246 \0 \0 \0 257 \0 \0 \0 261 \0 \0 \0 0066304 273 \0 \0 \0 275 \0 \0 \0 276 \0 \0 \0 300 \0 \0 \0 0066320 301 \0 \0 \0 303 \0 \0 \0 327 \0 \0 \0 330 \0 \0 \0 0066336 353 \0 \0 \0 355 \0 \0 \0 357 \0 \0 \0 360 \0 \0 \0 0066352 362 \0 \0 \0 363 \0 \0 \0 365 \0 \0 \0 367 \0 \0 \0 0066368 370 \0 \0 \0 371 \0 \0 \0 377 \0 \0 \0 \0 001 \0 \0 0066384 001 001 \0 \0 002 001 \0 \0 003 001 \0 \0 005 001 \0 \0 0066400 \a 001 \0 \0 \b 001 \0 \0 \f 001 \0 \0 \r 001 \0 \0 0066416 016 001 \0 \0 017 001 \0 \0 023 001 \0 \0 024 001 \0 \0 root@Angband:~# ... and here's the output from the partition_utility script: root@Angband:/boot# unraid_partition_disk.sh -t /dev/sdj BLKRRPART: Device or resource busy This disk is currently in use. ######################################################################## terminate called after throwing an instance of 'int' Disk /dev/sdj: 2000.4 GB, 2000398934016 bytes 1 heads, 63 sectors/track, 62016336 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdj1 64 3907029167 1953514552 83 Linux Partition 1 does not end on cylinder boundary. ######################################################################## ============================================================================ == Disk /dev/sdj is NOT partitioned for unRAID properly. == expected start = 63, actual start = 64 == expected size = 3907029105, actual size = 3907029104 ============================================================================ root@Angband:/boot#

Ok, so I went back to b12 and the disk still show as unformatted. I ran the unraid_partition_utility.sh and it showed that the drive was not partitioned for unraid properly (expected sector 63, saw sector 64). Now, I know that when I pre-cleared it, I did so with -A option, so it should be on 64. I ran the partition utility with the -A command and it told me the disk is now partitioned correctly. Upon reboot, however it appears to have reverted back.

Now that you mention it, I seem to recall that these problems occurred when I switched to b14, so I downgraded to b13 in the hopes it would go away. I will go back to b12a, my buddy is running that and he's never had any issues...

Thanks Joe; I've sent Tom an email. Km.

Ok, so I replaced my disk 12 with a brand new disk. Here's the procedure I followed: 1) Stop Array 2) UnAssign old Disk from slot 12 3) Powerdown 4) Install new disk 5) Power on 6) Preclear new disk 7) Stop Array Assign new disk to "empty" slot 12 9) Allow the Data Rebuild Now, after the data rebuild is complete, it is showing the new disk 12 as "unformatted"?!?! I would have formatted it first, only it never asked me before the data-rebuild started. Not sure what to do now... Screenshot: http://imm.io/igFm Sys log attached. syslog-2012-03-08.zip

I'm not sure, will have to down the server and investigate later today...

I have two Supermicro cards that supply 8 drives each and then there's the integrated 6-port SATA on the mobo. I'm not sure which drives are on which controllers... power issues, I have a Thermaltake 750W PSU. It has 56A on on rail for 12v, I thought that was enough for many drives? I supposed I could "stagger" the drives across the controllers but swapping some cables around?

As far as the FTP access goes, yeah, I had turned on FTP to try something out, it's normally completely firewalled and is now again. RE the file system errors, I figured I'd have to run reiserfsck. So are these not serious errors, like the disks are not failing imminently or anything? I mean I've had a few drives go "bad" in unraid, and only one of them was actually a bad drive.

Now I think there are more serious problems... take a look at the syslog now.... WTF? syslog-2012-03-04.zip

Ok, now I'm stumped... apparently you can't get to the drive anymore. It was /dev/sdi in that syslog, but it's showing up as /dev/sdj now. whne I run that command I get the following: root@Angband:~# dd if=/dev/sdj count=195 | od -c -A d | sed 30q dd: reading `/dev/sdj': Input/output error 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.000484026 s, 0.0 kB/s 0000000 root@Angband:~# ... and my syslog has the following: Mar 3 20:13:31 Angband kernel: Buffer I/O error on device sdj, logical block 0 So, assuming this means the disk is pooched, is it simply a matter of pulling it out and replacing it with a new disk (which will then rebuild the new drive from the "protected" data, ie, is it in "simultation" mode now?) or should I accept that the disk and it's contents are gone and move on Thanks for the assistance and answers, I appreciate it.

*BUMP* Out of desperation

unRAID Version: unRAID Server Pro, Version 5.0-beta13 Motherboard: ASUSTeK - M5A97 Processor: AMD AthlonTM II X2 240 - 2.8 GHz Cache: L1 = 256 KB L2 = 2048 KB Memory: 5767169 kB - DIMM3 = 1333 MHz (0.8 ns) The power supply is a Thermaltake 750.

*BUMP* Anyone? I'm scared to do anything with this in case I lose the data that was/is/may be still on the drive... Should I stop the array, remove the disk and attach it to my windows machine to try to see what I can see? Km.

Well, I've been having some *weird* issues lately. Drives showing up with write or read errors in the syslog and then I unmount and run reiserfsck which tells me there are no errors at all. I can initconfig and add the drives back to the array and they work fine, then, another day, another drive at a different point has the same error. It's culminated now in my disk12 showing as "unformatted". When I run reiserfsck, it does the semantic pass and show all the data on the disk, but unraid sees it as unformatted. I browsed the forum and tried the "unraid_partition_utility.sh" script (great util!) and it told me the partition was on 64 not 63. I followed the further instructions and "corrected" the partition. Then I ran reiserfsck --rebuild-tree (as --check told me to) and just for kicks, after it completed, I ran the util again. To my surprise it told me it was not suitable for unraid? It's like the partition changes were reverted somehow. Anyway, now it's running as "unformatted" and the array (after a reboot) is re-building parity. I think I'm pooched on this drive having any hope of recovering the data, should I just format it? Or should I get a new drive and "replace" it in the hopes it will rebuild disk12? Or is the current parity check wiping all that clean? I'm starting to give up... it used to be so great and now there are near daily errors. Any thoughts, oh great gurus? I will attempt to clarify anything (which I'm sure I left) lacking and am more than willing to try whatever is suggested. thanks in advance for any help you may have... Worried in Windsor. SYSLOG ATTACHED. syslog.zip

kill -9 pid

Ok, so after a reboot, the drive issue appears to be resolved. Why it took after this reboot and not the others, I have no idea All hail ignorance, isn't it blissfull! Thanks to those who looked over my quandry... it was appreciated.

Ok, so it looks like my disk7 has a poop-tonne of read errors on it, which is why portions of the data-rebuild and parity-check went so slowly. I will replace this disk at a later time, right now everything is back up to snuff. More weirdness ensues... I have added a new, 2TB WD drive to the array. I pre-cleared it using the 1.13 version of the pre-clear script. I added it to the array and then started the array, agreeing to format any new disks. It formatted the new disk (disk12) and green-balled it into the array. I can see the new disk via it#s SMB direct share \\tower\disk12 and I can create/delete folders on it. my unMENU main screen correctly reports the total new size of the array as 2.3 TB free (I had 300 or so GB free until adding the new drive). However, my shares are set to ~most free~, and so far, nothing is being written to the new drive. My SABnzbd reports there is only ~300Gb free (correct, if the new drive is not in) but that conflicts with what my unMENU screen says. I have gone back to 5b12 and I have included links to the unMENU and unRAID main screens. Any thoughts? unMENU Main: http://imm.io/cRw3 unRAID Main: http://imm.io/cRwb syslog-2011-12-12.zip