Advanced Format Drives - WD10EARS WD15EARS WD20EARS


Recommended Posts

Hi Guys,

 

First time poster, but I'm currently pre-clearing my drives to try my hand at Unraid (free version).  I bought (3) WD10EARS, which are connected to the SATA ports furnished on my Intel P4 motherboard.  

 

There's been a lot of talk about these drives and it's confusing, to say the least, to me.  I'm not foreign to *nix, but sectors and cylinders are beyond my knowledge.  I wanted to put this post together to try and help out anybody else that grabs a WD??EARS, since the knowledge is buried in other threads.

 

At this time, I have not installed the jumper across pins 7-8.

 

preclear was giving me 98 MB/s read rates when I was clearing only /dev/sda.  Now that I am clearing sda, sdb, and sdc at the same time, I am getting read rates of 57 MB/s, 41 MB/s, 41 MB/s.  We shall see what the write performance is :)

 

In other implementations they have been successfully using "fdisk -u" to start the partition on sector 64.  However, Joe L. doesn't think this will work, as stated here:

 

Unfortunately, I think if you were to change the first partition in unRAID to start on cylinder 64 instead of 63 it would no longer be recognized as a valid unRAID file system.    unRAID expects the cylinder to start on the first full cylinder as reported by the disks geometry.  (Typically on sector 63)   If the disk reported cylinders of 64 sectors, rather than of 63, the partition created and subsequently looked for by unRAID would start on sector 64.  I do not think this is possible since the field in the MBR for the number of sectors per track can only have values from 1-63.

 

I've not done any experiments with this, but it is just from my experience in writing the pre-clear disk utility and how unRAID decided if the disk is one it can mount, or is one that is foreign to it.    I suppose the trick will be to get the disk's reported geometry to be cylinders of 64 instead of 63.   This whole historical start on sector 63 is a hold-over from MS-DOS days... unRAID is trying to make the disks recognizable in MS-Windows based tools.  There is no underlying reason for the start on sector 63, and leaving sectors 1-62 unused otherwise. (sector 0 is the MBR)

So, using fdisk to realign the partition doesn't appear viable at this time.

 

However, we do have instructions on the HDD label "Windows XP, single partition - set jumpers 7-8 prior to installation or use WD align SW"

 

Anandtech has an explanation of the jumpers here:

 

Through the jumpering of pins 7 and 8 on an Advanced Format drive' date=' the drive controller will use a +1 offset, resolving Win 5.xx’s insistence on starting the first partition at LBA 63 by actually starting it at LBA 64, an aligned position. This is exactly the kind of crude hack it sounds like since it means the operating system is no longer writing to the sector it thinks its writing to, but it’s simple to activate and effective in solving the issue so long as only a single partition is being used.[/quote']

 

GaryMaster has done a lot of benchmarking are reports here that jumpering pins 7-8 solves the write performance issue.

 

So, my remaining questions are:

 

1. Do I need to run preclear again after the jumpers are set?  Any bad sectors will have been discovered, so I don't think so?

2. Should I try the fdisk route "just for the heck of it", or is it certain that this will not work?  I have no overwhelming desire to use fdisk if we know the jumper works, but if the only way to know for certain if fdisk works is to try it, I'm willing to try it.

 

Thanks,

Tim

 

 

 

 

Link to comment
  • Replies 284
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

So, my remaining questions are:

 

1. Do I need to run preclear again after the jumpers are set?  Any bad sectors will have been discovered, so I don't think so?

If you put the jumper into place after the pre-clear script has been run the disk will substitute sector 1 when accessing sector 0, 2 when accessin 1 ... 64 when accessing 63, 65 when accessing 64, etc.   This will improve performance since the partition starting on sector 63 is then fooled into using a sector (64) aligned on the 4k boundaries.

 

The "partition table" that holds the original partition table, master boot record and pre-clear signature looked for by unRAID will not be visible.  They were in sector 0. (no longer visible with the jumper in place)  The "cleared" sector 1 (now presented as 0) will be completely blank... as you cleared it to be all zeros.  

 

The disk will still work perfectly in unRAID, but unRAID will perform a clearing and partitioning of the disk on its own.  It will do this if you have already assigned a parity disk to your server because it will not detect a pre-clear signature.

2. Should I try the fdisk route "just for the heck of it", or is it certain that this will not work?  I have no overwhelming desire to use fdisk if we know the jumper works, but if the only way to know for certain if fdisk works is to try it, I'm willing to try it.

If the first sector is ANYTHING other than 63 unRAID will consider the disk to be foreign and will it clear it on its own.  (Part of the pre-clear signature is that the disk has a single partition that starts at sector 63) Therefore, using fdisk will not help...  It is certain it will not work.

 

Putting the jumper on the pins on the disk will improve performance.  It is not necessary unless you are trying to wring every bit of performance from the drive, but since it is so easy, you should put the jumper in place.

 

Pre-clearing before putting the jumper in place will still allow the disk to identify any bad sectors, so it is not a complete waste.  It is up to you if you wish the current pre-clear process to complete, or stop it, add the jumper, and then re-start.  Putting the jumper on after pre-clearing will just cause the drive to not be seen as partitioned (or pre-cleared) at all.

 

Since you are either going to go through a clearing performed by unRAID, with the server unavailable for some hours while it does the zeroing, or another preclear_disk.sh performed by you, with the server on-line, I'd choose another preclear_disk.sh script cycle.

 

One last thing... if you have not yet assigned a parity drive to your array unRAID does no clearing of a disk on its own.   So you'll not be affected by the jumper addition.   The clearing step, or omission if the disk signature shows it is pre-cleared, is not pertinent.

 

Joe L.

Link to comment

Thanks Joe for the detailed response.

 

I have unraid booting and all is well.  I am running the preclear script from /boot (I checked to make sure it is the latest) as furnished with the unraid image.  I have not assigned any of the three drives (the only three drives I have) in unraid.

 

With that in mind; regarding the following:

 

Since you are either going to go through a clearing performed by unRAID, with the server unavailable for some hours while it does the zeroing, or another preclear_disk.sh performed by you, with the server on-line, I'd choose another preclear_disk.sh script cycle.

 

One last thing... if you have not yet assigned a parity drive to your array unRAID does no clearing of a disk on its own.  So you'll not be affected by the jumper addition.  The clearing step, or omission if the disk signature shows it is pre-cleared, is not pertinent.

 

If I am understanding correctly, I could finish the current preclear, install the jumpers, and assign the drives in unraid, as this is a fresh install with no data nor parity yet.

 

Thank you for your help,

Tim

Link to comment

Thanks Joe for the detailed response.

 

I have unraid booting and all is well.  I am running the preclear script from /boot (I checked to make sure it is the latest) as furnished with the unraid image.  I have not assigned any of the three drives (the only three drives I have) in unraid.

 

With that in mind; regarding the following:

 

Since you are either going to go through a clearing performed by unRAID, with the server unavailable for some hours while it does the zeroing, or another preclear_disk.sh performed by you, with the server on-line, I'd choose another preclear_disk.sh script cycle.

 

One last thing... if you have not yet assigned a parity drive to your array unRAID does no clearing of a disk on its own.   So you'll not be affected by the jumper addition.   The clearing step, or omission if the disk signature shows it is pre-cleared, is not pertinent.

 

If I am understanding correctly, I could finish the current preclear, install the jumpers, and assign the drives in unraid, as this is a fresh install with no data nor parity yet.

 

Thank you for your help,

Tim

Yes.  If you assign the data drives before you assign a parity drive they will not be cleared by the unRAID software. 

 

Once you assign a parity drive you will face a full parity calculation.  That is unavoidable.

 

After you start the array with a parity drive with at least one data drive, any subsequent data drives added at a later time will be cleared by unRAID if they do not contain a pre-clear signature.

 

Your current pre-clear process will do its job in exercising the disk to find bad sectors.   

 

Joe L.

Link to comment

Do the WD15EADS models need to have the jumpers set?

 

No.  Those work out-of-the-box.

 

I recently installed an EARS drive into my server.  I installed the jumper beforehand, and everything seemed normal on the unRAID side.

 

My only question is that after some time has passed and the rest of computer technology starts catching up with these 'advanced format' drives, am I going to have to go in and remove the jumper at some point?

Link to comment

bubbaQ says here:

 

You OS was already using 4K block size by default.

 

There are four distinct units that you must be keeping in mind:

 

1. Hardware block size (i.e. sector)

2. Filesystem block size, (a block, or under FAT what is called a cluster... the smallest unit of filesystem size).

 

ReiserFS default is 4K blocks.... but admittedly, I haven't checked if unRAID alters that.

 

So it appears that technology isn't catching up, it's already there.  It seems that unraid's assumption that that partition begins at 63 is the only stumbling block.

 

I imagine that sometime in the future unraid will support the partition beginning at 64.  Since this is currenty addressed easily via the jumper, it's not a big deal to me.

 

Tim

Link to comment

I installed the jumper across pins 7 & 8 and am running the preclear_disk script again (have 3 instances of the script open in different vttys),  in write mode I am now getting:

 

Drive/dev/sda/dev/sdb/dev/sdc

Speed (no jumper)73.1 MB/s62.9 MB/s62.2 MB/s

Speed (Pins 7-8 Jumpered)80.7 MB/s68.3 MB/s63.1 MB/s

Improvement10.3%8.5%1.4%

 

 

HTH,

Tim

Link to comment

I installed the jumper across pins 7 & 8 and am running the preclear_disk script again (have 3 instances of the script open in different vttys),  in write mode I am now getting:

 

Drive/dev/sda/dev/sdb/dev/sdc

Speed (no jumper)73.1 MB/s62.9 MB/s62.2 MB/s

Speed (Pins 7-8 Jumpered)80.7 MB/s68.3 MB/s63.1 MB/s

Improvement10.3%8.5%1.4%

 

You can't really judge the improvement from that. 

When you are running 3 instances of the preclear_disk script at the same time, you have a different bottleneck.

 

Link to comment
  • 2 weeks later...

Ok, so it sounds like if I put a jumper on the WD drive it works just fine. It also sounded like unRAID wouldn't recognize it correctly if I removed the jumper after pre-clearing.

 

Soo...is the following correct?

 

If I bought these today, I'd put the jumper on, put it in the unRAID system and it happily goes.

 

Say at some point in the future, unRAID is upgraded and it no longer needs the jumper. I would need to shutdown the array, remove the jumper, restart it and let unRAID rebuild the drive without the jumper.

 

Forgot to ask. Does this need to be the parity drive if I have the WD 2TB Black drive in the system?

 

This process would be needed to remove the jumper from every drive that was previously jumpered one at a time.

 

Also...if given a choice, is there ANY reason to buy the older EADS drives over these if you jumper them?

Thx!

 

Link to comment

Ok, so it sounds like if I put a jumper on the WD drive it works just fine.

Correct.

 

It also sounded like unRAID wouldn't recognize it correctly if I removed the jumper after pre-clearing.

Correct.

 

If I bought these today, I'd put the jumper on, put it in the unRAID system and it happily goes.

Correct.

 

Say at some point in the future, unRAID is upgraded and it no longer needs the jumper. I would need to shutdown the array, remove the jumper, restart it and let unRAID rebuild the drive without the jumper.

I asked this before (can't find the thread at the moment), but I believe the answer was that there will never be a reason to remove the jumper in the future.  If you do remove the jumper, I believe you will lose all your data and have to reformat the drive.

 

Forgot to ask. Does this need to be the parity drive if I have the WD 2TB Black drive in the system?

No, if you already have a 2 TB drive as your parity drive, then you should be able to add a 2 TB EARS drive as a new data drive.  The only issue you may run into is if you have a Gigabyte board with HPA enabled.

 

Also...if given a choice, is there ANY reason to buy the older EADS drives over these if you jumper them?

Not really.

Link to comment

Say at some point in the future, unRAID is upgraded and it no longer needs the jumper. I would need to shutdown the array, remove the jumper, restart it and let unRAID rebuild the drive without the jumper.

I asked this before (can't find the thread at the moment), but I believe the answer was that there will never be a reason to remove the jumper in the future.

This answer kind of surprised me. I thought that in the future there may be the possibility of having the first sector start at 64 (instead of 63) or at sector 32 maybe. If/when that hapens, that will be a good reason to want to remove the jumper. (after backing up everything from that disk of course, and then reformatting it without the jumper)

 

Link to comment

Say at some point in the future, unRAID is upgraded and it no longer needs the jumper. I would need to shutdown the array, remove the jumper, restart it and let unRAID rebuild the drive without the jumper.

I asked this before (can't find the thread at the moment), but I believe the answer was that there will never be a reason to remove the jumper in the future.

This answer kind of surprised me. I thought that in the future there may be the possibility of having the first sector start at 64 (instead of 63) or at sector 32 maybe. If/when that hapens, that will be a good reason to want to remove the jumper. (after backing up everything from that disk of course, and then reformatting it without the jumper)

 

 

Yeah, that's what I was thinking too. When it would natively support it, I would remove the jumper and yes I would "lose" the data but I would expect unRAID to let me rebuild that drive correctly. Hence my comment of rebuild one drive at a time.

Link to comment

I've got two of the WD15EARS drives that I'm trying to install in my unRAID server in place of two existing 750GB drives.  I had initially installed one of the 1.5TB green drives and left off the jumper.  The drive seemed to work fine as it rebuilt the data from the drive it replaced via the parity drive.  When I attempted to transfer a large file (18GB Blu-Ray rip) to the server, I kept getting an error message about the tower not being found as it was apparently being disconnected and terminating the transfer.  After a nightmarish situation which cost me to lose about 1.5 to 2TB of data (a story told in another thread), I was able to rebuild the array.  Unfortunately, the problem still persists.  I tried adding the jumper but the array would not start up.  After a bit more reading I came across this thread.

 

Do I need to pre-clear the drive and then re-install it?  If so, what's the process for performing the pre-clear?  What's the best way to integrate the new drive into the array as replacement?

 

P.S.  A little more searching found me the preclear_disk.sh thread.  I'll read up some more and see if I can figure this thing out.

Link to comment

When I attempted to transfer a large file (18GB Blu-Ray rip) to the server, I kept getting an error message about the tower not being found as it was apparently being disconnected and terminating the transfer. [...] the problem still persists.

If your server is freezing on you upon copying large files, you may want to try the tweaks from this thread:

http://lime-technology.com/forum/index.php?topic=5621.msg52470#msg52470

Apply them, and see if the problem will still persist.

 

Link to comment

I haven't had a chance to try the recommended tweak.  Instead, I reinstalled the original 750GB drive and then let it rebuild parity.  I just tried to boot with the WD15EARS jumpered drive installed in an unassigned slot but when it checked the drive during the last phase of booting it just kept resetting in an endless loop.  I tried to insert the drive in the hot swap bay after it finished booting but unRAID would not recognize the drive, which is about what I expected.  I wanted to run the preclear_disk.sh script on the drive but it won't even boot up with the drive installed.  Any idea on what I can do to get it to boot up and run preclear on the drive?

 

FWIW, I had an identical drive that I installed without the jumper that integrated into the array with no problems.  The issue I had with it was that I couldn't transfer any large files to it without it resetting and losing connection with my PC.  When I installed the jumper, the array simply would not finish booting but simply got stuck in an endless loop with a drive not ready error.  This happened with the original 1.5TB drive that had data and the jumper was added after the fact as well as a new drive being booted for the first time.

Link to comment

Not sure, but with the WD20EARS drive I got, I didn't have any luck getting my unRAID to go without the jumper. Once I had the jumper on, it would see the drive and start rebuilding data. Not sure if its indicative of "normal" behaviour or not as it seems like other people were able to try the drive without jumpering it.

Link to comment
  • 1 month later...

I currently have 2x EADS and am thinking about picking up another two EARS tomorrow. None of them have been introduced to my unraid box yet. My gut tells me I'd put one of the (jumpered) EARS as the parity drive as it tends to give a  bit more performance. Would that be the best choice?

Link to comment

I currently have 2x EADS and am thinking about picking up another two EARS tomorrow. None of them have been introduced to my unraid box yet. My gut tells me I'd put one of the (jumpered) EARS as the parity drive as it tends to give a  bit more performance. Would that be the best choice?

The SLOWEST rotational speed drive involved write dictates performance.  The only exception to that is a faster parity drive will help if there are multiple processes writing multiple files to different data disks at the same time.  That is the only time the slowest rotational speed drive will not dictate the write performance.

 

The faster parity disk "might" help it to keep up with simultaneous writing to two or more data disks, remembering it will also have to move the disk head and seek between the various writes to the sectors that will not be contiguous.  That need to "seek" may negate some or all of the gain by having a faster drive.  The larger 4K sectors are not really so much of an issue since unRAID typically is writing and reading much larger files when used as a media server.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.