It all started with unRAID box seeming to freeze during a read while copying some content to my local PC.  It froze twice on the same file.  The first time I just restarted the copy and the second time I tried to shut down the array and was going to reboot the box.

 

During the stopping of the array, everything on the unRAID box froze.  I let it be for about an hour and eventually tried to stop it manually at the command line.  Not being able to do that, I manually restarted the box and figured I'd just have to let the parity rebuild.

 

When the box came back up, parity started to rebuild and was going along fine at 80 M/sec.  Checking later, parity check had stopped.  I kicked the box again and partiy check restarted, failing again around 45%.

 

I'm assuming I have a bad drive (since the read stalled on the same file twice) and the parity can't complete because of it.  This is very worrisome that this situation can occur.  I'm guessing I would have to copy the data I can off of the failing drive, drop in a cleared drive and then copy everything back?  

 

SYSLOG below.

 

 

 

syslog.txt

Hold on with the copying text into the reply boxes!!

 

You can save the syslog as a text file and attach it to your first post... PLEASE do that!

 

AND

 

give us a list of your hardware and tell us when you started having this problem

Sorry for that.

 

Hardware is an Asus A8N-SLI deluxe.  I'm using the on mobo SATA ports.

 

Drive are as follows:

 

parity ST32000542AS_6XW1FZ9R                           2 TB

disk1  [browse /mnt/disk1] ST3500630AS_9QG071D6           500.11 GB

disk2  [browse /mnt/disk2] ST32000542AS_6XW1RZ27              2 TB

disk3  [browse /mnt/disk3] Hitachi_HDT72101_STF604MH0J725B  1 TB

disk4  [browse /mnt/disk4] SAMSUNG_HD204UI_S2H7J9FZA01146 2 TB

 

Problem started yesterday during a marathon copy of data to MY PC.  Was copying a slew of stuff for a friend.  During the copy transfer came to a halt and I had to restart the box with the power switch because the array would not shut down, even from command line, manually umounting drives and killing PID's.

 

Everything had been great for the past 3-4 months maybe.  I had a few power outages months back and the parity had rebuilt successfully then.

I'm also running 5.0 b2. 

 

Yes, I understand it's a Beta.  I was having speed issued that turned out to be NOT related to 4.7 but never fell back as things seemed to be working well.

Ok so I just noticed something strange and I'm not sure if it's just the way unRAID behaves or not.

 

When I woke up this AM and found that the parity check had stopped, showing like 9000+ minutes until completion @ 145K per sec, I clicked STOP check and it stopped IMMEDIATELY.  It's showing:

 

 

(Last checked on Sun Mar 13 08:38:14 2011 CDT, finding 0 errors.) and is showing to the left "Parity is Valid".

 

Might it have actually completed successfully or does unRAID just show that it's ok when you stop it?!?

 

I assumed there was some type of failure from the syslog:

 

 

Mar 13 03:19:01 BIGHOSS kernel: BUG: unable to handle kernel NULL pointer dereference at 00000006

Mar 13 03:19:01 BIGHOSS kernel: IP: [] copy_data+0x22/0x142 [md_mod]

Mar 13 03:19:01 BIGHOSS kernel: *pdpt = 00000000375b5001 *pde = 0000000000000000

Mar 13 03:19:01 BIGHOSS kernel: Oops: 0000 [#1] SMP

Doing a search for the Kernal: Oops, it appears it might be a BUG that remained in b2.  I'll upgrade to a later beta and see if that fixes it.

 

 

You will get that Parity is Valid when you cancel. It may not really be valid.

 

Try changing to 4.7. I believe there was a fix for your issue in 4.7 and also in a later 5.0b release. You can also try the later 5.0b6a release if you really want but be warned the 5.0b6a has had a lot of changes and is a transitional release and only really recommended for test servers or servers where data loss is OK.

 

Peter

After reading the release notes I think I will fall back to 4.7 until a final release of 5 comes out.

 

The question of course is, can I fall back to 4.7 without losing data?

Yes, you can.

The format of the files that contain your configured users and passwords changed. If I remember right, you need to delete a couple of files from your config directory before booting 4.7, and then you have to recreate your users. The files to delete are passed, smbpasswd, and shadow. I'd suggest renaming them rather than deleting them.

The procedure seems to be:

 

1) Backup the flash drive to somewhere other than array

2) Rename the bzroot and bzimage folders in case you want to revert.

3) Copy the 4.7 version over the existing files structure

4) Remove the config/ password files

 

The concern I have is I see for all upgrade paths it says to have a WORKING parity drive.  I can't seem to get to that point currently.  Is this really a problem if I remove the parity drive from the array before I downgrade?

Copied everything off and fell back to 4.7.  Wow - is that interface UGLY! 

 

Parity checking now.  We'll see if that fixes the problem.

Partity check successful after falling back to 4.7.  It found 4 errors so I'm running it again to make sure they have been fixed.

 

Thanks for the input guys, this seems to have fixed the problem.

 

Mike