Again, my biggest concern at this point is the mention of crash/es/ing as - presumably - captured by my syslog.

 

As previously mentioned by "dgaschk" and as far as I know by looking at few other X8SIL-F owner syslogs the "crash" observed is "harmless" (at least there are no other reported negative consequences) and exist in any Unraid system based on X8SIL-F and two of the Supermicro controllers.

 

If you want to put your mind on peace do a search for X8SIL-F, check out any post with syslog attached, download it and search for a text string "X8SIL" inside - this one will immediately precedes a "crash" like yours. Or you can send a support question to Supermicro - after that you are using SM motherboard and two SM controllers.

Personally,  I would run another parity check and then look at the smart reports again and see if any of the reallocated sector counts increase.

 

If they increase... then in my opinion the drive can't be trusted.

 

I already did a follow-up extended smartctl on SDQ after it was suggested, didn't seem like the reallocated counts or spin-up attempts have increased.

 

I assume the interpretation is that if there isn't an increase, then it's simply reporting the "status quo?" Would it ever report a decrease?

 

I'm probably going to swap it out once some 2TB drive hits a nice price-point again  

 

Thanks!

Again, my biggest concern at this point is the mention of crash/es/ing as - presumably - captured by my syslog.

 

As previously mentioned by "dgaschk" and as far as I know by looking at few other X8SIL-F owner syslogs the "crash" observed is "harmless" (at least there are no other reported negative consequences) and exist in any Unraid system based on X8SIL-F and two of the Supermicro controllers.

 

If you want to put your mind on peace do a search for X8SIL-F, check out any post with syslog attached, download it and search for a text string "X8SIL" inside - this one will immediately precedes a "crash" like yours. Or you can send a support question to Supermicro - after that you are using SM motherboard and two SM controllers.

 

Cool, thanks for the lead!

Did anyone go back and look at the first syslog he posted?  It looked a mess.

 

I agree that 3 parity errors is not a huge deal.  But the fact that he got parity errors on an array that had no hard shutdowns is indicative of a problem IMO.  I have never had an unexplained parity sync error in over 3 years of unRAID use.  If I got 3 all of a sudden that I could not explain, I would not be happy with an "its only 3" song and dance.

 

I do think that it would now be appropriate to start running parity checks.  As I said, if you can run three in a row with no sync errors it would add confidence that this was some kind of fluke.  But I'd still like some people to look at your earlier syslog and give their opinions based on that.

 

If I remember right, the parity errors were in the "housekeeping" area (very early) on the disk.  That is not where data content is kept.  This is the type of parity sync error you'd see after a hard shutdown.

Run a couple of parity checks and monitor the pending and reallocated sector counts in the SMART reports.

 

I should revise my comment on where the errors probably lay. In theory, they could be on any disk. In practice, Limetech made the default behavior of a parity check to update parity to reflect what's on the disks. Limetech may know something that we don't.

 

Definitely get Joe L.s input on your syslog. It may look odd to me because of the hardware configuration.

 

UnRAID is a great product that provides high reliability and uptime. But if you have irreplaceable data, it should be stored in a backup distinct from this server, preferably offsite.

 

A less reliable technique is to store important data on 2 distinct drives within the same unRAID server. Then the data is lost only if both of these disks fail concurrently.

Again, my biggest concern at this point is the mention of crash/es/ing as - presumably - captured by my syslog.

 

As previously mentioned by "dgaschk" and as far as I know by looking at few other X8SIL-F owner syslogs the "crash" observed is "harmless" (at least there are no other reported negative consequences) and exist in any Unraid system based on X8SIL-F and two of the Supermicro controllers.

 

Correct

http://lime-technology.com/forum/index.php?topic=9790.msg93889#msg93889

 

Lets stop calling them "crashes". They are normal log entries. Crashes make no log entry...

Did anyone go back and look at the first syslog he posted?  It looked a mess.

 

I agree that 3 parity errors is not a huge deal.  But the fact that he got parity errors on an array that had no hard shutdowns is indicative of a problem IMO.  I have never had an unexplained parity sync error in over 3 years of unRAID use.  If I got 3 all of a sudden that I could not explain, I would not be happy with an "its only 3" song and dance.

 

I do think that it would now be appropriate to start running parity checks.  As I said, if you can run three in a row with no sync errors it would add confidence that this was some kind of fluke.  But I'd still like some people to look at your earlier syslog and give their opinions based on that.

 

If I remember right, the parity errors were in the "housekeeping" area (very early) on the disk.  That is not where data content is kept.  This is the type of parity sync error you'd see after a hard shutdown.

 

Run a couple of parity checks and monitor the pending and reallocated sector counts in the SMART reports.

 

I should revise my comment on where the errors probably lay. In theory, they could be on any disk. In practice, Limetech made the default behavior of a parity check to update parity to reflect what's on the disks. Limetech may know something that we don't.

 

Definitely get Joe L.s input on your syslog. It may look odd to me because of the hardware configuration.

 

UnRAID is a great product that provides high reliability and uptime. But if you have irreplaceable data, it should be stored in a backup distinct from this server, preferably offsite.

 

A less reliable technique is to store important data on 2 distinct drives within the same unRAID server. Then the data is lost only if both of these disks fail concurrently.

 

Took a while, but after running 3 Parity Checks in a row, all 3 completed successfully without any errors. 

 

At this point, I'll put replacement of SDQ as an action item and put this thread to rest. Would have been nice to figure out what caused the errors to begin with, but I'm leaving well enough alone at this point 

 

Thanks for everyone's generous help and input!

Did anyone go back and look at the first syslog he posted?  It looked a mess.

 

I agree that 3 parity errors is not a huge deal.  But the fact that he got parity errors on an array that had no hard shutdowns is indicative of a problem IMO.  I have never had an unexplained parity sync error in over 3 years of unRAID use.  If I got 3 all of a sudden that I could not explain, I would not be happy with an "its only 3" song and dance.

 

I do think that it would now be appropriate to start running parity checks.  As I said, if you can run three in a row with no sync errors it would add confidence that this was some kind of fluke.  But I'd still like some people to look at your earlier syslog and give their opinions based on that.

 

If I remember right, the parity errors were in the "housekeeping" area (very early) on the disk.  That is not where data content is kept.  This is the type of parity sync error you'd see after a hard shutdown.

 

Run a couple of parity checks and monitor the pending and reallocated sector counts in the SMART reports.

 

I should revise my comment on where the errors probably lay. In theory, they could be on any disk. In practice, Limetech made the default behavior of a parity check to update parity to reflect what's on the disks. Limetech may know something that we don't.

 

Definitely get Joe L.s input on your syslog. It may look odd to me because of the hardware configuration.

 

UnRAID is a great product that provides high reliability and uptime. But if you have irreplaceable data, it should be stored in a backup distinct from this server, preferably offsite.

 

A less reliable technique is to store important data on 2 distinct drives within the same unRAID server. Then the data is lost only if both of these disks fail concurrently.

 

Took a while, but after running 3 Parity Checks in a row, all 3 completed successfully without any errors. 

 

At this point, I'll put replacement of SDQ as an action item and put this thread to rest. Would have been nice to figure out what caused the errors to begin with, but I'm leaving well enough alone at this point 

 

Thanks for everyone's generous help and input!

 

You're welcome.  Glad, whatever happened, it is not recurring.

 

The fact that your parity errors were in the early part of the disk (housekeeping area) means it is very likely there was not data corruption.

 

If it were me, I would run weekly parity checks for a month or so.  If your parity errors do not recur, I think I'd feel pretty good that, whatever it was, was a fluke.

 

You're welcome.  Glad, whatever happened, it is not recurring.

 

The fact that your parity errors were in the early part of the disk (housekeeping area) means it is very likely there was not data corruption.

 

If it were me, I would run weekly parity checks for a month or so.  If your parity errors do not recur, I think I'd feel pretty good that, whatever it was, was a fluke.

 

Sounds good and will do, thanks again!