Not sure what happened but noticed that computers no longer saw the unRAID server. Unable to telnet in. Or sign in when I plugged monitor/keyboard to unRAID server.

 

Had to hard powerdown, restart.

 

Parity check in progress.

 

PCs now able to connect to Tower but all the Shares were gone.

 

Went to Tower/shares.htm and nothing there.

Readded the entries.

PCs now see the shares but none of the files there.

Was now worried.  

 

Checked /mnt/disk1/LR and /mnt/disk2/LR and see the files there, but if I go to /mnt/user/LR and do a ls, I get nothing.

 

Help???  

Not sure what happened but noticed that computers no longer saw the unRAID server. Unable to telnet in. Or sign in when I plugged monitor/keyboard to unRAID server.

 

Had to hard powerdown, restart.

 

Parity check in progress.

 

PCs now able to connect to Tower but all the Shares were gone.

 

Went to Tower/shares.htm and nothing there.

Readded the entries.

PCs now see the shares but none of the files there.

Was now worried. 

 

Checked /mnt/disk1/LR and /mnt/disk2/LR and see the files there, but if I go to /mnt/user/LR and do a ls, I get nothing.

 

Help???   

Step 1.  Attach a system log to your next post.

 

Joe L.

Was unable to get the syslog from when it locked up.

 

Did some searching and found 1 post that mentioned that the shares would not be fully mounted after a "crash" until the parity check was completed.

Well that would be approx 300mins and WAF would go way down.

 

So I cancelled the parity check, did a clean shutdown, brought it back up, all shares are back and I'm good to go now.

 

Running Parity Check to make sure.

 

 

 

 

Did some searching and found 1 post that mentioned that the shares would not be fully mounted after a "crash" until the parity check was completed.

That is not an expected result at all, although you are the second person to report it.

 

What will happen is that the file systems will not be mounted until their journal transactions are replayed.  (They will exist if there was a lot of disk activity prior to the forced shutdown.)

 

On my personal server it took over 15 minutes in one case.  What I saw was several disks showed "unmounted" for those 15 minutes until their transactions could be re-played by the reiserfs file-system.  After that time, they mounted and I could see their files.  You just need to be patient.  re-booting will only make things worse.

 

I agree, having the array off-line during a 300 minute parity check is not an acceptable behavior, and would get the same lack of WAF here.

 

You might want to send an e-mail to support@lime-technology and point them to this thread... perhaps there is some condition as you describe where the array is not brought up until the parity check completes, but I doubt it, at least he will know what you experienced.  It is far more likely the file-systems were not yet mounted and he might be able to provide better error messages to the system console.

 

Joe L.

[What will happen is that the file systems will not be mounted until their journal transactions are replayed.  (They will exist if there was a lot of disk activity prior to the forced shutdown.)

 

On my personal server it took over 15 minutes in one case.  What I saw was several disks showed "unmounted" for those 15 minutes until their transactions could be re-played by the reiserfs file-system.  After that time, they mounted and I could see their files.   You just need to be patient.  re-booting will only make things worse.

Thanks

 

How "large" are the journals? What "flushes" them? How far back in time would the journals have transactions for?  What causes a "checkpoint" to be taken?

The journal sizes depend on how much was written to the drives but not fully completed. The Linux reiserfs driver and other OS portion flushes them when they're mounted.

I have the same problem. I'm using .14 with the m1015.

 

Is there a connection between the card and unraid?  Or the fiie system?

 

I fixed the last problem got the array up, ran a successful parity check then the system locked up and an overwhelming amount of valse errors. It's still running but unmanageable.

 

Any suggestions?

Beta 13 and Beta 14 does not support LSI Sata controllers. You will get massive false read errors and drives red-balling when they come out of spin-down during their spin-up. You will need to downgrade to beta 12 for your m1015 controller.

Someone, forget who, updated the package and supplied for the community to use and it seems to work OK until something triggers this panic.

 

 

The something is as simple as "accessing a spun-down drive on an LSI controller". Any Linux kernel in the 3.1.x through 3.3.x series has an issue with unRAID MD code and LSI controllers.