Hi,

 

I have spent much of the weekend installing unRAID for the first time.  The installation went smoothly and the initial parity check was performed without incident, taking about 8 hours to complete.  I was able to set up some shares and write some data to them - again, without incident.

 

I then decided to see what would happen by simulating a power failure (I simply and inelegantly turned off the PC at the power outlet).  After re-booting, the system then went into parity check mode.  It was running very slowly and producing a large number of errors on the parity disk - about 700 errors in 10 minutes.  The parity check was running at a speed of about 1,800 KB/sec and estimated to finish in 13,344 minutes, much slower than the initial parity check prior to the power "outage.". 

 

On the unRAID Main menu under Disk Status, the parity disk and disk 1 both have green lights.

 

I would very much appreciate some help!

 

I have attached 3 files:

 

- syslogshort.txt  (the original file exceeded the maximum size limit of 128 KB for this forum, I have deleted what appear to be largely pepetitive sections of it)

- smartsda.txt  (S.M.A.R.T. report for disk 1)

- smartsdb.txt  (S.M.A.R.T. report for parity disk)

 

My equipment:

 

Two new Western Digital 1.5 TB hard drives

New Gigabyte EP45T-UD3LR Motherboard

2 GB memory

450W power supply

 

 

It is just my personal preference, but I think it is better to keep everything in the same thread, with the same user name.  I already responded in this thread, and I would read that first.  The syslog here is based on the same system, but in this syslog, the kernel found and set up the flash drive later, so Disk 1 becomes sda and the Parity disk becomes sdb.  This syslog also reveals that there are a number of bad sectors ('media error', UNCorrectable) at the very beginning of the Parity disk, so I suspect that the timeouts in the previous syslog were at the same point, and the drive was just locating and analyzing them for the very first time, and took too long, timing out.  Analyzing bad sectors and dealing with exceptions takes a long time, and that explains the horrible performance you are seeing.

 

We need to see the SMART report for this drive, the parity drive, currently sdb.  Unfortunately, the 2 SMART reports that were attached were from the same drive, Disk 1.  Perhaps you repeated the same command, but did not change sda to sdb?

 

Disk 1 appears to have been fixed, no transactions to be replayed, and a clean Reiser file system.

 

I'm all for testing systems, but pulling power when the system is writing to a hard drive is NEVER advisable, can cause permanent damage to any hard drive, as I suspect it has to this one.  We recommend a UPS always, and pulling power from the UPS only.  Thankfully, a journaling file system like ReiserFS is very good at handling unplanned outages, but I would NEVER challenge it while it is known to be writing directly to the disk.

 

We need to see the SMART report for this drive, the parity drive, currently sdb.  Unfortunately, the 2 SMART reports that were attached were from the same drive, Disk 1.  Perhaps you repeated the same command, but did not change sda to sdb?

 

Rob,  sorry I posted two identical files.  This current post contains the correct SMART report for the parity drive.

 

Disk 1 appears to have been fixed, no transactions to be replayed, and a clean Reiser file system.

 

Yes, it appears to be performing OK.

 

I'm all for testing systems, but pulling power when the system is writing to a hard drive is NEVER advisable, can cause permanent damage to any hard drive, as I suspect it has to this one.  We recommend a UPS always, and pulling power from the UPS only.  Thankfully, a journaling file system like ReiserFS is very good at handling unplanned outages, but I would NEVER challenge it while it is known to be writing directly to the disk.

 

Actually, I pulled the power while the system was idle.

 

I know that it is not advisable to pull power while a disk write is in progress but I do note that over many years of experience with Windows machines, I have never managed to write off a hard disk.  Could it be that either 1.5TB drives are more susceptible to damage than, say, 300MB drives - or that unRAID is more sensitive to disk problems than the various forms of Windows?

 

Anyway, thanks kindly for looking into my problem here.

How did you figure the system was idle? Did you do a "sync" / "sync" command? Did you spin down the drives? If the answer is no to both of those, you have no way of knowing the system wasn't in the middle of flushing something to the drives.

Actually, I pulled the power while the system was idle.

 

OK, sorry, you did imply that earlier.  Because the damage seemed so severe, the easiest explanation for me was that power was lost during heavy writing to the drive.

 

I know that it is not advisable to pull power while a disk write is in progress but I do note that over many years of experience with Windows machines, I have never managed to write off a hard disk.  Could it be that either 1.5TB drives are more susceptible to damage than, say, 300MB drives - or that unRAID is more sensitive to disk problems than the various forms of Windows?

 

This drive was having issues (timeouts at the same very early point) even before you tried this experiment, so I would say the drive itself may be defective.  The SMART report is rather bad for a drive with only 75 Power_On_Hours.  It is showing a Reallocated_Sector_Ct of 129, and a Current_Pending_Sector count of 1136, quite high and should normally be zero, and an 'ATA error count' of 6444.  That also explains the quantity of bad sectors reported, and the very slow operation so far.  You probably are also seeing a high error count on the far right of this drive on the unRAID Web Management page.

 

These errors are coming from the drive itself, and being handled by the Linux kernel and drive modules at a very low level.  The unRAID modules do not see or know about these errors (as far as I know), only see the read errors returned to them, which is why it was still green.

 

My recommendation would be to unassign this drive and run the Preclear Disk script on this drive.  You want to be able to make a good decision as to whether to RMA the drive, or assume that it has passed its 'teething' problems.  Preclearing it should force the drive to either clear the Pending back to zero with a single increase of the remapped sectors but no further increase after that, or show you clearly that the drive is continuing to fail.

 

My recommendation would be to unassign this drive and run the Preclear Disk script on this drive. 

 

RobL, thanks for this advice.  I will implement the preclear routine and see how we go.

 

In the meantime I have purchased a 1.5TB Seagate SATA drive, installed it as the parity drive and completed the parity check.  No errors reported by unRAID.  The parity check went smoothly, taking about 8 hours.  Out of abundant caution I have run smartctl on this drive and the results are attached as smartsdc.txt.  I woul appreciate your view about this report.  I note that Raw_Read_Error_Rate is 21203.  Should I be alarmed?  Another disk (WD) that I have checked shows this parameter as 0.  Also, is Reallocated_Sector_Count = 29 acceptable for a new disk?

The drive looks pretty good, with only the Reallocated_Sector_Ct needing to be monitored for awhile.  Seagates are the only ones that report their soft read errors, as the Raw_Read_Error_Rate and Hardware_ECC_Recovered, roughly means N detected and N corrected.  All drives have soft read and seek errors, but in general only Seagate reports them, as very very large numbers, possibly encoded.  Yours is minuscule compared to what they will become later.

 

It is hard to compare SMART results of drives from different manufacturers, as they use different programmers and SMART policies.  You will see different attributes used, the same attributes used differently, scaled differently, encoded differently (eg. compare the temps), etc.  And even from the same manufacturer, you will see large differences between models, especially the new models, as SMART continues to evolve.

 

The Reallocated_Sector_Ct is the only one of note here, and of course, it IS a little disappointing to get a brand new drive that already has 29 bad sectors, but it is not at all unusual, especially within the first month.  The first month is the 'shakeout' month for drives, which is why we recommend running the Preclear Disk procedure on all new drives, to run it hard, to shake out any marginal sectors and problems, and try to make marginal drives fail now before they are full of valuable data.  Typically, drives either fail within the first month or run for years.

 

The only thing you need to do is monitor this drive for awhile, to determine if this 29 sectors was the result of the initial testing and use of the drive, weeding out the weak sectors, and therefore only the good and strong sectors are left, or is it perhaps the first evidence of issues and the Reallocated_Sector_Ct and/or Current_Pending_Sector will continue to increase.  It is the trend in these numbers that is important, not the actual current number.  Obtain SMART reports every month for awhile and you will know if you have a problem or not.