Jump to content
We're Hiring! Full Stack Developer ×

Troublesome syslog errors


Rajahal

Recommended Posts

I'm still having some issues with the client build that I described here.  I've now swapped out the motherboard for a C2SEE, the CPU is a Celeron 430, and I've got 2 GBs of DDR3 1066 RAM in there.  Everything else is the same as is described in that post.  The server is currently running unRAID 5.3 beta.

 

While running the newest version of preclear (1.6), I still see the errors I described here.  I haven't yet taken Joe's advice of zeroing the MBR on the two EARS drives, I'll do that soon.  Even though those errors do appear, the drives are surviving preclear passes, so that's at least a good sign.

 

Take a look at the attached syslog.  It is filled with errors that I've never seen before.  Are they attributable to the potentially bad EARS drives?  If so that would be a relief, as I can replace bad drives easily.  I'm just praying that the server hardware is actually fine, and that it is just the drives that are bad.

troublesome.zip

Link to comment

While there may be a problem with this drive, it is hard to say from that syslog piece, due to the very bad error handling.    It looks like a rather immature driver/module, poorly debugged.  Why not try v5.0-beta4, with hopefully a more recent SAS module with better error handling.  If that still does not help, you may have to wait for a future kernel.

 

Another option for testing that drive is reconnect it to an onboard port, one known to work well.

Link to comment

Thanks.  I just downgraded to unRAID 4.7 and it seems to have solved the issue.  So I guess you are right that there was some driver issue with 5.3 beta.  I'll check 5.4 beta at a later date, but right now I didn't have time to wait for the download.

 

I guess I don't need to zero the mbr as long as they are working, right?

 

New syslog attached.  Looks much better.

muchbetter.txt

Link to comment

Thanks, I'll try both of those things.

 

Can someone tell me the syntax to manually zero the mbr on the drives?  Also, isn't that what step 1 of preclear's clearing phase does?

 

Step 1 of 10 - Copying zeros to first 2048k bytes DONE

Actually, no.  I don't tell the whole story in that one status line.  The first 2048k are cleared after skipping past the part of the MBR that defines the partitions. I found when developing the script that linux would somtimes discover the change in partitioning and it would make it more difficult to perform the subsequent steps. 

 

I end up writing the MBR in a much later step, after the zeroing of the remainder of the entire drive.  I did it that way so if the MBR was marked as pre-cleared I'd be reasonably certain the balance of the disk had been zeroed.

 

Joe L.

Link to comment

Understood, thanks.  As I now understand it a successful pass of preclear should always zero (and later rewrite) the MBR.

 

I continue to have no problems with these drives or preclear since downgrading to unRAID 4.7, so I guess the issue was specific to 5.3beta.  Good to know I can put it to rest.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...