Just did some bulk copying before bed,

noticed that the Parity drive (/dev/sdb, ata-ST31500341AS_9VS0QPN0) had been taken off-line this morning

 

syslog indicates some ATA command failures, after which the drive was disabled

(I shutdown, re-seated the drive and brought the system back up and it is currently rebuilding parity)

 

just installed c++ libs so I can use smartctl

this seems to show a very high Reallocated_Sector_Ct value (1275 ??!!)

 

Is this a drive that I should get replaced right away???

(the SMART stats show it's only got a lifetime use of some 93 hours so far...!)

Any ideas on what failed to make it go offline?

 

Cheers,

m

 

(syslog from failure and SMART stats attached)

Just did some bulk copying before bed,

noticed that the Parity drive (/dev/sdb, ata-ST31500341AS_9VS0QPN0) had been taken off-line this morning

 

syslog indicates some ATA command failures, after which the drive was disabled

(I shutdown, re-seated the drive and brought the system back up and it is currently rebuilding parity)

 

just installed c++ libs so I can use smartctl

this seems to show a very high Reallocated_Sector_Ct value (1275 ??!!)

 

Is this a drive that I should get replaced right away???

(the SMART stats show it's only got a lifetime use of some 93 hours so far...!)

Any ideas on what failed to make it go offline?

 

Cheers,

m

 

(syslog from failure and SMART stats attached)

 

1275 reallocated sectors is a large number.  Not sure if you have a prior report.  If, by chance, your drive has had 1275 reallocated sectors from the very beginning, and that value has held steady, it would not be a large concern.  But I have never seen so many bad sectors hold steady. (Recently reports here have shown that drives with even just 1 bad sector seem to rapidly degrade into thousands and need to be replaced).  My guess is that number is going to get larger and larger as the disk unravels and becomes useless.

 

The errors in the syslog are likely due to the errors that the drive is reporting.  Sometimes (usually even) these errors are the result of a cabling issue.  It is certainly possible that you have a cabling issue + a failing drive, but it is more likely that you have one or the other.  Since we think that the drive is failing, I would focus on that.  If it is a cabling problem also, replacing the drive will mean unplugging and repluggin whiich might fix a cabling problem if one exists.

 

I would immediately shudown and disconnect / remove that drive from the array.  Upon rebooting, the array should come up in "simulated" mode.  It will appear that the removed drive is still in place like always, when in fact it is being simulated behind the scenes.  Note that in this mode your array is unprotected.  You should quickly get a new drive (or maybe you have a spare) and be able to rebuild onto the replacement drive (post back if you can't find instructions how to do this).  I'd hold on to the bad one until the rebuild is complete and parity protection re-established, but then RMA it.

thanks bjp999

 

I wish I had the original stats too - these are the things I will learn by experience to keep track of in future :-)

 

I bought these HDDs with an small-surcharge instant-replacement guarantee (unusual for me, but since these are the 1.5TB Seagate's I've heard had all those teething troubles when they first came out, I thought this would be the time to pay that little bit extra) - so I think what I'll do is get down to the store today and just swap it out with a new one, citing the 1275 reallocated sectors (the store will take care of the RMA for me!). FYI, none of these drives fall under the category of Seagate's "problem" range as far as serial numbers and firmware goes.

 

For the record, the 3 other same-model 1.5TB drives I have installed in the array ALL have a Reallocated_Sector_Ct value of 0.

 

I also notice that some audible vibration has stopped since I reseated the drive. Perhaps there was a connection (drive-seating) issue in the mix.

When I install the new drive, I will have a good poke around at the cabling inside the tower and just double-check things. Again FYI, this is a Lime-Tech MD-1510/LI unit with the Icy-Dock cages.

 

Thanks again for the advice,

m

Before you return the drive, make sure that the array comes up in simulated mode and that the data on the simulated disk looks good.

 

The way it simulates it is the way it will be reconstructed.

 

If anything looks worrisome on the simulated disk, having the real physical disk might be worthwhile.

 

Not sure if the store would agree to let you take leave a credit card imprint for the new drive, and keep the old one for a couple days, before returning the old one.  That might give you an extra measure of assurance in case there are any problems in the rebuild process.

 

(I'm a bit anal about these things.  I always like there to be a plan B in case something goes wrong.)

Don't think I made it clear - the drived that failed was the Parity Drive

 

so I don't think there'll be any benefit in keeping the data that's on it - or is there?

 

m

Don't think I made it clear - the drived that failed was the Parity Drive

 

so I don't think there'll be any benefit in keeping the data that's on it - or is there?

 

If fully intact, that parity drive would help you to recover if a drive failed during the parity rebuild onto the new parity drive.  But since it is giving problems, I think the value of keeping it is pretty low.

 

Just wanted to follow up and say I got the instant product replacement no probs on a new 1.5TB HDD (same Seagate ST31500341AS as the rest)

 

Brought the system up and rebuilt parity no probs.

I made sure I have SMART data for all drives now! This new drive also has 0 Reallocated_Sector_Ct like the rest, so I'll be keeping my eye on these things over time.

 

Also not heard the vibrations yet that I was hearing before, so I'm tending to think there was some kind of seating issue on the original setup (possibly on top of any physical media issues with the HDD itself).

 

Thanks again for the help and advice.

 

m

 

ps - to satisfy my curiosity on your last point, how would you use the old parity drive if another drive failed during a new parity-drive rebuild?

Presumably you'd have to shut down the system, put the OLD parity drive back in place and swap out the newly-failed data drive - how do you tell the system to accept the old parity drive "as is" and continue to rebuild the new data drive?

Glad to hear your up and running again.  If you haven't already, run a parity check (after the parity build) to make sure that all is well.  Many users oimit this step and a few later find out (when they have a problem) that parity didn't build right.

 

There is a command "mdcmd set invalidslot n" that will let you tell unRAID which drive is invalid on a "new" array.  Read about it here.

 

If you were to put your old parity disk in the parirty slots, all but one of the original data disks in the data slots, and one replacement disk in another data slot, you could rebuild the replacement disk using that command.

OK, running Parity Check now...

 

the front page (main.htm) of my tower already said that parity was valid and that it was last checked last night,

but presumably it always says this imm. after a rebuild??

 

thanks for the tip on the "mdcmd set invalidslot n" command - I will have to (try to) remember that if and when the need arises (assuming I'm not in a blind panic at that point!)

OK, running Parity Check now...

 

the front page (main.htm) of my tower already said that parity was valid and that it was last checked last night,

but presumably it always says this imm. after a rebuild??

 

This iis very misleading.  There is a difference between "building parity" and "checking parity", but unRAID indicates a successful check immediately after a build.

 

A few motherboards are not compatible and they will build but the check will always produce a bunch of parity errors.  Over time several of them have developed bad drives and recovery is not possible.  If only they had done a parity check AFTER the parity build they would have known. 

 

thanks for the tip on the "mdcmd set invalidslot n" command - I will have to (try to) remember that if and when the need arises (assuming I'm not in a blind panic at that point!)

 

Lots of use of this on the forums.  If you search for "invalidslot" you should find lots of examples.