i just rebuilt my unraid server (4.0) with a new motherboard (p5b-vm DO), and now in the web interface i have a red icon next to my disk2.

 

i have read that this means that the disk is offline or disabled, but that cant be because if i go to one of my windows computers and navigate to \\storagetower\disk2 i can see all the files on there and read and write to it.

 

so if the disk is not disabled, what does the red icon mean?

 

 

You are not reading/writing that drive, you are using the redundant capability of the system to pull your data off of other drives.

 

Per the posted documentation:

 

"When a disk reports a failed write operation the system will disable the disk. A disabled disk will no longer be used in any way by the system. The disk still appears as a share, and you may still read and write it; however, the array will be running unprotected and another disk failure will cause data loss."

 

 

Bill

 

ah ha!  thanks for clarifying - looks like i need to get another drive pronto.

 

wonder why it failed - its a fairly new drive.  oh well hopefully its still under warranty.

looks like the drive is still under warranty so i will be shipping it back to seagate for a replacement.  in the meantime is there anything i can do to prevent the system from running in unprotected mode without losing the data on the filed drive?

A significant number of drives fail when they still have that new drive smell - it is referred to as "infant mortality" and is not unusual at all.

 

Large shops will often burn-in drives to catch these problems, do some random read/write activity for a week or so and return the failed drives.  I actually do something similar at home, but it is not as intense.  If I get three new drives, for example, I will copy a large set of ISOs to drive one, then from drive one to drive two, drive two to drive three, then loop around again.

 

 

Bill

looks like the drive is still under warranty so i will be shipping it back to seagate for a replacement.  in the meantime is there anything i can do to prevent the system from running in unprotected mode without losing the data on the filed drive?

 

I would install another drive.  Assuming it was not the parity drive that failed, you only need to insert a drive that is large enough to hold the files you had on the now-bad drive, so it is possible an older drive will do the trick.

 

 

Bill

unfortunately it was a 500G drive with about 400G of data on it.  so i guess my best bet is to go and buy another 500GB drive locally and drop it in while i am waiting for the warranty drive to be shipped.  then when i get the warranty drive i can just throw it in as an additional drive.

unfortunately it was a 500G drive with about 400G of data on it.  so i guess my best bet is to go and buy another 500GB drive locally and drop it in while i am waiting for the warranty drive to be shipped.  then when i get the warranty drive i can just throw it in as an additional drive.

 

I figured that my sage advice wouldn't work.  LOL!

 

You always have three choices:

 

1. Continue to use the system as-is and take the risk

2. Shut everything down and wait for the new drive

3. Do what you are suggesting, go buy another drive and the replacement drive will then expand your capacity

 

Given the large dataset on the bad drive, #1 is a poor choice and #2 may not be feasible, so buying the extra drive sure sounds right.

 

 

Bill

 

i just rebuilt my unraid server (4.0) with a new motherboard (p5b-vm DO), and now in the web interface i have a red icon next to my disk2.

 

i have read that this means that the disk is offline or disabled, but that cant be because if i go to one of my windows computers and navigate to \\storagetower\disk2 i can see all the files on there and read and write to it.

 

so if the disk is not disabled, what does the red icon mean?

 

 

If you JUST rebuilt your server there is a possibility that your cabling to that one drive is not seated correctly.  Yes, it could be the drive itself, or you could have zapped it (or the controller at the other end of its cable) accidentally with a static discharge when handling it during the rebuild, or it could be a poorly seated cable, at either the disk end or the disk controller end. It could even be a bad power cable.  I'd personally check out the cabling before deciding it is the drive at fault.

 

Joe L.

i will do that.  thanks for the tip.

well i tried re-seating the cables and everything and still it comes up with the red dot so i will assume that it is dead

 

 

well i tried re-seating the cables and everything and still it comes up with the red dot so i will assume that it is dead

Try it on a different cable... In other words, swap it with a different drive on a different cable and a different controller.  A IDE/SATA cable could have gone bad, or a power cable, or the controller.  If swapping all those result in the same dead drive, then say a prayer for it (if you are religious) and RMA it.

 

Joe L.

ok so i determined that the drive is definitely bad and i shut down the server and pulled out the failed drive so i can ship it back to seagate.  i booted the server back up and it didn't look quite right so i shutdown, put the drive back in and booted back up.  something was still weird and in an effort to start the array i ended up clicking the restore button. now it says the array is starting and the parity drive has an orange icon and disc 1 is red - all others are green and say "Mounting" under the "Free" column.

 

this was a few hours ago and there has been no change

 

what do i do?

originally after replacing my motherboard disk 2 said it had failed.  so in the process of trying to remove the proper drive to ship it back i accidentally ended up hitting the rebuild button (which rebuilds the parity right?)  and now when i boot up the system, the parity drive is orange, disk 1 is red and all other disks are green and say "mounting"  and read value is set to 24.

 

not really sure how to proceed.  i will gladly post my syslog file - but where do i find that?

 

any help would be greatly appreciated.

 

I felt it was best to respond to your post in your original thread.

 

To obtain a copy of your current syslog, at the unRAID console or in a Telnet session, type the command:

 

  cp  /var/log/syslog  /boot

 

This will make a copy of the system log in the root directory of your flash drive, which you can either copy directly from the flash share of your server, or plug the flash drive into your PC and access the syslog there.  Any file manager such as Windows Explorer can access the file across the network.  For example, if your unRAID server name is Tower, then you can access your newly created syslog as \\Tower\flash\syslog.  I recommend renaming it with the date and time and the .txt extension, for example syslog2007-08-28-1630.txt.

 

Would you clarify your situation as to which disks are bad?  You mentioned that Disk2 failed, but you have now indicated that Disk1 is red and the others are green.  Did you mean Disk2 (not Disk1), or did you re-assign the drive that was Disk1 to Disk2, or are you saying that now Disk2 looks fine but Disk1 has now apparently failed?  It seemed pointless to say more until I understood more accurately.  Your syslog would help greatly of course.

 

One thing I have found is that when unRAID disables a drive (marks it red), the drive may still be in perfect shape.  Because of a lemon motherboard, I had disk controllers that would suddenly quit, causing the attached drives to be disabled.  Unless it was in the middle of a write, the drives were still perfect, without corruption.  Even in the case of an interrupted write, reiserfsck plus deletion of last written file would restore the drive.  I also have an older Maxtor that if allowed to spin down, cannot wake up.  It then shows disk errors, then is disabled, but is actually perfect after a reboot.  But in each of these cases, unRAID has to mark the drive as bad, and force a rebuild, completely unnecessarily.  Besides wishing for individual control of drive spindown to keep the Maxtor up, I have wished for a way to force a parity check, regardless of what unRAID thinks is the right next step.  I want a way to tell unRAID that irregardless of what it thinks of the situation, I know the drives and parity are all perfect, so just do a parity check to confirm.  I've had to rebuild about 5 or 6 times, unnecessarily.

 

As to rebuilding/restoring, I think there may be 2 different Restore buttons, that result in 2 different rebuilds.  When I have chosen one, the parity was rebuilt.  When I have chosen the other, the data drive was rebuilt.  The only difference in the end was that it was quicker to rebuild the 300GB Maxtor data drive than to rebuild the 500GB parity drive.

 

Apologies for drifting a bit from your problem...

 

The read value of 24 is not a problem, quite normal when the Reiser file system is mounting the drive.

 

thanks for getting back to me - hopefully you can help as i really am not sure how to proceed.  first of all  - attached is my syslog file.

 

now let me clarify my series of events.  after rebuilding my system with the new mobo, i fired it up and it said disk 2 was disabled.  after some troubleshooting, disk 2 actually appeared to have failed.  so at that point all drives were green except disk 2 which was red.

 

next is when i accidentally hit the restore button.  after that the parity disk turned orange, disk 1 turned red and disk 2 turned back to green.  that was its status (parity is orange, disk 1 is red and all others are green).  unfortunately it seemed to be stuck in the mounting process.  in the "Free" column all the data drives said "Mounting" and down below the only option was refresh, which didn't seem to do anything.  and it just sits in this same state indefinitely. see the attached screenshot for details.

 

so just moments ago - i rebooted the server and then like magic, all the drives came up blue.  and the array was stopped.  so i clicked on start and now all disks are green (including disk1 and 2) and it seems to be doing a parity rebuild.

 

so i dunno what that was all about but hopefully now it will get the parity rebuild and all will be well.

 

 

ok so after my last post i thought i was in good shape - the parity was rebuilding and everything seemed ok but just a moment ago i went to his the web interface to see what percentage the parity rebuild was at and the interface didn't come up.  so i went to the console and noticed that it says the following:

 

[ 9575.101480] REISERFS: abort (device md1): Journal write error in flush_commit_list

[ 9575.101583] REISERFS: Aborting journal for filesystem on md1

 

also when the parity rebuild was working earlier - if i looked at the front of the server on all the drive bays the activity lights were flashing.  now the activity light is on solid on disk1 and the activity light is off on all other drives.

 

what does all this mean?

 

any help would be GREATLY appreciated.

Thank you for the syslog.  I'll need another one now that things have changed, with the new Reiser errors listed in it.

 

The syslog stops before Disk8 responds, so I think it must have been captured before the screen was captured.  Only Disk2 and Disk3 are responding.  It's trying hard to mount Disk1 but failing.  This is the second time in 2 days that I have seen unRAID trying to mount an uninstalled drive, your Disk1 and Critical's Disk8.  Tom will have to look at this.  I can see it trying to mount a pseudo drive, with the unRAID driver intercepting the calls to the missing drive, but the fact that the reiserfs is returning errors cannot be correct behavior.  Trying to mount the 'uninstalled' Disk1 is what probably caused everything to hang.

 

The fact that they came up blue was probably a good thing.  Just guessing here, but it looks to me as if unRAID realized something was wrong with its drive list, and reset the whole list, marking them all New (blue).  You didn't mention it but I assume you assigned Disk1 to the missing WD500, before restarting the array.

 

One smaller issue, the Maxtor 80GB caused a couple of dma errors, don't know why.  At first, I thought it might be too old to support SMART, but it shows a temp, so SMART is working.  You might try the command 'hdparm -I /dev/hdg' and see if anything odd jumps out at you.  Compare it with another Maxtor, hdh or hde.

 

I have to comment on the following rather exciting extract from your syslog:

Intel® PRO/1000 Network Driver - version 7.4.27-NAPI

e1000: 0000:00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:1b:fc:62:7c:bc

e1000: eth0: e1000_probe: Intel® PRO/1000 Network Connection

At least several users have been waiting for support for a PCI Express gigabit network card, and this looks like the first time I have seen or heard anyone successfully using one.  This appears to be an Intel PRO/1000 PCI Express card, or is it onboard?  Can you confirm?  Can you provide the exact name and model number?  I'd like to pass this on in the related thread started by cmhardwick:  http://lime-technology.com/forum/index.php?topic=797.0.

 

thanks for getting back to me. since i last posted, i made the decision to reboot the server since the parity build seemed to have stopped and hung during mounting. so what i did was to reset sata in the bios from AHCI to IDE. by doing that it would cause unraid to see several disks as missing and not start the array.  so i reassigned the disks properly and started the array which started the parity rebuild again.  i let it run overnight and it seems to be still going and is currently at 5%.  with any luck this one will finish.

 

last time when i posted my syslog i got the file by plugging the flash into my PC (since the array would not start )  now the array is started to so i could just set the flash as a share but i am reluctant to rescan the shares and enable that while the parity build is running since it failed last time.  but if the parity build fails again then i will go ahead and post the syslog.  i wonder if unraid has a problem when i set SATA in the bios to IDE instead of AHCI?

 

as for the PCI Express NIC, i never had one installed.  originally i was using the onboard NIC on my P5PE-VM mobo.  that port failed a few weeks ago at which point i put in a COMPUSA branded PCI gigabit NIC.  i left it that way for a few days before i shipped the mobo back to newegg and ordered my new p5b-VM DO mobo which is what is installed right now and i am currently using the onboard port on that mobo.  so i can only assume that the entry you found in my syslog was referencing the PCI card i had installed and misinterpreted it as a PCI express card.

ok so i let my server sit overnight and all of today and the parity rebuild is still cranking - it is almost at 10 % now.  so assumign it finishes, it seems liek it may take a few days.  but the thign that concerns me is that when i looked at the console this morning i saw a screen full of these erors:

 

[ some number] Hangcheck: hangcheck value past margin!

 

and i copied the new syslog over to my PC but unfortunatley i cannot attach it here because the forum only allows 128K and my syslog is 2.2MB.

 

so i uploaded it to my server and you can grab it here:

http://www.deewebdesign.com/syslog_new.txt

 

my concern is that even if the parity rebuild finishes there may still be problems if it is throwing these errors.  what do you think?

It's definitely not looking good, and if it were me, I'd give up rebuilding parity (unassign the parity drive) until I had a reliable running system.  Disk3 is causing 99% of the problems.  You Started the array rebuild at 5:21 AM, 20 seconds later had the first of many many errors from Disk3 (Seagate 500, Ser# __5G8), and by 5:37 AM, Disk3 had been downgraded all the way to PIO0 mode.  Every time it caused errors, there appears to be a 30 second timeout, then it causes all of the SATA drives to be reset and reconfigured, and another attempt is made to slow Disk3 down further.  It finds it is already at the slowest speed, so reconfigures it one more time as PIO0, and continues.  This could take a VERY long time, with no guarantee it is working correctly anyway.  It is still doing it at the end of the syslog, 15 hours later, and you say it has only gotten to 10%.

 

This Seagate (Disk3) needs to be tested to determine if it is good, perhaps by hooking it up to a Windows computer and formatting it?  Is this the drive that first appeared to fail?  Perhaps swapping its position, to a different cable or SATA connector might make a difference.

 

This thread http://lime-technology.com/forum/index.php?topic=918.0 seems relevant to you.  You might try the suggested irqpoll parameter, and play with the IDE/AHCI switch, with the parity drive off.  I would try reading and writing to each of the drives, to ensure which ones are working correctly.

 

The command 'hdparm -I' will show you the capabilities and configuration of a drive.  I would run it on /dev/hdg and /dev/hdh, and check whether they are running at full speed.  Both had DMA problems early in the syslog, and may be running in a PIO mode, which is very slow.  The mode is in the DMA or the PIO line, marked with an asterisk, and you want the mode to be udma5 or udma6.

 

I would also try running the reiserfsck command on each of the data disks.  Stop the array, and at a console or in a telnet box, type "reiserfsck -y /dev/sdd1".  If it tells you to rerun with --fix-fixable or --rebuild-tree, do it.  Then repeat for each of the data drives, but not the parity drive.  Change sdd1 to sdc1, then sdb1, hde1, hdf1, hdh1, hdg1, and sde1.

 

The hangcheck messages don't appear in the syslog, but I assume they correspond to the 30 second timeouts, associated with the Disk3 errors.

 

As to the huge syslog, I zip them when they are large, since they are just repetitive text, especially the larger syslogs, and compress very small.  Your 2.2MB syslog zipped to 160K, still too large to attach, but a lot better.  Zipping them also ensures they are received intact.

 

thanks for getting back to me.  i dont understand how my array could have gotten so screwed up.  regardless, if i were stop the parity rebuild, shutdown, replace disk3 with a new disk, and reboot - would that work or would i lose all my data since the parity hasnt been rebuilt?

 

i am not terribly proficient with linux but i will look into your suggestions and see if i can make sense out of any of it.

thanks for getting back to me.  i dont understand how my array could have gotten so screwed up.  regardless, if i were stop the parity rebuild, shutdown, replace disk3 with a new disk, and reboot - would that work or would i lose all my data since the parity hasnt been rebuilt?

 

i am not terribly proficient with linux but i will look into your suggestions and see if i can make sense out of any of it.

If the disk drive is defective, it will need to be replaced.  If the disk controller is defective, or the cable is defective, they will need to be replaced.  No matter what it is, if the defective component remains in your system it will continue to cause you all kinds of errors and data corruption until it is replaced.

 

You have suspected the bad disk drive for about a week or so. If you can, get a replacement disk and install it in a spare slot.  Assign it on the web-interface to any spare slot you desire. Temporarily un-assign the parity drive and disk3 and start your array with them unassigned, This will protect whatever data is on disk3 for the short term.

 

The unArray web-page should prompt you to format the new drive.  Do that.

 

Once the new drive is formatted, if everything is looking stable, stop the array, assign what was disk3 to a spare slot on the unRaid array, leave the parity drive unassigned.  For now, do not enable user-shares. Once things are stable you can re-enable them.

Export the disk-shares as read/write.

 

While the array is stopped, you might want to run the reiserfsck command as already described on the disks in your array (all but the parity disk).  Once you think any file-system corruption is fixed, you can proceed.

 

Re-start the array...  From windows you should be able to browse to the old disk3.  (You might have assigned it to a new logical slot, or left it in slot3)  If you can browse to it, copy whatever files on it you care about to the new disk you purchased.  This may take a while, especially if it again shows the errors it has been exhibiting.

 

Next, stop the array, remove the defective disk3, re-assign the parity drive, and re-start the array. It should re-build parity and complete within 2 to 5 hours. (My IDE based system takes about 5 hours, other with SATA systems have reported 2 hours or less, yours should take somewhere in that range.)

 

Finally, take the defective disk and place it behind the left-rear tire on your car.  Back over it.... multiple times...  This will enable the dense-compression mode of the disk-platters.   Place the pieces in the trash, or send them in for warranty replacement. It will not be the first drive returned in that condition to the drive manufacturer, they'll understand fully. (They may not replace the drive once you crush it, but they will understand  ) 

 

Unfortunately, this is probably your best chance of recovering any of the data that was on disk3.  You could have used the parity drive to recover your data, but early in this process you pressed the wrong button and asked that the array parity be re-calculated using the remaining drives (without disk3) and overwrote its knowledge of what was on disk3. It therefore is not usable for data recovery until it has been successfully re-built once your data drives are stable again.

 

Joe L.

thank you so much for all your help - i will give that a try when i get home from work.  so just so summarize, i should do the following:

1) install a replacement drive in any available slot and power up the server

2) under "Devices" in the web interface - assign the replacement disk to any available slot (lets say disk 9). and unassign the parity disk AND disk 3

3) start the array which will prompt me to format the replacement drive (disk 9)

4) once format of disk 9 is complete, stop the array and reassign disk 3 (but not the parity drive).

5) start up the array again and from a windows PC, move whatever data i can get from disk 3 to disk 9.

6) once i have gotten all the files off of disk 3, stop the array again

7) with the array stopped, remove disk 3 (and do very bad things to it  )

re-assign the parity drive and start the array back up.

9) this should rebuild parity - deleting any remnants of disk 3 and adding the new disk 9 to parity.

 

does this sound about right?

 

also one other question - based on your previous post, when i am running reiserfsck on the drives i assume the following:

 

sdd1 = disk 1

sdc1=disk2

sdb1=disk3

hde1=disk4

hdf1=disk5

hdh1=disk6

hdg1=disk7

sde1=disk8

 

is that correct?

 

thanks again for all your help!

 

 

 

one more - question - how can i start my array to copy data from disk 3 to disk 9 if the parity drive is unassigned - unraid won't let me start it (the start button is disabled) when the parity drive is unassigned.

one more - question - how can i start my array to copy data from disk 3 to disk 9 if the parity drive is unassigned - unraid won't let me start it (the start button is disabled) when the parity drive is unassigned.

You will need to check the "checkbox" under the "start" button.  It should then enable the start button.

 

Joe L.