September 30, 200817 yr I don't know if it is related to the new beta, but after upgrading to the new beta from 4.3.2 I suddenly had a disk disabled after restarting the server. I restarted with the old unraid version and the disk was still disabled. Ok, hard drives can go bad, maybe it is just a coincidence. I start to move all the files off the disabled drive to other drives. After I have moved the files I try to power down, but I can't stop the array because a device is still in use. This part is a bit blurry to me, but as I remember, the disabled drive showed up unformatted after trying to stop the array. Since the power button was not available, I pressed the format button to reformat the drive that was disabled. Instead of the disabled drive being formatted, all the green drives showing "formatting" in one of the columns on the main unraid web page. I am sh*tting bricks. I don't think I could stop the formatting from the main page so I run to the server and press the off button. I followed the instructions in the thread regarding disabled drives, pulled the bad drive and restart. Sure enough, 3 of my disks are "empty" or seem to have been formatted. They are green, but have no files. According to the smart report, the disabled drive was ok (passed). I reinstalled the disabled drive and unraid is rebuilding right now. I am guessing the missing files on the 3 "formatted" disks are not gone. After rebuild I will follow the instructions in thread http://lime-technology.com/forum/index.php?topic=2381.0 to see if anything is left. I would have done this before rebuilding, but the discs where not listed under /mnt until rebuilding began. I feel that I ran into a situation that wasn't normal, or described in the documentation and I may have made some incorrect decisions. The output from the syslog after the drive was first disable was: Sep 29 23:30:54 Nas emhttp: shcmd (28): killall -w smbd nmbd Sep 29 23:30:55 Nas emhttp: shcmd (29): /usr/sbin/hdparm -S242 /dev/sda >/dev/null Sep 29 23:30:55 Nas emhttp: shcmd (30): /usr/sbin/hdparm -S242 /dev/sdb >/dev/null Sep 29 23:30:55 Nas emhttp: shcmd (31): /usr/sbin/hdparm -S242 /dev/sdc >/dev/null Sep 29 23:30:55 Nas emhttp: shcmd (32): /usr/sbin/hdparm -S242 /dev/sdd >/dev/null Sep 29 23:30:55 Nas emhttp: shcmd (33): /usr/sbin/hdparm -S242 /dev/sde >/dev/null Sep 29 23:30:55 Nas emhttp: shcmd (34): /usr/sbin/hdparm -S242 /dev/sdf >/dev/null Sep 29 23:30:55 Nas emhttp: shcmd (35): /usr/sbin/hdparm -S242 /dev/sdh >/dev/null Sep 29 23:30:55 Nas emhttp: shcmd (36): /usr/sbin/hdparm -S242 /dev/sdk >/dev/null Sep 29 23:30:55 Nas emhttp: shcmd (37): /usr/sbin/hdparm -S242 /dev/sdj >/dev/null Sep 29 23:30:55 Nas emhttp: shcmd (38): /usr/sbin/hdparm -S242 /dev/sdi >/dev/null Sep 29 23:31:00 Nas kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Sep 29 23:31:00 Nas kernel: ata3.00: cmd e3/00:f2:00:00:00/00:00:00:00:00/40 tag 0 Sep 29 23:31:00 Nas kernel: res 40/00:00:00:f2:00/00:00:00:00:00/00 Emask 0x4 (timeout) Sep 29 23:31:00 Nas kernel: ata3.00: status: { DRDY } Sep 29 23:31:00 Nas kernel: ata3: hard resetting link Sep 29 23:31:00 Nas kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Sep 29 23:31:00 Nas kernel: ata2.00: cmd e3/00:f2:00:00:00/00:00:00:00:00/40 tag 0 Sep 29 23:31:00 Nas kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Sep 29 23:31:00 Nas kernel: ata2.00: status: { DRDY } Sep 29 23:31:00 Nas kernel: ata2: hard resetting link Sep 29 23:31:00 Nas kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Sep 29 23:31:00 Nas kernel: ata4.00: cmd e3/00:f2:00:00:00/00:00:00:00:00/40 tag 0 Sep 29 23:31:00 Nas kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Sep 29 23:31:00 Nas kernel: ata4.00: status: { DRDY } Sep 29 23:31:00 Nas kernel: ata4: hard resetting link Sep 29 23:31:00 Nas kernel: ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Sep 29 23:31:00 Nas kernel: ata9.00: cmd e3/00:f2:00:00:00/00:00:00:00:00/40 tag 0 Sep 29 23:31:00 Nas kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Sep 29 23:31:00 Nas kernel: ata9.00: status: { DRDY } Sep 29 23:31:00 Nas kernel: ata9: hard resetting link Sep 29 23:31:02 Nas kernel: ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Sep 29 23:31:02 Nas kernel: ata3.00: configured for UDMA/133 Sep 29 23:31:02 Nas kernel: ata3: EH complete Sep 29 23:31:02 Nas kernel: sd 3:0:0:0: [sdc] 976773168 512-byte hardware sectors (500108 MB) Sep 29 23:31:02 Nas kernel: sd 3:0:0:0: [sdc] Write Protect is off Sep 29 23:31:02 Nas kernel: sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00 Sep 29 23:31:02 Nas kernel: sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 29 23:31:03 Nas kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Sep 29 23:31:03 Nas kernel: ata2.00: configured for UDMA/133 Sep 29 23:31:03 Nas kernel: ata2: EH complete Sep 29 23:31:03 Nas kernel: sd 2:0:0:0: [sdb] 586114704 512-byte hardware sectors (300091 MB) Sep 29 23:31:03 Nas kernel: sd 2:0:0:0: [sdb] Write Protect is off Sep 29 23:31:03 Nas kernel: sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 Sep 29 23:31:03 Nas kernel: sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 29 23:31:03 Nas kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Sep 29 23:31:03 Nas kernel: ata4.00: configured for UDMA/133 Sep 29 23:31:03 Nas kernel: ata4: EH complete Sep 29 23:31:03 Nas kernel: sd 4:0:0:0: [sdd] 586114704 512-byte hardware sectors (300091 MB) Sep 29 23:31:03 Nas kernel: sd 4:0:0:0: [sdd] Write Protect is off Sep 29 23:31:03 Nas kernel: sd 4:0:0:0: [sdd] Mode Sense: 00 3a 00 00 Sep 29 23:31:03 Nas kernel: sd 4:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 29 23:31:05 Nas kernel: ata9: link is slow to respond, please be patient (ready=-19) Sep 29 23:31:10 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:31:10 Nas kernel: ata9: hard resetting link Sep 29 23:31:15 Nas kernel: ata9: link is slow to respond, please be patient (ready=-19) Sep 29 23:31:20 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:31:20 Nas kernel: ata9: hard resetting link Sep 29 23:31:25 Nas kernel: ata9: link is slow to respond, please be patient (ready=-19) Sep 29 23:31:55 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:31:55 Nas kernel: ata9: limiting SATA link speed to 1.5 Gbps Sep 29 23:31:55 Nas kernel: ata9: hard resetting link Sep 29 23:32:00 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:32:00 Nas kernel: ata9: reset failed, giving up Sep 29 23:32:00 Nas kernel: ata9.00: disabled Sep 29 23:32:00 Nas kernel: ata9: EH complete Sep 29 23:32:00 Nas emhttp: shcmd (39): sync Sep 29 23:32:00 Nas kernel: sd 9:0:0:0: [sdh] Result: hostbyte=0x04 driverbyte=0x00 Sep 29 23:32:00 Nas kernel: end_request: I/O error, dev sdh, sector 2495 Sep 29 23:32:00 Nas kernel: md: disk6 read error Sep 29 23:32:00 Nas kernel: handle_stripe read error: 2432/6, count: 1 Sep 29 23:32:00 Nas kernel: md: disk6 read error Sep 29 23:32:00 Nas kernel: handle_stripe read error: 2440/6, count: 1 Sep 29 23:32:01 Nas kernel: ata9: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen Sep 29 23:32:01 Nas kernel: ata9: hotplug_status 0x88 Sep 29 23:32:01 Nas kernel: ata9: hard resetting link Sep 29 23:32:01 Nas kernel: sd 9:0:0:0: rejecting I/O to offline device Sep 29 23:32:01 Nas kernel: md: disk6 write error Sep 29 23:32:01 Nas kernel: handle_stripe write error: 2432/6, count: 1 Sep 29 23:32:01 Nas kernel: md: disk6 write error Sep 29 23:32:01 Nas kernel: handle_stripe write error: 2440/6, count: 1 Sep 29 23:32:01 Nas kernel: md: recovery thread woken up ... Sep 29 23:32:01 Nas kernel: md: recovery thread has nothing to resync Sep 29 23:32:01 Nas emhttp: shcmd (40): umount /mnt/user Sep 29 23:32:01 Nas emhttp: shcmd (41): rmdir /mnt/user Sep 29 23:32:01 Nas emhttp: shcmd (42): umount /mnt/user0 Sep 29 23:32:01 Nas emhttp: shcmd (43): rmdir /mnt/user0 Sep 29 23:32:01 Nas emhttp: shcmd (44): umount /mnt/disk1 Sep 29 23:32:01 Nas emhttp: shcmd (44): umount /mnt/disk2 Sep 29 23:32:01 Nas emhttp: shcmd (44): umount /mnt/disk3 Sep 29 23:32:01 Nas emhttp: shcmd (44): umount /mnt/disk4 Sep 29 23:32:01 Nas emhttp: shcmd (44): umount /mnt/disk5 Sep 29 23:32:01 Nas emhttp: shcmd (44): umount /mnt/disk6 Sep 29 23:32:01 Nas emhttp: shcmd (44): umount /mnt/disk7 Sep 29 23:32:01 Nas emhttp: shcmd (44): umount /mnt/disk8 Sep 29 23:32:01 Nas emhttp: shcmd (44): umount /mnt/cache Sep 29 23:32:01 Nas emhttp: shcmd: shcmd (44): exit status: 1 Sep 29 23:32:01 Nas emhttp: shcmd (45): rmdir /mnt/cache Sep 29 23:32:01 Nas emhttp: shcmd: shcmd (45): exit status: 1 Sep 29 23:32:01 Nas emhttp: shcmd (45): rmdir /mnt/disk3 Sep 29 23:32:01 Nas emhttp: shcmd (45): rmdir /mnt/disk6 Sep 29 23:32:01 Nas emhttp: shcmd (45): rmdir /mnt/disk1 Sep 29 23:32:01 Nas emhttp: shcmd (45): rmdir /mnt/disk5 Sep 29 23:32:01 Nas emhttp: shcmd (45): rmdir /mnt/disk7 Sep 29 23:32:01 Nas emhttp: shcmd (45): rmdir /mnt/disk2 Sep 29 23:32:01 Nas emhttp: shcmd (45): rmdir /mnt/disk4 Sep 29 23:32:01 Nas emhttp: shcmd (45): rmdir /mnt/disk8 Sep 29 23:32:01 Nas kernel: mdcmd (11): stop Sep 29 23:32:01 Nas kernel: md1: stopping Sep 29 23:32:01 Nas kernel: md2: stopping Sep 29 23:32:01 Nas kernel: md3: stopping Sep 29 23:32:01 Nas kernel: md4: stopping Sep 29 23:32:01 Nas kernel: md5: stopping Sep 29 23:32:01 Nas kernel: md6: stopping Sep 29 23:32:01 Nas kernel: md7: stopping Sep 29 23:32:01 Nas kernel: md8: stopping Sep 29 23:32:06 Nas kernel: ata9: link is slow to respond, please be patient (ready=-19) Sep 29 23:32:11 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:32:11 Nas kernel: ata9: hard resetting link Sep 29 23:32:16 Nas kernel: ata9: link is slow to respond, please be patient (ready=-19) Sep 29 23:32:21 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:32:21 Nas kernel: ata9: hard resetting link Sep 29 23:32:26 Nas kernel: ata9: link is slow to respond, please be patient (ready=-19) Sep 29 23:32:56 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:32:56 Nas kernel: ata9: limiting SATA link speed to 1.5 Gbps Sep 29 23:32:56 Nas kernel: ata9: hard resetting link Sep 29 23:33:01 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:33:01 Nas kernel: ata9: reset failed, giving up Sep 29 23:33:01 Nas kernel: ata9: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen t4 Sep 29 23:33:01 Nas kernel: ata9: hotplug_status 0x88 Sep 29 23:33:01 Nas kernel: ata9: hard resetting link Sep 29 23:33:06 Nas kernel: ata9: link is slow to respond, please be patient (ready=-19) Sep 29 23:33:11 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:33:11 Nas kernel: ata9: hard resetting link Sep 29 23:33:17 Nas kernel: ata9: link is slow to respond, please be patient (ready=-19) Sep 29 23:33:21 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:33:21 Nas kernel: ata9: hard resetting link Sep 29 23:33:27 Nas kernel: ata9: link is slow to respond, please be patient (ready=-19) Sep 29 23:33:56 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:33:56 Nas kernel: ata9: limiting SATA link speed to 1.5 Gbps Sep 29 23:33:56 Nas kernel: ata9: hard resetting link Sep 29 23:34:01 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:34:01 Nas kernel: ata9: reset failed, giving up Sep 29 23:34:01 Nas kernel: ata9: EH complete Sep 29 23:34:01 Nas kernel: md: import disk6: lock_rdev error: -6 Sep 29 23:34:01 Nas kernel: md: disk6 removed Sep 29 23:34:01 Nas kernel: ata9.00: detaching (SCSI 9:0:0:0) Sep 29 23:34:01 Nas kernel: sd 9:0:0:0: [sdh] Synchronizing SCSI cache Sep 29 23:34:01 Nas kernel: sd 9:0:0:0: [sdh] Result: hostbyte=0x04 driverbyte=0x00 Sep 29 23:34:01 Nas kernel: sd 9:0:0:0: [sdh] Stopping disk Sep 29 23:34:01 Nas kernel: sd 9:0:0:0: [sdh] START_STOP FAILED Sep 29 23:34:01 Nas kernel: sd 9:0:0:0: [sdh] Result: hostbyte=0x04 driverbyte=0x00 Sep 29 23:34:01 Nas kernel: ata9: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen Sep 29 23:34:01 Nas kernel: ata9: hotplug_status 0x88 Sep 29 23:34:01 Nas kernel: ata9: hard resetting link Sep 29 23:34:01 Nas emhttp: shcmd (44): /usr/sbin/nmbd -D Sep 29 23:34:01 Nas emhttp: shcmd (45): /usr/sbin/smbd -D Sep 29 23:34:04 Nas kernel: md: import disk6: lock_rdev error: -6 Sep 29 23:34:04 Nas kernel: md: disk6 removed Sep 29 23:34:07 Nas kernel: ata9: link is slow to respond, please be patient (ready=-19) Sep 29 23:34:11 Nas kernel: ata9: COMRESET failed (errno=-16) Sep 29 23:34:11 Nas kernel: ata9: hard resetting link root@Nas:~# Broadcast message from root (Mon Sep 29 23:34:32 2008): The system is going down for system halt NOW! I only have the syslog after I started the rebuild. I have attached it.
September 30, 200817 yr The presentation of that format button is sometimes under the wrong conditions. *sigh* hope you are able to recover with the reiserfsck --rebuildtree. There were a few people who mistakenly assigned parity to a data drive and was able to recover. Tom there's a serious issue with how emhttp handles disks that did not unmount correctly. In addition, it should see if there are active pids and kill them to help the umount succeed.
September 30, 200817 yr I will give it a try after the rebuild. I follow most threads on the forum and I didn't remember reading any threads that reminded me of my problem.
September 30, 200817 yr I second the need to look at processes and kill anything with an open file on the array when stopping..... 90% of unRAID management issues I have come from a stop that fails due to an open file (which is where lsof comes in handy). With so many people using unRAID as a platform to run other things (like NZGget, torrents, web server, media management, etc.) that all may have open files on an array when they are active, there needs to be scripting hooks in the unRAID management interface.... particularly a user-defined or user-editable script to be called before stopping the array.
September 30, 200817 yr the rebuild is finished and now I am running the reiserfsck --rebuild-tree -S -l /boot/recovery.log /dev/md1 for disk1. Refreshing the web page shows a text that there is (are) unformatted drives, which is not correct. I hope this is just because of the procedure to rebuild (all disks are green). Let's assume the deleted files were on disk3. cd /root /root/samba stop umount /mnt/disk3 reiserfsck --rebuild-tree -S -l /boot/recovery.log /dev/md3 If the reiserfs command prompts for you to type "Yes" to continue, type exactly "Yes" (Upper case "Y", and lower case "es".) Wait for it to finish. (it could take a long time if it is a large drive with lots of files) When done, you will see the "root" prompt once more. Then, mount the file system and re-start samba using the following commands: mount -t reiserfs -o noatime,nodiratime /dev/md3 /mnt/disk3 /root/samba start I'll see when the rebuild is finished.
September 30, 200817 yr Well, I have recovered the first disk and it looks good so far. The original file structure is back. I have a question about the lost + found folder. It seems to contain a lot of files that were once moved from the disk to another disk or deleted. Is it correct that after rebuilding that all previous moves/deletes show up in lost + found (when not overwritten)?
September 30, 200817 yr Is it correct that after rebuilding that all previous moves/deletes show up in lost + found (when not overwritten)? These are files whereby data chunks have been found with out directory pointers. so.. previous moves and deletes yes.. it could also contain partial file chunks too. I would review them against the sources if possible. If you know the moved file was/is intact on the destination, then you can probably delete the version in lost+found.
September 30, 200817 yr I wonder if the 4.4.1 beta is really ok. After recovering data I wanted to restart the server. Pressing stop did not stop the array, instead it seems the server crapped itself. See attached syslog. I had to turn off the server with the power switch. I am now running the 4.3.2 version instead and a parity check is being run. I have never had these kind of problems in the past, and I doubt that my hardware has suddenly stopped working. I like the this row in the syslog: Sep 30 21:06:01 Nas kernel: BUG: unable to handle kernel NULL pointer dereference at 00000008 Sep 30 21:06:01 Nas kernel: IP: [<f88705db>] :md_mod:handle_stripe+0x2ed/0xc64 Sep 30 21:06:01 Nas kernel: *pde = 00000000 Sep 30 21:06:01 Nas kernel: Oops: 0000 [#1] SMP <<<<<--------------- Sep 30 21:06:01 Nas kernel: Modules linked in: md_mod pata_jmicron sata_promise jmicron ide_core ahci libata e1000e Sep 30 21:06:01 Nas kernel: This has been a load of trouble. I normally like to use the latest software version, but this puts a different perspective on things. I am using the stock (standard) Asus motherboard that Tom uses. Roland
September 30, 200817 yr Installed v4.4-beta1, and running fine, no issues. And none of the syslogs above (except btlupin's) show any issues either. As with any significant update of the Linux kernel, there are a few users who have seen device assignment changes, potentially making a few drives show as missing temporarily, until re-assigned. This first beta of the v4.4 series appears to have been a good test of its core improvements, the update of the kernel from 2.6.24.4 to 2.6.26.5 and support for SMP. Per Tom's remark about "a substantial set of changes" to come, let the fun begin... ... Well, writing the above is as far as I had gotten when btlupin's post arrived. I have a number of additional comments to make about v4.4-beta1, but his issues required a look. I've spent some time reviewing his situation, but unfortunately have now run out of time. All I can say at the moment is I *think* his problems are not specific to the new beta, and I have an idea about the causes, and other comments for him, but no time until tomorrow. I would like to strongly say to all users: If you see an unexpected Format button, please please do not press it, or do anything drastic, until a full power off, and calm examination and testing. There is very possibly NOTHING wrong with ANY of the drives!
September 30, 200817 yr I tested 4.4-beta1. On my configuration version of UnRaid server 4.4-beta1 not working. After boot I see "Loading bzimage..." and "Loading bzroot........ready" then computer is done restart.
September 30, 200817 yr Author I don't know if it is related to the new beta, but after upgrading to the new beta from 4.3.2 I suddenly had a disk disabled after restarting the server. ... I only have the syslog after I started the rebuild. I have attached it. This problem is a combination of 2 bugs. First is the timeout in the linux sata driver is too short for issuing commands such as setting the spin-down delay which results in all those timeout and reset messages in your syslog. Second is that in your case it so happened that multiple disks failed the same sector at the same time & uncovered a bug in the unraid driver which resulted in the crash. Both of these problems are fixed in 4.4-beta2. After a bit more testing we will be posting -beta2 today.
September 30, 200817 yr Hmmm - I think I'm getting problems with the 2.6.26.5 kernel on my box. I got a bunch of messages like: ata1: link is slow to respond, please be patient (ready=0) ata3: link is slow to respond, please be patient (ready=0) ata1: COMRESET failed (errno=-16) ata1: hard resetting link ... When the boot finally finished, both of my Western digital 500GB green drivers were 'missing'. My maxtor SATA & WDC PATA drive did come up though.... Hmm - I removed the 1.5Gb/s link jumpers on one drive and it came up fine, though I'm a bit worried about long-term stability running the drives at full 3Gb/s - the motherboard is an older unit, and I used to get crashes under windows when I ran at full rate -- though with different cables. EDIT: Even with the drives at 3GB/s, they're not coming up reliably. Looks like I'm back to 4.3.3 for now, since the 2.6.24.4 kernel seems immune to whatever is afflicting me.
September 30, 200817 yr My system: Asus P5E-VM Do bios v.0803 Celeron 420 2 x 512mb kingston BQ! SP 450W 3 x HD501LJ, 1 X 7200.11 750GB, 1 X 7200.10 160GB Now, when SMP is supported, and some drivers got updated i'm waiting for security & reliablity improvements and revamping the web panel. What driver updates are you referring to? Actually i only refer to Intel PRO1000 driver update (v0.2.0 in 4.3.3, and v0.3.3 in 4.4b1) but i believe there are much more driver updates. By the way did samba get updated to the latest version - 3.2.4?
September 30, 200817 yr Author My system: Asus P5E-VM Do bios v.0803 Celeron 420 2 x 512mb kingston BQ! SP 450W 3 x HD501LJ, 1 X 7200.11 750GB, 1 X 7200.10 160GB Now, when SMP is supported, and some drivers got updated i'm waiting for security & reliablity improvements and revamping the web panel. What driver updates are you referring to? Actually i only refer to Intel PRO1000 driver update (v0.2.0 in 4.3.3, and v0.3.3 in 4.4b1) but i believe there are much more driver updates. I'll look into that, but you know what they say, "If it ain't broke..." By the way did samba get updated to the latest version - 3.2.4? This will be in an upcoming 4.4-beta.
September 30, 200817 yr Tom, can you update Smartcontrol in the next release? The current 5.36 does not run tests correctly on my Seagate 1 tb drives Will 5.38 do the job? yes - I believe that is the latest version. I use 5.38 and it works great.
October 1, 200817 yr Will 5.38 do the job? sorry I didn't answer sooner... Weebotech helped me getting 5.38 installed, and yes, indeed it works fine
October 1, 200817 yr Hmmm - I think I'm getting problems with the 2.6.26.5 kernel on my box. I got a bunch of messages like: ata1: link is slow to respond, please be patient (ready=0) ata3: link is slow to respond, please be patient (ready=0) ata1: COMRESET failed (errno=-16) ata1: hard resetting link ... When the boot finally finished, both of my Western digital 500GB green drivers were 'missing'. My maxtor SATA & WDC PATA drive did come up though.... Hmm - I removed the 1.5Gb/s link jumpers on one drive and it came up fine, though I'm a bit worried about long-term stability running the drives at full 3Gb/s - the motherboard is an older unit, and I used to get crashes under windows when I ran at full rate -- though with different cables. EDIT: Even with the drives at 3GB/s, they're not coming up reliably. Looks like I'm back to 4.3.3 for now, since the 2.6.24.4 kernel seems immune to whatever is afflicting me. This is what happened to me and I lost about 200gb of data.
October 1, 200817 yr This is getting insane. After the parity check I rebooted and everything came up green. I check my shares and lots of folders are missing. When I tried to stop the array I get the devices busy and a bucket load of error messages. What should I do? Roland Edit: added screen shot
October 1, 200817 yr This is getting insane. After the parity check I rebooted and everything came up green. I check my shares and lots of folders are missing. When I tried to stop the array I get the devices busy and a bucket load of error messages. What should I do? Roland Edit: added screen shot DO NOT press "Restore" Do NOT press "Format" It appears as if some of your drives did not "mount", therefore, the files on them are not currently visible to you.... (They are probably there, once you can get things back to normal and get the disks back mounted) typing mount will show you which drives did get mounted. The messages at the end of your syslog indicate you have a lot of corruption on the file-systems on your disks. They all need to be checked in turn using reiserfsck -q -y /dev/mdX where mdX = md1 through md8 If any errors are reported, you will be instructed by reiserfsck to run it again with the appropriate option. Do not run the rebuild-tree option more than once on a drive until it can pass a simple check as described above. Joe L. First step is to get back to a working configuration... I'd put the newer version of unRAID (just released) on the flash drive and try once more.
October 1, 200817 yr No risk of me pushing one of those buttons after all the trouble I have had. I am running reiserfsck -q -y /dev/mdX on each of my drives now. Thanks for your help. Roland
October 1, 200817 yr ok I have run through all my disks. Don't know the damage yet, but 2 needed to be rebuild (--rebuild-tree). What do I do now? The disks still show up as unformatted. mount /dev/md2 /mnt/disk2 gives the error message mount: mount point /mnt/disk2 does not exist. This is the same for the other disks as well. Roland
October 1, 200817 yr ok I have run through all my disks. Don't know the damage yet, but 2 needed to be rebuild (--rebuild-tree). What do I do now? The disks still show up as unformatted. mount /dev/md2 /mnt/disk2 gives the error message mount: mount point /mnt/disk2 does not exist. This is the same for the other disks as well. Roland A mount point is just an empty directory. When unRAID did not find a file-system on the disk, it did not create the directory. Just type mkdir /mnt/disk2 and the mount point will then exist. There are warnings about doing multiple rebuild-tree's on the same disk while it is corrupted. Are you sure it is not asking you to do a fix-fixable instead? or are these drives you did not do a rebuild on before? Joe L.
October 1, 200817 yr On a few I used fix-fixable (result after running reiserfsck -q -y) and on two I was "told" to use --rebuild-tree. I don't think that I have done any multiple rebuild-tree on the same disk. I created the mount points and all disks mounted. The only disk that isn't mounted is the cache, since I don't know which disk it is: mkdir /mnt/cache -- mount /dev/? /mnt/cache. What is next? Should I install the new unRaid version on the flash and stop and reboot? I have to admit I am worried what will come up when I try to stop and reboot, since I have had problems with that. Assuming all goes well, should a new parity check be done? Thanks for your help and time. Roland
October 1, 200817 yr Wow, Tom has already figured out and fixed the problem, saved me some discussion! My thoughts on btlupin's issues were similar to what Tom has called the first bug, because this is now the third or fourth time I have seen similar error sequences following a probable Spin Up button click. btlupin: it appears you 'pressed' the Spin Up button, and after a brief delay, the Timeouts began, resulting in 3 of 6 onboard connected drives timing out, and 3 of 4 drives connected to a Promise card reporting the same Timeouts (exception Emask, Timeout, frozen). The resultant resets then caused more trouble, but it appears to me as if higher level modules are not being made aware of the drive troubles, and they (reiserfs and unraid) continue to send commands, resulting in more errors logged. Tom has added in v4.4-beta2 an extremely patient 30 second timeout, into the lower level code. In this case, once the drives have been disabled or communications lost, unRAID cannot fix them, and you HAVE to reboot for a fresh hardware identification. I strongly recommend you not just reboot, but power off completely for a cold start. Some hardware components need 5 to 10 seconds to electrically drain, for a true cold start. I can't help but think that there are serialization issues or a very poor implementation of the Promise driver or firmware, when 4 Spin Up's are sent simultaneously to the 4 drives on the Promise card, and 3 of the 4 time out. That is appalling! Not unRAID's fault, and I'm thinking Tom has been overly generous in saying this is a bug in unRAID. It is of course important for him to have issued a workaround for it, and he has, but he should not be taking the blame. I would like to recommend to all users with unRAID v4.3.3 or v4.4-beta1: Avoid using the Spin Up button. Some additional comments on v4.4: ACPI seems to be reporting more 'Thermal zones' with CPU temps, and more 'cooling devices'. The CPU temp may be accessible now on most machines, even without lm_sensors loaded. It would be nice to see it added to the Web Management page. The 'rootdelay=10' boot parameter has been removed from the syslinux.cfg entries. As noted previously, most of the ACPI errors are now gone. I had understood (wrongly apparently) that these were most likely bugs in the BIOS, but since they have disappeared from 2.6.26.5 syslogs, they may have either been bugs (now fixed) in the kernel, or now worked around or ignored Of possible interest to those interested in using cpufreq or similar, this line now appears in the syslog: cpuidle: using governor ladder I noticed, like another user, the console message that ifplugd could not install a second time. The syslogs show no issues, ifplugd installed correctly. I suspect there is an indirect second load of ifplugd somewhere. On my AMD nForce 570 machine, there is a small improvement in the XOR processing speed, from 8033.6 MB/s to 8311.2 MB/s, a measurable but probably not detectable difference. Perhaps the second CPU is assisting? Two Intel boards showed much smaller changes. There appears to be a substantial increase in ntp logged activity in the syslog, much of which seems unimportant. The Unmenu syslog viewer needs to be updated for v4.4... Edit: My recommendation to power off for 10 seconds was probably more extreme than necessary, 99.9% of the time. I had one Maxtor that needed that, and have seen other rare cases. I like to be safe...
October 2, 200817 yr Everything seems to be working again so far. I lost some data, but most of it is replaceable. Mostly I have lost a lot of time. I have set the spin down timer to never for now. I have replaced the original drive that came up red (though it is green now) and unraid is currently rebuilding. I don't know if it makes any different, but I think the drives that had slow spinups are all in a Chieftec 4 in 3 backplan. Is the replacement drive cleared first before rebuilding, or not? I'd like to thank everyone for their help, though I think Tom could have assisted more. He did find the bugs, which is good for everyone, but gave no assistance or advice to me. Roland
Archived
This topic is now archived and is closed to further replies.