Advanced Format Drives - WD10EARS WD15EARS WD20EARS

[smeehrrr]

And the performance gap is due to a software deficiency in Slackware?

[Rajahal]

If your only issue is a decrease in performance, consider yourself lucky.  A few people on these forums have reported more serious problems (data corruption, if memory serves) after using unjumpered EARS drives for a while.

 

There's really no reason to think about it, since unRAID can recover from one lost drive.  Just shut down, install the jumper, boot up, and let unRAID restore the drive's contents.

 

Make sure to do a parity check first, since you will want to make sure your parity data is readable.

[smeehrrr]

My parity drive is, unfortunately, also a WD20EARS.

 

Looks like I need to find some jumpers and get to work.

[BRiT]

And the performance gap is due to a software deficiency in Slackware?

 

I don't have the time to find and repost the series of articles and links right now, but if you perform a search on these forums, you will find several earlier posts related to the drives and the cause of the issues.

[smeehrrr]

Found some jumpers and gave it a try.  I have two WD20EARS in the server.  Both of them apparently worked without the jumpers.  With the jumpers, one of them works and the other one goes into the same error loop that captain_video saw above.  Took the jumper off that one and it works again.  Just weird.

[WeeboTech]

And the performance gap is due to a software deficiency in Slackware?

 

It's a partition alignment issue. similar to the issues that SSD's have after a significant number of writes.

If the partition is not aligned on a properly divisible boundary, multiple sector reads & writes occur to update a sector.

[smeehrrr]

Looks like my best bet is to RMA the drive that doesn't work with the jumper attached and make sure everything is jumpered in the future.

 

Here's a question that I haven't been able to figure out from the various threads on this subject:  Assuming that Unraid eventually supports these drives natively (sans jumper), will there be any performance penalty for having the jumper on there?  Web sources suggest all that it's doing is adding one to the sector offsets, so wouldn't think so, but maybe someone has a definitive answer.

[Joe L.]

Looks like my best bet is to RMA the drive that doesn't work with the jumper attached and make sure everything is jumpered in the future.

 

Here's a question that I haven't been able to figure out from the various threads on this subject:  Assuming that Unraid eventually supports these drives natively (sans jumper), will there be any performance penalty for having the jumper on there?  Web sources suggest all that it's doing is adding one to the sector offsets, so wouldn't think so, but maybe someone has a definitive answer.

For unRAID to "support" those drives it would have to start the partition on sector 64 instead of 63.

 

Don't expect a "magic" cure when that happens...  You would need to re-format the drive and re-load it.

 

Just add the jumper and be happy the manufacturer recognized the need.

[WeeboTech]

Here's a question that I haven't been able to figure out from the various threads on this subject:  Assuming that Unraid eventually supports these drives natively (sans jumper), will there be any performance penalty for having the jumper on there?  Web sources suggest all that it's doing is adding one to the sector offsets, so wouldn't think so, but maybe someone has a definitive answer.

 

It should only be an issue on new drives without a partition table.

Once the partition table is aligned correctly, either through the use of jumper or directly starting the partition at 64, the drive should perform correctly.

 

If the jumper were present and unRAID or fdisk were to set the partition start value at 64, it might not be aligned correctly and a performance penalty could result.

[NAS]

I created a placeholder on the wiki for this issue.

 

http://lime-technology.com/wiki/index.php?title=FAQ#What_is_an_Advanced_Format_Disk_or_4K_HDD.3F

 

Would anyone who really understands this be prepared to spend 5 minutes populating it with facts?

[Msan]

I created a placeholder on the wiki for this issue.

 

http://lime-technology.com/wiki/index.php?title=FAQ#What_is_an_Advanced_Format_Disk_or_4K_HDD.3F

 

Would anyone who really understands this be prepared to spend 5 minutes populating it with facts?

 

I've updated it a bit.. not much, but a start..

[NAS]

I have taken alot of the words from this thread and roughly added them to the wiki entry.

 

Could someone please proof it as this is a potential data loss problem and it needs to be correct.

 

ta

[Rajahal]

Well, it is definitely thorough.  However, I would take a different approach.  First of all, tell people what they need to know and how it will affect them - basically, tell them what to do.  Then fill in the rest with the whole technical side of things.  If the person cares to keep on reading, they can, otherwise, they can stop.  As it is currently, it is a confusing read and the really crucial information about the WD EARS is somewhat buried in the middle.

 

I'll reorganize it as I see fit, then let you guys evaluate my changes.

 

Edit: OK, well, my reorganization turned into a major overhaul.  Your thoughts, please:

 

http://lime-technology.com/wiki/index.php?title=FAQ#What_is_an_Advanced_Format_Disk_or_4K_HDD.3F

 

[NAS]

Looks good to me. A few tweaks would make it flow better but its a significant improvement.

 

Id suggest we start creating dedicated pages for topics of this length and link them back to a simple FAQ one liner. The FAQ is daunting to say the least. After a certain critical mass is achieved (which i think we hit a while back) people wont actually read the faq i.e. sit down and read it rather than referring to it like a manual.

[Msan]

Looks good to me as well..

[TyantA]

After a fair amount of reading the one thing I still can't figure out is: I have 2x new 2TB EADS drives and 2x new 2TB EARS drives. I've jumpered the EARS drives before pre-clearing them but I'm still having a hard time deciding which to use as the parity drive. I don't think it'll matter much but...

 

Thoughts? 

[rd_blair]

I just replaced my parity drive with a WD20EARS-00S drive without the jumper. Old parity drive a Seagate 1.5 T will be used as data drive later, it has not been touched. The parity build completed no errors. I ran a parity test without correction after parity build no errors.

 

I had not read forum posts about this jumper issue. Now I am confused because the 20EARS is the parity drive. Do I unassign the parity device before powering down the array and adding the jumper? What do I do next? Can I just take the performance hit and run the array for awhile?

 

 

added: Just encase I am running unRAID 4.5.4 unMenu 1.3

[Rajahal]

After a fair amount of reading the one thing I still can't figure out is: I have 2x new 2TB EADS drives and 2x new 2TB EARS drives. I've jumpered the EARS drives before pre-clearing them but I'm still having a hard time deciding which to use as the parity drive. I don't think it'll matter much but...

 

Thoughts?  

 

It shouldn't matter, but I would probably use the EARS as parity.  In the future when the jumpers are no longer needed, it should be a bit faster than the EADS.  Today, however, it won't matter at all.

 

I just replaced my parity drive with a WD20EARS-00S drive without the jumper. Old parity drive a Seagate 1.5 T will be used as data drive later, it has not been touched. The parity build completed no errors. I ran a parity test without correction after parity build no errors.

 

I had not read forum posts about this jumper issue. Now I am confused because the 20EARS is the parity drive. Do I unassign the parity device before powering down the array and adding the jumper? What do I do next? Can I just take the performance hit and run the array for awhile?

 

 

Just because you haven't run into errors yet doesn't mean that you won't run into errors down the road.  Here's the procedure (unfortunately there's no way to do it without invalidating parity, but at least you still have your parity backed up on the 1.5 TB drive in case something goes wrong):

 

1) Stop the array

2) Go to the devices page and unassign the parity drive

3) Start the array (this will make it forget about the parity drive)

4) Stop the array, power down the server

5) Install the jumper on pins 7-8 of the EARS parity drive (you may have to physically remove the drive from your server for this step, or you may not, depending on your configuration)

6) Boot the server into unRAID

7) On the devices page, assign the EARS drive to the parity slot

Start the array.  unRAID should start a parity sync.

9) After the parity sync completes, run a parity check.

 

If the parity check has no errors, then all is well - your array is parity protected and you shouldn't have any troubles with your EARS drive.  I would still give it some time before adding the 1.5 TB drive back in as a data drive, if you have the luxury of waiting.  Definitely don't touch the 1.5 TB drive until all of the above steps are complete.  If a data drive fails during any of those steps, you will need that old parity drive to recover the data.

 

Edit: I removed the stuff about clearing because I forgot that the parity drive is never cleared.

[Joe L.]

7 ) Preclear the EARS drive (optional - only do this if you want to minimize the server's downtime)

There is no benefit in this situation of pre-clearing the EARS drive.  it has already been written to and read in its entirety.

The step is optional if you wish to exercise the disk, but there is absolutely no need to pre-clear a parity drive, as it will never be "cleared" by the unRAID software.

8  ) On the devices page, assign the EARS drive to the parity slot.

This step is required.

9 ) Start the array.  unRAID should start a parity sync.

This part of step 9 is true.

  The drive will be cleared if you skipped the preclear step.

This part of step 9 is not accurate.  Parity drives when initially being added are never cleared.  Data drives added after a parity drive is assigned are cleared if not already pre-cleared.

[bubbaQ]

7) Preclear the EARS drive (optional - only do this if you want to minimize the server's downtime)

 

Preclearing a parity disk will have no effect on downtime.  Parity disks are not cleared before usage by unRAID.

[Rajahal]

Ah, right, I forgot.  Thanks for the corrections.  I edited my post.

[rd_blair]

Thanks for the quick reply.

 

I seem to be rebuilding parity now but had some scares along the way. When I booted the unraid server after putting the jumper on it took a long time to get past the 20EARS drive. When the parity build started it took about 160 reads and a long time before it wrote to parity the first time. Now it is writing at 58,442 KB/sec and needs 519 minutes to go. Access to the web interface is painfully slow. Do you think this is going to work?

[Rajahal]

Seems to be working to me.

[NAS]

Interesting one.

 

I emptied a WD15EARS. Removed it from the array. Powered down. installed the jumper.

 

On start up i just get device error ad nausium and unraid never even gives a prompt.

 

So i pop it into a handy cradle which is unfortunately in a windows box. Delete the partition and try again. Same device error.

 

How can I make this drive work with the jumper when its previously been used without the jumper?

[Brandnewfatboy]

Interesting one.

 

I emptied a WD15EARS. Removed it from the array. Powered down. installed the jumper.

 

On start up i just get device error ad nausium and unraid never even gives a prompt.

 

 

I had the same error with one WD15EARS. When I attached a monitor, I could see unRAID trying to boot, but looping an error over and over again. Never got to a prompt.

One another WD15eARS, tried again and this time it did boot. But the syslog was riddled with an error, repeated over and over. Have still got this syslog saved somewhere if someone would find it useful.

 

In both cases, took the jumper off, reformatted, and all is back to jumperless normal.

 

Still have the urge to try adding jumpers again. Can't quite decipher a plan B as yet though