Large performance gap with EARS on 4.7

[ixnu]

I'm a noob, so please forgive me if this is common knowledge.

 

I'm seeing some serious performance issues with the WD20EARS.

 

Current set up:

4.7 Pro

 

2x Hitachi HDS5C302 (1 data, 1 parity)

2x SAMSUNG_HD204U253 (both data)

1x WDC_WD20EARS (data)

 

 

The Hitachis and Samsungs (F4's with updated firmware) both have about 40MB/s write and 60 MB/s reads after testing over two weeks and 4 TB of data transfer.

 

I recently added the WD EARS and it is writing at ~ 19-25 MB/s after about 500 GB of testing. It also has occasional momentary pauses (using robocopy from Win7).

 

I do not have the jumper attached (and never have) to the WD. This was a clean install of 4.7 pro.

 

Is this normal?

 

I have attached my syslog from the start of the clear. Looks OK to me.

 

WDsyslog.txt

[onthecake]

Are they all plugged into the same controller? Copying the same data?

 

That is very slow for the EARS. I have about 8 in mine and get around 40-50 MBs on average. My only complaint with them is they run a littler warmer than the hitachi or samsungs and their failure rate seems to be higher.

[ixnu]

Thanks for the quick response.

 

Are they all plugged into the same controller?

 

Yes, they are all plugged into the same (onboard) AMD SB710 controller. It is plugged into slot 5 of 6 (second slot of second bank).

 

Copying the same data?

 

Yes, it's the same type of data. I'm migrating my movie rips (mostly MKV's) off of my Win7 box to an unRaid box. This HDD had been working in my Win7 box for several months without issues.

 

My only complaint with them is they run a littler warmer than the hitachi or samsungs and their failure rate seems to be higher.

 

Slower, hotter, and less reliable...what's not to like?

 

As I write this, the avg write speed has dropped to ~16 MB/s.  :'(

[Rajahal]

Did you enable the '4k mbr aligned' option on the unRAID 'settings' page?

[lionelhutz]

But the syslog doesn't look OK.

 

This line is causing slower speeds

 

May  2 19:12:41 Tower emhttp: writing mbr on disk 4 (/dev/sde) with partition 1 offset 63 (Drive related)

 

The drive partition should start on sector 64 (offset 64) and not sector 63. You should be using the partition 4k aligned setting on the unRAID settings page instead of the unaligned setting. You will have to clear the MBR before unRAID will write a new partition.

 

Peter

[ixnu]

The drive partition should start on sector 64 (offset 64) and not sector 63. You should be using the partition 4k aligned setting on the unRAID settings page instead of the unaligned setting. You will have to clear the MBR before unRAID will write a new partition.

 

Thanks Peter!

 

The disk just contains test data, so no biggie.

 

I followed the wiki entry here:

http://lime-technology.com/wiki/index.php?title=Advanced_Format_Drives

 

And it seemed like I didn't have to do anything. Is there a procedure for using this disk in 4.7?

 

Is there a script or wiki for clearing the MBR, or is it fdisk time?

 

Can I do something like this:

 

1.) delete all the data on the disk 

2.) drop it from the array

3.) clear the MBR (not sure how to do this correctly)

4.) clear it in unraid (or with the script?)

5.) Add it to the array

6.) Set the sector at 64 on the settings page

7.) format

8.) write to it

 

Thanks again.

[Rajahal]

Change the 4k mbr aligned setting right now.  I won't affect your current disks, only future disks.

 

You can use the preclear script to clear the MBR:

 

Added "-z" option to zero the MBR and do nothing else.

 

The syntax would look like this:

 

preclear_disk.sh -z /dev/sdX (where X is the drive letter)

 

There's actually no need to delete the data, unRAID will take care of that for you as it zeros the disk.  If you don't want your array to be down for a long them, then you could run a full or quick preclear on the disk, like this:

 

Full: preclear_disk.sh /dev/sdX

Quick: preclear_disk.sh -n /dev/sdX (skips the preread phase)

[ixnu]

Did you enable the '4k mbr aligned' option on the unRAID 'settings' page?

 

Doh!, no I did not.

 

Two questions:

1.) Do you know if the Samsung and Hitachis need to be aligned formated? Should they be re-formatted?

 

2.) What are the ramifications of changing the setting going forward?

 

Thanks for your help!

 

 

[ixnu]

preclear_disk.sh -z /dev/sdX (where X is the drive letter)

Full: preclear_disk.sh /dev/sdX

 

So the procedure would be to:

0.) Change align setting on unraid settings page

1.) stop array

2.) remove drive from array (not sure about this step)

3.) run preclear_disk.sh -z /dev/sde from putty (the -z clears the mbr)

4.) format disk

5.) write to disk

 

 

[Rajahal]

The Samsung and Hitachi drives do not need to be advanced formatted, but it won't hurt them either.  I recommend turning on the 4k aligned option and leaving it on for the rest of your server's life.  It will work with any new drive (the only exception being a WD EARS drive with a jumper installed).  In fact, I don't know why that isn't the default setting in unRAID 4.7 - I think it should be.

 

Your procedure would be:

0) Enable 4k align setting on unRAID 'settings' page

1) stop array

2) remove sde from array by unassigning it on the 'devices' page

3) go back to the unRAID 'main' page and start the array with one missing disk

4) run preclear_disk.sh -z /dev/sde from putty (the -z clears the mbr).  This should only take a few seconds or maybe minutes.

5) stop the array

6) assign the disk to the same slot on the 'devices' page

7) go back to the unRAID main page - it should say 'upgrading disk'.  Click the 'I'm sure' checkbox and start the array.  unRAID will rebuild the old data onto the disk.  This will take many hours, but your array will be available the entire time.

[mbryanr]

The Samsung HD204 is advanced format, regardless MBR Aligned is the way to go.

[lionelhutz]

The Samsung and Hitachi drives do not need to be advanced formatted, but it won't hurt them either.  I recommend turning on the 4k aligned option and leaving it on for the rest of your server's life.  It will work with any new drive (the only exception being a WD EARS drive with a jumper installed).  In fact, I don't know why that isn't the default setting in unRAID 4.7 - I think it should be.

 

Your procedure would be:

0) Enable 4k align setting on unRAID 'settings' page

1) stop array

2) remove sde from array by unassigning it on the 'devices' page

3) go back to the unRAID 'main' page and start the array with one missing disk

4) run preclear_disk.sh -z /dev/sde from putty (the -z clears the mbr).  This should only take a few seconds or maybe minutes.

5) stop the array

6) assign the disk to the same slot on the 'devices' page

7) go back to the unRAID main page - it should say 'upgrading disk'.  Click the 'I'm sure' checkbox and start the array.  unRAID will rebuild the old data onto the disk.  This will take many hours, but your array will be available the entire time.

 

Exactly, you can just rebuild the data right back onto the disk. You will have to go through either a disk rebuild or a parity build so you might as well just do this and test the disk rebuilding at the same time.

 

Peter

[onthecake]

In fact, I don't know why that isn't the default setting in unRAID 4.7 - I think it should be.

 

I guess I thought was set by default since it said 4.7 supports AF drives. I will need to go back through each drive and do this as well  :'(

[ixnu]

The Samsung and Hitachi drives do not need to be advanced formatted, but it won't hurt them either.  I recommend turning on the 4k aligned option and leaving it on for the rest of your server's life.  It will work with any new drive (the only exception being a WD EARS drive with a jumper installed).  In fact, I don't know why that isn't the default setting in unRAID 4.7 - I think it should be.

 

Rajahal, thanks very much for your time. This is has to be the most confusing part of unRaid for me.

 

I'm happy with ~40 MB/s write speed on the Sam's and Hitachi's, and since it has no affect on reliability, I don't think I will go back and reformat them.

 

I'll report back on the progress.

 

Thanks for all of the quick help!

[Rajahal]

Right, don't bother with the disks that aren't slow, it won't help anything.

 

Same goes for you, onthecake.  If you aren't experiencing performance issues, then don't bother to do this.

[mbryanr]

For performance results unaligned:aligned on the Samsung -

 

http://lime-technology.com/forum/index.php?topic=8012.msg77505#msg77505

 

 

Note:  This comparison and summary was before the release of unRAID AF compatibility.

[onthecake]

I was under the impression that this was something that got worse/slower over time?

 

 

[Johnm]

I just read this thread and totaly feel like a total noob...

 

I just had a face palm and slammed my head onto my desk.

 

All for a non-unRAID reason.. well. Ok it is, but not in an un-RAID server. yet...

 

I am backing up the last of my data off my WHS so i can move the drives to my unRAID.

 

I shoved a brand new EARS into the server outside of the WHS pool and started to back up the last Terabyte of data from the pool i wanted to save. I just noticed my backup drive to drive is copying at 13MB/s... I shrugged and said thats odd and went back to surfing the forums.

DOH i forgot to jumper that unit. WHS is 2003 (XP) based, no AF...

 

9 EARS in that server all jumpered and I forgot to jumper the back-up drive.

 

reading your issue just reminded me that I just did something stupid.

 

so, it goes to prove it happens, even to sys admins.

 

thanks for the help, both in reminding i forgot the jumper now, and to remind me to pull them off when i migrate the drives to unRAID.

 

DIT TYPO

[Rajahal]

I was under the impression that this was something that got worse/slower over time?

 

Not that I know of.  The performance difference should be immediate.  Granted, you are likely to notice it more on groups of small files than you are on single large files.

 

Johnm: I wouldn't recommend removing the jumpers from your EARS drives.  Just add them as they are and preclear them using the -a option (which uses sector 63, which the jumper then corrects to sector 64).  unRAID will them use them correctly.

 

If you are OCD and simply must remove the jumpers, then the -A option in preclear will 'fix' them.  However, you won't see any performance benefit over leaving the jumpers in place and using the -a option.  unRAID won't care either way.  The risk with this comes from reports of WD EARS drives bricking once the jumper is removed.  I haven't seen it personally, but it doesn't seem worth the risk to me.  RMAing a drive is a hassle.

[lionelhutz]

thanks for the help, both in reminding i forgot the jumper now, and to remind me to pull them off when i migrate the drives to unRAID.

 

Don't pull them off. EARS react badly when this is done. You will have to do at least 1 read and write pass over the drive to get it to quit throwing errors and actually behave again.

 

If you are doing all these drives at once then set unRAID to unaligned and assign the drives and create the array. Then, set it to 4k-aligned right after and never use a jumper again. I personally wouldn't bother with the preclear if you are creating a new array. Those drives have been running in another server so they should be OK. If you are adding them then use the switches to only clear the drive and skip the pre and post reads which will make it take about 9 hours instead of 25 hours. I don't know offhand but typing preclear_disk.sh will print the help with the different switches.

 

Peter

[Johnm]

Honestly,

 

These drives were actually old back up drives that had been on a shelf for over a year.  then jumpered and shoved into the WHS 2 or 3 months ago. that box was just to test DE. I don't think i even dusted them off..

 

For peace of mind and data integrity, I have no problem's pulling the jumpers off and do a full preclear.

 

These are gen 1 and early gen 2 EAR 2TB's .

1 has a smart error for a pending remap (a gen 1). that one will get a full WD test before i decide it's fate.

 

 

If i was migrating them to a 2008r2 or ZFS box i would probably use the WD tools to test and zero the drives anyways.

I don't mind the 2 day wait to both see how my build handles heat and to really test/verify the drives.

 

I read elsewhere that 2 preclear passes is a good idea in my case. 3 for new drives?

(sorry for the slight hijack)

 

And thank you for the advice.

[Rajahal]

2 passes is enough if the drives behave, but if they start throwing a lot of errors then you might need to run more.

 

I'm with lionelhutz, though.  Why risk bricking the drives?  Just use them with the jumpers installed and don't use jumpers on any subsequent drives.

[Johnm]

Brick.. strong word.

 

My thinking was, i was unsure of the drive stability, I honestly dont have a lot of faith in a 3 year old EARS. My thought was, I just rather kill the drive while empty instead of it failing months from now with data. Even if i recover the data, my time is worth more then the  24-48 hours to repair.

 

now you have me thinking otherwise. I'll just have to put a post it/masking tape on the drive with notes to -a it.

 

thanks again.

 

and yes i have OCD! ARGH!

[Johnm]

I definitely have a bigger issue then a jumper.

 

I pulled the new EARS out and put in a sammy F2 1.5TB and started my copy over. I just noticed it is taking an hour to copy an 8Gig MKV.

 

The rest of the rig is a well burned in, stable supermicro server. all drives are on the mobo headers. glad its getting decommissioned.

[lionelhutz]

I definitely have a bigger issue then a jumper.

 

I pulled the new EARS out and put in a sammy F2 1.5TB and started my copy over. I just noticed it is taking an hour to copy an 8Gig MKV.

 

The rest of the rig is a well burned in, stable supermicro server. all drives are on the mobo headers. glad its getting decommissioned.

 

Is there a parity build or drive rebuild going on?