Good Morning Joe 

 

I guess I would agree at this point, I've just uploaded the current syslog via SavFile - http://www.savefile.com/files/1237224

 

You really may not want this as I was surprised by the size, the original I sent was 20KB, this one (still uploading) is 49+MB.  Evidently something is going on that I can't quite fathom      .  Please don't spend too much time at this point, since I think the drive is Toast, but I do find it interesting that there has been such a change to the Array.

 

I would guess that if you see anything else (or Rob or Tom) affecting my Array, I'd really like to know.

 

Regards,

 

Dave  :'(

Good Morning Joe 

 

I guess I would agree at this point, I've just uploaded the current syslog via SavFile - http://www.savefile.com/files/1237224

 

You really may not want this as I was surprised by the size, the original I sent was 20KB, this one (still uploading) is 49+MB.  Evidently something is going on that I can't quite fathom      .  Please don't spend too much time at this point, since I think the drive is Toast, but I do find it interesting that there has been such a change to the Array.

 

I would guess that if you see anything else (or Rob or Tom) affecting my Array, I'd really like to know.

 

Regards,

 

Dave  :'(

The log is filled with error messages (sample below) as it tried to access drive "hdg" as it tried to access each sector in turn when clearing/formatting it.

 

Until you can replace the drive, to protect your other data, stop the array, unassign disk6, then again on the main screen check the checkbox and press the "Restore" button to make it forget it ever had a disk6.  It should build parity on all the remaining assigned disks and they will be protected until you can put a new drive in disk 6's slot.  At that point it will be as if you are adding it new.

 

Don't want to have you risk losing any other data if a different drive were to fail.

 

Joe L.

 

sample error messages filling your log are here:

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283390

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283392

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283394

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283396

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283398

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283400

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283402

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283404

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283406

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283408

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283410

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283412

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283414

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283416

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283418

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283420

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283422

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283424

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283426

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283428

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283430

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283432

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283434

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283436

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283438

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283440

Dec  1 22:55:05 Tower kernel: end_request: I/O error, dev 22:01 (hdg), sector 44283442

Whoa:

 

Well I was able to stop the Array, but then lost access to Main/Devices etc.  Went to telnet to try an Halt the system and it would not let me login with 'Root' as password, so forced to manually reboot.  Able to get to Main and stop Array this time and then to Devices and remove Drive6.  Then went back to Main and clicked box to allow Restore.  System is currently performing a Parity-Sync currently estimating 465 minutes.

 

Hopefully, everything is ok    Haven't tried to access it since all this was going on.  Just tried to telnet back to Server and it again allowed me access to Root, so must ? be ok!

 

Geez, what a mess!  Thank you all for coming to my rescue, I'm sure if I hadn't noticed the BIG RED DOT more by accident than design, I might have lost all my data!  At this point what would you recommend once the Array is hopefully rebuilt w/o current Drive6?  Would you suggest upgrading to 4.2.1 before installing another Drive6?  As Rob noted, too many variables make it impossible to determine the problem or cause(s).  Also, I'm a bit concerned at what was described earlier with the drives being sequenced incorrectly - hopefully that was related to my failing drive6 but .

 

Again, not enough words to THANK YOU all, particularly JOE L. for the response and support!  What a Forum and what a Group!!!    :)

 

Warmly,

 

Dave 

Before you upgrade I'd like to see you able to stop the array and shut down without having to press the hardware reset button on the computer.  I'd like to see it then power up and start without errors.  Then we can talk upgrade time.

 

Let's see if the parity check goes smoothly. Once it is complete, your data on the remaining drives is protected

 

You can add a replacement drive6 back once you are on 4.2.1 or before, your choice.  (If things are stable, I'd probably put 4.2.1 on your other flash drive, leaving the current flash drive on 3.0 as a fallback.)

 

Joe L.

Hi Joe/Rob:

 

Just completed Parity Check/Stop/Shutdown (removed offensive drive6) and startup.  I've uploaded the two new syslogs (immediately following Parity Check ~ 45K) and following reboot (~ 26K) so I think things are back in order.  Parity states its Valid with 0 Errors    !  Also just checked a random film through the Movies Share and it worked fine!

 

If you have a minute to check the Syslogs to see if there are other problems, I'd appreciate some feedback.  Again, don't really know how to thank you for all your help and assistance  !!!

 

Let me know if I should try to switch to 4.2.1?

 

http://www.savefile.com/files/1238013 - Syslog3 - After Parity Check before Restart

http://www.savefile.com/files/1238036 - Syslog4 - After Reboot

 

Does UnRaid still start/stop and re-order the disks?

 

Warmly,

 

Dave

 

Well, this is progress - no errors, but the startup behavior is still bazaar.  The drives are initially matched up backwards, all are then marked 'Wrong', then it reloads them in the correct order and proceeds on, with no further problems, and this is both before and after your successful shutdown and reboot.  I have never seen anything like this in a v4 syslog.  Unless Joe has another idea, I think it is time to reboot with v4.2.1.

 

Hi Rob,

 

Thanks for the info, somewhere in the deep dark recesses, I seem to remember that Tom indicated a problem (probably from version 1) with several computers loading data in Reverse Order.  As I recall, the config file had to be modified to change the order.  I'm not sure (can't remember  ) whether that applies in my case, but I wonder if something like that might be possible.  I started with an original 128MB Key from Tom, then migrated to the Pro Set following his instructions, if we copied the 128MB Key Config d/t the unusual at that time MB (ASUS P5PE-VM), then that might explain the current problem.  Below is my config file (disk.cfg) as currently on the Flash.

 

# Disk configuration

spindownDelay=1

parity=/dev/hda

disk1=/dev/hdb

disk2=/dev/hdc

disk3=/dev/hdd

disk4=/dev/hde

disk5=/dev/hdf

 

I don't think there is anything unusual, but maybe you'll see something that I don't.    Is there another file that you would like, please advise?

 

Dave

 

I did a quick search in the "unRAID Server 3.0" forum for "syslog" and found this old post with a syslog from version 3.0 of unRaid attached: http://lime-technology.com/forum/index.php?topic=382.msg2835#msg2835 .

Downloading the attached syslog, I see the same strange behavior. It too loads up the disks in the wrong order, then unloads the md module and then loads the disks in the correct order.

 

Looks to me to be a bug that was subsequently fixed in a later release.  Can't think of any reason why the disks would be loaded in the wrong slots on purpose, then the module unloaded, then re-loaded with the disks in the correct order.

 

So... time to load 4.2.1 on your other flash drive and get it going.  Be sure to set the volume label on it to UNRAID.

 

Joe L.

 

 

Hi Joe/Rob:

 

Well after getting everything done that you suggested, I installed 4.2.1 on the other Flash and re-booted.  At first I couldn't access the Main.htm, but guessed rightly that it was located at another address (DHCP).  Able to find it from my Router Table and then access Main.htm.  As noted no drives recognized until assigned but first I reset the System to my static IP (also fun trying to get back to Main.htm).  After getting in, I followed the instructions from Tom and assigned the drives (interestingly they were listed in natural order).  I then started the Array and it is currently Parity Syncing (another 500 minutes).  I've copied a new Syslog.txt to  http://www.savefile.com/files/1238467 for your review, though it may need to be updated once more after the Array is started (would think that stopping, shutting down, restarting would be correct ).  As this will take all night, I'll try to catch y'all (originally from the Deep South) tomorrow!   

 

Gratefully,

 

Dave 

My upgrade to 4.0 did the same thing. Although nothing has changed, it wanted to do a full parity calculation. (and did)

 

From now on, on this version of unRaid, the full parity calc will only occur if you do not shut down cleanly. If you stop the array first and then power down, it will not normally do a parity check upon power up.

 

Wow, what an experience for you.  Time to RMA the defective drive.

 

See Ya'All in the AM (I am in the deep South)

m'ning Joe  !

 

Everything looks clean today, though I note that none of the green "lights" are flashing.  In the older 3.0 blinking lights meant that the drives were idle (temps are listed indicating they're spinning), did I miss something or is it just too soon (overnight for parity check)?  I just went to the Settings and clicked on 1 hour spin down even though it appeared in the box anyway.  I thought that in the older system those boxes went grey if invoked. 

 

At this point the Array is up w/parity and 0 errors, so I'm thankful to you and Rob for your great help!  Yes, I do think its time to RMA the Drive, its out and marked, so will try to get that done today/tomorrow.  I also have the other drive sitting on my desk to install in its place, but will just let it be for the next 24 hours or so!

 

Again I can't thank you both enough, have a great Holiday Season!!!    And if you get a chance, I'd appreciate any thoughts re: direct output to the TV/Projector idea (we could do that in another thread).

 

Warmly, Gratefully and Thankfully,

 

Dave