Guys,

 

I posted a few days back and have been slowly erradicating possible problems that are affecting my rig.

 

Following parity check everythign seems fine until media player try's to refresh its library, when the following error shows up continiously in the syslog:

warning: vs-5150: search_by_key: invalid format found in block 213581840. Fsck?

 

have attached the full syslog, but I have no idea whats going.  this has been ongoing for over 10 days now, have tested different memory sticks as was getting kernel panic, and this is the best result I've gotten so far, by grabbing the syslog before it dies.  Can someone please help, as I am a linux moron.  Unraid has been rock stable for 6 months and now since the move (new flash, a few dodgy seagate drives0 I am getting to the end of my tether as I can't figure out the problem. 

 

It feels like to my uninitiated brain that the error is filling up the RAM and causing the kernel panic, but I can't figure out why this is happening?  I can see the permission error but why is this happening?

 

see attached - Advice would be appreciated!

 

Paul

Your file system on disk1 ( /dev/md1 )  has some corruption.

 

Basically, you need to run a file system check to fix it.

 

Follow the directions given in the wiki here: http://lime-technology.com/wiki/index.php/Check_Disk_Filesystems

 

You will probably find the first file system check will recommend the fix-fixable option in a second pass.

 

Before you can un-mount the file-system, the disk must not be "busy" so if you have any extra add-on programs running (specifically cache_dirs) stop them first.

 

Joe L.

This syslog is relatively small, for one with errors, and does not include any panic'ing, so there should be no effect on your RAM usage.  If you have another syslog, either much larger and/or with evidence of a kernel panic, post it and we can take a look.

 

Other than the need for reiserfsck on Disk 1, as noted by Joe, your syslog looks fine, and your system looks good, quite fast.  It does indicate that there was a previous improper shutdown, perhaps because of a crash(?), and that there was some writing to Disk 1 at the time of crash or shutdown.  That may have been a cause of the file system corruption on Disk 1.  If the corruption has been there awhile, it is possible that it has been causing the kernel panics, but we would need to see it in the syslog to confirm that.

 

There are a couple of files mentioned, album art and a folder pic, that may have been corrupted.  Reiserfsck may or may not be able to recover them correctly, so test them after everything else is fixed.

Thx Joe/Rob,

 

I ran the file system check and it came back with - see attached.

 

Its asking to rebuild - based on the wiki it says I should be very careful when i do this. 

 

In regards to kernel panic, I've been gettign them regularly whenever media player is trying to build its library which is on disk 1.  When the kernel panic happens I don't kniow how to get the syslog out as the web gui becomes unresponsive.  also shutting down cleanly once the panic has occurred I haven't figured out.  I've been able to stop the kernel panic by stopping the library build - hopefully the file system check will fix this problem?

 

any advice on next steps.  Sorry to be such a pain!

 

PK

Thx Joe/Rob,

 

I ran the file system check and it came back with - see attached.

 

Its asking to rebuild - based on the wiki it says I should be very careful when i do this. 

 

In regards to kernel panic, I've been gettign them regularly whenever media player is trying to build its library which is on disk 1.  When the kernel panic happens I don't kniow how to get the syslog out as the web gui becomes unresponsive.  also shutting down cleanly once the panic has occurred I haven't figured out.  I've been able to stop the kernel panic by stopping the library build - hopefully the file system check will fix this problem?

 

any advice on next steps.  Sorry to be such a pain!

 

PK

Next step is to run with the --rebuild-tree option as suggested.

Since the file-system is still un-mounted, you need not do those steps again unless you re-mounted it.

 

Once you run "reiserfsck --rebuild-tree /dev/md1" , and it finishes, you can probably try the "--check"

reiserfsck /dev/md1 once more to see that it fixed it all.

 

Very likely fixing the file-system corruption will stop the kernel exceptions.

 

I know the warnings in the wiki look bad... but they are there to keep people from going too far without seeking advice...  some of the actions are very hard, if not impossible to backtrack on...

 

Joe L.

Joe,

 

you are a legend!

 

rebuilt the tree, re-ran the reiserchk and it found no further corruptions, restarted the array and no errors are forthcoming so far (fingers crossed0.  Will recheck parity tonight, and hopefully the gremlins have left the building.

 

thx again for the prompt response and wise counsel it makes the decision to use unraid such an easy one.

 

thx, PK