Partial success.

 

First I stopped the array, disabled user shares, restarted the array.

 

Then, using mc I copied all the files from /mnt/disk1 to mnt/disk4 that I wanted to copy.  (Then I deleted them from /mnt/disk1 because I was really trying to do a carefull move of these files)

 

So far, so good.  I was able to complete my file operations without the server crashing.  It seems that disabling the user shares did help!

 

Next I tried to stop the array again so that I could re-enable the file shares.  Maybe it's because mc was still running (I'm not sure) but the server wouldn't stop.  Instead all 5 data drives went into an 'unformatted' state and my only option again was to reboot the server. 

 

So... my files are moved, the server is rebooted, and parity sync is running AGAIN!!!  Arg.

 

Partial success.

 

First I stopped the array, disabled user shares, restarted the array.

 

Then, using mc I copied all the files from /mnt/disk1 to mnt/disk4 that I wanted to copy.  (Then I deleted them from /mnt/disk1 because I was really trying to do a carefull move of these files)

 

So far, so good.  I was able to complete my file operations without the server crashing.  It seems that disabling the user shares did help!

 

Next I tried to stop the array again so that I could re-enable the file shares.  Maybe it's because mc was still running (I'm not sure) but the server wouldn't stop.  Instead all 5 data drives went into an 'unformatted' state and my only option again was to reboot the server. 

 

So... my files are moved, the server is rebooted, and parity sync is running AGAIN!!!  Arg.

 

If you had "cd'd" to a folder on disk5 it would not be able to be unmounted.  When you try to stop the server, all the other drives would be unmounted and look as "unformatted" in the unRAID management console.  You probably could have logged off of telnet, exiting "mc" and then pressed "stop" once more to actually stop the array.

 

I had the exact same thing happen to me last night when I went to shut down. In my case is was a loop-back device I had connected to a backup file image of a laptop that was making the unmount fail because it was "busy"

 

Hopefully you will be able to get back to normal now (once parity calc is done) 

Yes, hopefully.  I've 'upgraded' to 4.4.2 (from 4.5 beta) and once parity sync finishes I'm going to try re-enabling the Go Script Manager.  If I get that far I'm going to try another file copy with user shares enabled and see what happens.  I've copied/moved larger quantities of files in the past and never had to disable user shares to do it.

 

As side note, I believe I noticed an unMenu addon that'll add the ability to do a clean shutdown.  Does this addon attempt to stop any processes that would prevent the drives from being unmounted?  Would this be a better way to ensure a clean shutdown more often?  (I sure hate to to do parity syncs when I shouldn't have to.  6 times in one month is more than enough!!!)

Yes, hopefully.  I've 'upgraded' to 4.4.2 (from 4.5 beta) and once parity sync finishes I'm going to try re-enabling the Go Script Manager.  If I get that far I'm going to try another file copy with user shares enabled and see what happens.  I've copied/moved larger quantities of files in the past and never had to disable user shares to do it.

 

As side note, I believe I noticed an unMenu addon that'll add the ability to do a clean shutdown.  Does this addon attempt to stop any processes that would prevent the drives from being unmounted?  Would this be a better way to ensure a clean shutdown more often?  (I sure hate to to do parity syncs when I shouldn't have to.  6 times in one month is more than enough!!!)

Yes, the unmenu Array Management screen does have a "stop-array" button, and it does attempt to terminate processes that may have files open.  It would have more cleanly stopped your server if you had used it.  Also there is a "powerdown" package posted that will cleanly shut down with Ctl-Alt-Delete or by typiong "powerdown" at the tenlet prompt.    But neither would not have helped me last night.

 

Now, just so you don't feel too bad, I used the unmenu Array-Management "Stop" button last night and it was then that I discovered unmenu does not check for loopback devices attached to files.  (A loop device is a way to make a file look like it is an actual disk partition, and it then lets you mount the "loop" device and interact with the file as if it was a real file-system.)  Now, most people will never set up a loop device like I did, but obviously I need to add code to unmenu to check for it too.  (The Lime-Technology supplied management page does no checks at all, other than shutting down SAMBA which it thinks is the only way to have open files.. ) It frequently will end up with some drives un-mounted (and reported as unformatted) and others still mounted.  Scares you the first time you see it, but no harm is done unless you decide to check the box to format the drives...  In any case the loop device kept the file system busy, so it could not be un-mmounted, but did not show up in an "fuser" command as we currently have it coded.  Took me a bit to figure out what was keeping the file-system busy... and how to delete the loop connection to the file.

 

I've done a lot of parity checking this past month too... you are in good company.

 

Joe L.

The clean powerdown package is the unmenu package file for Weebotech's clean powerdown script for unraid.  It helps prevent parity checks after GOOD shutdowns(your crashes would still have invoke the parity check).  It also adds the ability to do a clean shutdown by pressing the power button on the case (with support cases) and will allow ctrl-alt-del to produce a clean reboot (if you use that specific package).  You can do a search of the forum to find out more. or go here: http://code.google.com/p/unraid-powercontrol/

 

I don't think the Go Script Manager was causing the issues you were/are experiencing.  You seem to have your problems during heavy disk use which, from what I have read (in this thread and others), seems to be is associated with a memory issue.  I have tested many ways to make the boot procedures fail as a result of the .auto_goscript file contents you are using.  I had it hang once while using a windows eol file but on two other occasions it worked fine (with the windows eol)....  I have added some code to the newest version of the go script manager(hopefully out soonish... I have some features to iron out yet before I will be happy with it) to make sure that all the .auto_goscript files are run through a fromdos statement before they are run at boot to prevent this possibility in the future. I also added a delay before invoking .auto_goscript files.

 

Even when testing some of the pre-v0.1 code that was extremely buggy, the worst I did was crash unmenu.  The regular (stock) web interface was still accessible and I could still use telnet to kill and re-start unmenu.  

 

I hope you get everything figured out.

 

Cheers,

Matt

So, from the sounds of it, to help prevent unnecessary parity syncs I should use the 'stop-array' button on the unMenu Array Management screen AND look at installing the Clean Powerdown unMenu package.  I didn't understand that if the array was sucessfully stopped that there were still a possibility for an improper shutdown to cause a parity sync.  I figured that if the array was sucessfully stopped that I could simply hit the power button to restart.

 

As far as the Go Script Manager...  It wasn't contributing to my to my issues with copying files and locking up the server.  It was just that after the first such lockup I couldn't get the server to fully reboot until I disabled it.  I can't understand why. But now that I've got my copied I'm going to try to re-enable it.  I like the idea of not having modifications hardcoded in my go script.

I'm still trying to create a more stable unRaid.  Since I started this post, I have replaced the motherboard (with a faster one with a different Network card).  And, I've moved the parity drive onto its own controller.  I'm beginning to question the latest version of unRaid (currently running 4.4.2) because it is after upgrading that I started having this problem with my server locking up.  Early this afternoon my server finished syncing parity after placing my Seagate 1.5TB back into service.  While attempting to copy two 4GB files over (something I do all the time as I'm loading my movies onto the server) it locked up again!  When I say "locked up" I mean that I've lost all visibility to the server.  I can't ping it by name or IP and I can not Telnet.  My only option is to power it down, which of course results in another parity sync.

 

So, I'm syncing again.  Attached is a syslog after rebooting.  I don't see anything in there that looks suspicious to me, but maybe someone else can recognize a clue.

I too don't see anything wrong in the syslog.  You should not have locked up, or lost network connectivity, without even a hint in the syslog.

 

The usual advice would be to simplify, remove all the addons, by going back to the stock go file.  If you can run successfully that way, then begin to add things back one by one, until it fails.

Rob,  Not a bad idea.  I have to note, however, that this behavior just recently started.  I haven't added any add-ons recently.  The only significant thing I've done is upgrade to 4.4.2.  Maybe something about 4.4.2 doesn't like the add-ons that I was running previously (and still)?  Hmmm....

So, I disabled all add-ons and restarted the server.  Parity, and all else looked good.  So, I started a copy of ten 4GB files.  The copy got about 30% through an then BAM... It locked up again.

 

After powerdown/powerup parity sync started again. Not being in the mood to wait another 18 hours for parity to sync, I disabled my Seagate 1.5TB parity drive. I've got files I need to copy to the server!! Parity sync will have to wait.

 

By now I've got thirteen 4GB files to copy. I start the copy process and it completes without error.

 

My suspicions are now turning toward the Seagate 1.5TB drive. (Firmware SD1A). Does anyone else run one of these drives as parity?

 

I'm going to install a WD 1TB as parity and do more testing. I'll let everyone know how it goes.

 

All excited with my success...  Before I made any changes I ran another test to copy eight 4GB files to the server.  After 4 of the files copied, the server locked up AGAIN 

 

Since my saga began, I've replaced all the hardware except for the power supply, case, drives, and a Supermicro AOC-SAT2-MV8 8 Port SATA host controller.  At first I had all five WD 1TB data drives and my one Seagate 1.5TB parity drive running off of the Supermicro controller.  This had been my configuration for quite some time and I'd never had an issue.  I've since added a Rosewill e-SATA PCI RAID Adapter RC-209-EX controller and had moved my parity drive to that.  When I still had issues, I suspected my Seagate drive.  Now, I'm starting to suspect my Supermicro controller card.  Maybe having 8 SATA ports doesn't mean that it can handle that many drives.

 

So, for my next test I moved "disk4" (the drive I've been moving all these recent files to) onto the Rosewill controller.  Let's see if I can isolate the Supermicro controller as the problem. (I don't want that to be the answer, but I'd take any answer that results in a stable server.)

 

More to come, I'm sure.

Now I'm out of ideas.  My server just locked up again while copying a single 4GB file. 

 

I've replace all my hardware.  There is nothing left to replace except a brand new 610W single-rail power supply and I can't imagine that is causing my issue.  The only remaining variable is the latest version of unRaid itself.  I'm having a difficult time believing that I'm the only person having this problem.

 

Unless someone is reading this and has a suggestion for something I haven't thought of, I'm out of ideas and will try to run without parity while I load my server.  Thankfully, when I'm done loading most all of my data will be static and I don't seem to have any problem with reading.

 

Maybe things will get better with the next unRaid version.  I can't imagine what else to do.

Well, this issue is still haunting me.  I've discovered that while I'm still loading these 4GB files to my server (I have about 130 left to go) the only way I can keep the server from intermittently freezing is to disable my parity drive. 

 

Another alternative would be if there is some way to disable the automatic parity sync when hard-booting.  Every time I had to hard-boot and did let parity sync finish, it finished with 0 errors.  So, my assumption is that when this does happen and I have to hard-boot that parity sync isn't really needed.

 

Is there something that I could put in my go file to prevent this automatic start of parity sync?  It'd be nice to have more control over this.

Well, this issue is still haunting me.  I've discovered that while I'm still loading these 4GB files to my server (I have about 130 left to go) the only way I can keep the server from intermittently freezing is to disable my parity drive. 

 

Another alternative would be if there is some way to disable the automatic parity sync when hard-booting.  Every time I had to hard-boot and did let parity sync finish, it finished with 0 errors.  So, my assumption is that when this does happen and I have to hard-boot that parity sync isn't really needed.

 

Is there something that I could put in my go file to prevent this automatic start of parity sync?  It'd be nice to have more control over this.

 

Not that I know of, but you can cancel the parity check after it starts.

Not that I know of, but you can cancel the parity check after it starts.

 

Yes, as I'm beginning to understand how parity works I believe your are right and that would be the same result.  But one thing I've noticed on my server is that when parity sync starts at boot, unRaid has a difficult time mounting my other drives.  It'd be nice to have the option at boot to assume good parity and not have to touch the server.