I don't have any logs since I'm at work right now, but I'm mainly looking for insight from the experts here.  Here's the story:

 

Last week I received one of the TAMSolutions 24 bay Supermicro Xeon servers.

 

Motherboard: X7DBE-X

Procs: Intel 5130 Dual Core 2.0GHz

Ram: 8GB 4x 2GB, 12 empty slots

Qty 3 SAT2-MV8 Raid cards

 

I upgraded from rc8a to rc11 (and Simple Features 1.0.11) on the old server and then eagerly moved all of my drives over, ran a parity check and all was good.  My next scheduled weekly parity check showed 60 errors, and disk4 had some errors.    This wasn't very surprising because I knew Disk 4 was iffy...  It has been slowly accumulating Pending and Reallocated sectors in ones and twos for a couple of months, but I've been procrastinating on doing anything about it (drive failures have always been drama-free in the years I've been using UnRAID, so I wasn't worried).

 

I ordered a new drive and replaced disk4, rebuilt and all seemed to be well.  The new disk4 is a 3TB, replacing a 2TB, so all of the data I've been moving to the array has been going to the new disk4.

 

The issue started yesterday.  I started getting "disk full" errors with Windoze file explorer, and noticed the mover wasn't moving stuff off of the cache disk.  The syslog was full of "disk 4 is read only" errors.

 

I did some searching here and ran reiserfsck.  It told me I needed to use the --rebuild-tree option.    I have not done that yet, I'm preclearing a drive that I intend to add to the array and plan to attempt to copy my data off of disk 4 onto the new drive, then I'll proceed with --rebuild-tree.

 

So, the insight and advice I'm looking for is:

 

1) I've never had this happen before in 4-5 years of using Unraid and a few HDD failures.  Is it likely just coincidence that it happened right after moving to new hardware, or are there tests that I should run to diagnose the new hw? 

 

2) Is rc11 suspect?  Should I roll back to rc8a?  Should I reduce my RAM to 4 GB?

 

3) Is it a sound plan to move my data off of the corrupt disk first and then do reiserfsck --rebuild-tree

 

Thanks for any insight you can offer, I know it's kinda vague without logs.

The issues you are experiencing have not been mentioned with respect to the 4gb issue. Syslogs needs to be seen to see if anything is going on. Also a smart report on the failing drive will be helpfull.

 

Moving data off the failing drive is allways a good idea, that way data loss is less likely (should a double failure occur).

I am curious what the outcome of this was?

 

I am looking at importing one of the Supermicro systems, so I am going through related threads.

And I am curious what size disk you have for parity?

 

Sent from my SGH-T889 using Tapatalk 4 Beta

 

 

I dropped my RAM back to 4GB and ditched Simple Features, which was causing the UI to go out to lunch which meant graceful shutdowns couldn't be done.

 

I did lose some data because of the default "correcting" parity check which just incorporates the corruption into the parity drive.

 

After I salvaged most of the data, I replaced the bad drive and have not had problems since.

 

I have a 3TB parity disk.