I'm hoping someone in the community can help with this.  I can't get multiple 1TB+ drives to work in my well established unRAID server and it is driving me crazy.

 

I have  2 year old unRAID server now which was running v4.3.3 without any issues when I began the upgrade.  It is now upgraded to 4.4.

 

This machine has been flawless since it was built.  However, when I went to update to large capacity drives this week I cannot get a successful rebuild on the data drives.

 

System began with 3 drives:  A 400GB parity drive and (2) 300GB data drives (Disk1 and Disk2) running unRAID 4.3.3 flawlessly.

 

I first upgraded the Parity drive to a 1.0TB Western Digital BLACK drive.  No issues.  Then installed a hitachi 1TB drive for a data drive.  I get multiple errors during parity rebuild and subsequent parity checks.

 

I assumed bad drive, right?  So I reset the array by using the restore command back to my original configuraiton and rebuilt the parity drive from my original data drive.

 

Next, I installed a 1.5TB Seagate drive (wtih firmware update) as my parity drive.  Again, no issues.  Parity check after building the parity drive verifies it is OK.

 

Then I use a second 1.5TB seagate drive to replace Data2.  It appears to rebuild correctly, but has multiple 200+ errors during an immediate parity check!

 

I then restored AGAIN to my original config and rebuilt partiy and performed parity check to assure everything was back in place.  All OK with original drives. 

 

Installed updated BIOS to my motherboard (system config below) and then performed upgrade to unraid to v4.4.  REPLACED ALL SATA CABLES with new ones.

 

Did the entire process again with the (2) 1.5 TB drives and I have the exact same result (errors on parity check of rebuilt data drive).

 

Can anyone help understand why unRAID seems to fail when installing a second >1TB drive into the system??

 

Here are my hardware specifications:

 

ASUS P5LD2-VM R2.0 Motherboard

Cooler Master Centurion 5 Tower with 380 Watt Cooler Master Power Supply

Intel Pentium D 820 Dual Core 2.8GHz, 800MHz FSB

1GB Dual Channel Corsair XMS2 PC5400 DDR2 675 SDRAM

Kingston Data Traveller 2GB USB Flash

ICY Dock 5 in 3 SATA III Bay (Fits 5 SATA III Drives in 3 Full Height Bays)

Seagate Barracuda 400GB 16MB 7200 RPM SATA/300 HDD (OLD Parity) 

Maxtor 300GB 16MB 7200 RPM SATA/150 OLD Drive 1

Maxtor 300GB 16MB 7200 RPM SATA/150 OLD Drive 2

 

Have TRIED:

Western Digital Black 1TB Parity

Hitachi Desktar 72k1000 1TB Data 2

 

Seagate Baracuda 1.5TB Parity

Seagate Baracuda 1.5TB Data 2

 

Please help!

Did you try running the preclear script on these new drives to make sure they are error free?

 

It takes an hour per 100gigs to run, so it will run for awhile on the new 1.5Tb drives.

Did you try running the preclear script on these new drives to make sure they are error free?

 

It takes an hour per 100gigs to run, so it will run for awhile on the new 1.5Tb drives.

 

Where is this magical 'preclear' script?

http://lime-technology.com/forum/index.php?topic=2817.0

Please help!

You have already done many of the things to eliminate items normally suspected first...   Now you need to look at what is common.

 

The extra drive may be placing demands on the power supply that let marginal memory issues surface.  I know it is a name-brand power supply, but it still might be a suspect.  But first,

is it configured correctly.

 

With the additional drive installed, run a memory test.   If your memory needs specific timing, or voltage, make sure the MB Bios is set accordingly.  It might work with only one drive drawing power, but be out of tolerance with the additional drive connected.

 

If you have two memory strips, swap them in their slots.  Might be timing related.

 

Post a "syslog"  You basically said "my car makes a funny noise when I put in an extra passenger" but did not give us the "recording" of the noise.  The syslog might give clues to what is happening when the errors occur.  (You will need to run another parity check, and include the log at least to where the errors occur)

 

Post a smartctl report from each of the drives.  It is possible they are reallocating sectors, and you don't know if they are the underlying cause.

 

It could be the MB itself,  there have been some boards that just do not work well when a lot of activity occurs on the PCI bus....   Does it have options for CPU voltage? is it set correctly?   You mentioned the "case" the MB is in, but not the Motherboard model itself.   Did I miss that somewhere?  When you mounted the MB, did you put in all the mounting screws? (Sometimes, the metal case is used as part of the ground return on the MB for some circuits. )  

 

The preclear_disk.sh script is here: http://lime-technology.com/forum/index.php?topic=2817.0

You would use it before you assign any new drive to your array.    You will want to make sure you have a working "smartctl" program first for it to show you before/after test results.

 

(On 4.4 unraid,  the "smartctl" program needs an additional library installed to function.  It is described in that preclear_disk thread)

 

Joe L.

Thanks for the prompt replies from everyone.  I will post a syslog when I get back to the array later this morning.  I have also run 2 of the drives through their native drive inspection programs without incident (note that I have used 4 different drives in this scenario - all are new and from different vendors - not very likely that thye are bad).

 

I will also run memcheck before I post the log file.  I'd be surprised if this were the issue, but perhaps the larger addressing space is pushing the memory into areas that were not previously being accessed with the smaller drives?

 

Can anyone provide a brief reason for the the purpose of the preclear script when you are installing unpartitioned new drives?

The motherboard is an ASUS P5LD2-VM R2.0

 

Can anyone provide a brief reason for the the purpose of the preclear script when you are installing unpartitioned new drives?

 

When adding a disk drive to an unRAID array, it is first completely cleared. This clearing step can take many hours for large drive. During the "clearing" step, the unRAID array data is not available on the LAN as the array is stopped. This clearing step can be skipped if a drive has been specially "pre-cleared".  In addition, if you simply assign it to the array you will not know of any early indications of disk failure, making removal more difficult, as a full parity re-calc will likely be needed.  the only way to know if a brand new disk is working well is to run it through a burn-in cycle.

 

The preclear_disk.sh utility is also used to burn-in a disk. If the disk can go through a full pre-read/zero/post-read cycle without errors, it is less likely to fail shortly after being assigned as part of the unRAID array. You may request this script to perform multiple read/write/read cycles of the entire disk. As many as 20 cycles may be requested at a time. (For a 1.5TB drive, 20 cycles would probably take close to 2 weeks. )

 

The intention of this script is to allow the SMART firmware on modern disks to identify and re-allocate any marginal sectors before the disk is used in the unRAID array. Any sector marked as needing re-allocation during the "pre-read" phase will be re-allocated by the SMART firmware on the disk during the subsequent "clearing" phase when zeros are written to the entire disk.

 

See here for a bit more detail: http://lime-technology.com/wiki/index.php?title=UnRAID_Add_Ons#Preclear_Disk

 

Basically, a 1.5TB drive could take your unRAID array off-line for 6 hours or more if you let unRAID clear it before it adds it to the array.  Instead, it will only be off-line for a few minutes if it is pre-cleared.  If your family comes to rely on the server for movies and music, they will want you to minimize down-time as you upgrade it.

 

Joe L.

Thanks for the detail, Joe.  I really appreciate you taking the time to look at this for me.

 

I put the unRAID server back on the bench (again, everything has been working fine with the old data drives and new 1.5TB parity drive). 

 

Installed a 4th drive (the 1.5TB drive) to the power supply and loaded memcheck.  It has been running for over an hour without incident, so as suspected, the memory is solid and everything appears operational even under the additional load of a 4th drive (and CDROM that isn't normally there).  This rules out any obscure issues with RAM or Power Supply.  I wonder if I am overheating the CPU/NB or SB on the motherboard during the long drive build and subsequent parity check.  I may do the next rebuild on my bench with the case open.

 

I put my unRAID USB into my other PC expecting a syslog to already be present, but this must be something I have to invoke.  I will search around the forum and try to find out how to do that.  When I get a chance, I will attempt once again to replace the data drive and force the errors to appear while logging to a syslog file.

 

I also plan on looking at my BIOS settings for the ASUS hard drive controller - perhaps it is set to the wrong mode which could cause some issues.

OK - Here are the results of my latest trials...

 

I proceeded to rebuild a drive again so that I could capture the syslog file before powering down.

 

This time, I decided to rebuild DRIVE 1 instead of DRIVE 2 and to use the WD Black as the data drive for the reubild since it was successfully rebuilt and parity checked as the parity drive once before.  This allowed me to use a different port on my motherboard for the rebuild and also a different slot in my ICYDOCK modular drive system.

 

Everything rebuilt perfectly and a subsequent parity check now shows no errors and I have 2 (>1TB drives) operational which I have not been able to do before now.

 

I have moved the drive back to the original problematic port and reassigned the drive to that spot so unRAID knows which physical drive is which again.

 

Ran partiy check and immediately had errors, so the problem is related to the physical port on the motherboard.  When restoring the smaller drive to that port, there are no issues at all - only a large drive on physical SATA port #2 creates the problem. 

 

I will attach a syslog in a moment to show what errors occured.

 

 

Attached is the syslog.  I just returned the drives to their original ports and everything is passing parity check again without incident.  Basically, Sata port #2 is happy with the 300GB drive but none of the 1TB and larger drives.  The problem follows the physical port, but the port is obviously working fine on a smaller drive.

 

Thanks in advance for any expert opionons regarding the errors contained within the ATTACHED log from the partiy check.

 

Gary

Your syslog confirms what you have said about that port.  You are getting exception Emask errors (host bus error, ICRC), immediately on first access through the port, and continuously thereafter.  I'm not an expert here, but it's my opinion this is faulty hardware, and even if you found a 'fix', or configuration switch that appeared to fix it, I would not trust this port.  I would like to see a syslog with the small drive attached to this port, and covering a period of hard traffic through it, like a parity check, before I would recommend even a smaller drive connected to it.  It might appear to be working correctly, with no errors reported, but if the exception handler is working, and dealing with each error internally, and successfully, then you may be able to run, but with very poor performance.

 

As it is, the exception handler quickly slows down the mode all the way to UDMA/33, but that does not help.  I would have liked to see it disable DMA, and try a PIO mode, but it did not.  And would you have wanted a drive that ran successfully in a very slow PIO mode?  Probably not.

 

I can't think of any reason why the size of the drive should matter, so it seems more likely that it is something about the more modern drives that is not compatible.  It's possible that there is a signal line being used differently, or a signal speed issue, but I don't know.

The smaller drive has been on that port for 2 years without ever seeing any problem or parity check issue.  I just completed upgrading the entire server (avoiding this particular port) and the big drives work flawlessly on all of the other ones.  So I've come to the conclusion that there is a hardware problem on that port (mechanical or something in the chipset) that doesn't work with the more modern drives - but they all work perfectly on the other ports.  I only use 3 drives in this server, so it isn't an issue - just bothers me a little that I don't know what is wrong with the port... makes one lack the desired level of confidence in the other ones working properly going forward, but I now have (2) 1.5TB drives and (1) 1.0TB drive up and running on the server as intended.

 

For now, I'll consider this issue closed.  Thanks for everyone who helped look at the issue.

 

Gary