# HELP: WD 2TB green power is slow

## Moriah

I have a 3-way RAID-1 mirror on my backup server.  I had recently been using Seagate 7200 RPM 1.5 TB drives, and they worked great, but I needed something a little bigger, so I went to Western Digital 2 TB "Green Power" drives, and they are dog slow!    :Evil or Very Mad: 

A backup operation that used to start at 1:30 AM would finish before 8:00 AM with the Seagates, but runs until a little after 8:00 PM (yes PM, over 12 hours longer!) with the WD green power drives.  

I can't figure out how to set the power management with hdparm to kick this speed up.  Obviously, these drives are not going to be as fast as the 7200 RPM Seagates, but they certainly should not be 3 times as slow either.  My guess is that the "green" in green power means they are trying to save the earth or something, and don't care if the thing is slower than punched paper tape going thru a teletype.    :Mad: 

Does anybody have any idea how to configure these drives with hdparm (or a sledge hammer) to make them run faster?

----------

## BradN

Is your backup operation seek dominated, or largely throughput limited?

If it's the former, try hdparm -M 254 or hdparm -M 0.

If it's throughput limited, verify bad drive performance with hdparm -t -T.  Apply sledge hammer to WD engineer, because there's no power saving benefit to not reading the data as it traverses the read head.

If you've configured your raid array with a stripe size larger than 1/2 * drive buffer size, I could envision situations where this could cause problems depending how linux's software raid is implemented.  If you haven't manually set this, don't worry about it.

----------

## dmpogo

These are the ones with 4k sectors ?   Do you have partitions aligned ?

http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/index.html?ca=dgr-lnxw074KB-Disksdth-LX

----------

## Hu

Also, check to see if you got saddled with drives that have "Advanced Format."  This is Western Digital's codename for drives that use 4K sectors internally, but lie and claim to be 512-byte sectors to the OS.  As a result, everyone partitions them badly and performance is terrible.  If you have an affected model, a few hours reading Google results from "linux 4K sector" or variants thereof may let you substantially increase drive performance.  You will have to repartition the drives to do so, which means moving all the data off them first.

----------

## Moriah

The really noticable time eater is seek dominated, as bazillions of hard links are made to copy the current backup image to a directory tree associated with today's date.  The tomorow, rsync runs again and updates the current backup image directory, which then again gets copied with hard links to preserve that day's filesystem image.  I am doing this for 18 systems on my network every night.  

I dinkered with the power management settings, but it seemsed to make no difference, so I will look into the 4K sector thing instead.  Yes, these are WD "advanced format" drives.  I run a couple of 250 GB SSD's on my laptop, so I am familiar with the format alignment issues that can arise when the sector size is not what it seems.

I understand the need for larger sectors on such a large drive; it just would have been nice for them to tell you about it!    :Evil or Very Mad: 

BTW The RAID is RAID-1, a 3-way (3 drives all holding identical data) mirror, so there is no striping to worry with.

----------

## dmpogo

 *Moriah wrote:*   

> The really noticable time eater is seek dominated, as bazillions of hard links are made to copy the current backup image to a directory tree associated with today's date.  The tomorow, rsync runs again and updates the current backup image directory, which then again gets copied with hard links to preserve that day's filesystem image.  I am doing this for 18 systems on my network every night.  
> 
> I dinkered with the power management settings, but it seemsed to make no difference, so I will look into the 4K sector thing instead.  Yes, these are WD "advanced format" drives.  I run a couple of 250 GB SSD's on my laptop, so I am familiar with the format alignment issues that can arise when the sector size is not what it seems.
> 
> I understand the need for larger sectors on such a large drive; it just would have been nice for them to tell you about it!   
> ...

 

What filesystem are you using, BTW ?

----------

## dmpogo

 *Moriah wrote:*   

> The really noticable time eater is seek dominated, as bazillions of hard links are made to copy the current backup image to a directory tree associated with today's date. 

 

I wonder how IntelliSeek of the green WD drives performs here

----------

## Moriah

I am running XFS because it benchmarked fastest when deleting multi-mega-bazillions of hard links when I clear a month off the raid-1 array.

I too wonder about "intelliseek".  One would hope that they buffred multiple writes and used the elevator algorithm to minimize seeking, but who knows, it could really be "stupidoseek" instead.    :Surprised: 

----------

## jathlon

 *Moriah wrote:*   

> I am running XFS ... 

 

Might be a couple of useful tips in this thread;

https://forums.gentoo.org/viewtopic-t-488215-highlight-xfs.html

The original thread is pretty old but there are some more up to date info later on.

Happy trails,

jathlon

----------

## Moriah

Please focus on the drives, not the filesystem, or anything else.  Remember (you *DID* read the first post, didn't you?) that the only thing that changed was the drives went from seagate 1.5 TB 7200 RPM drives to WD green power 2 TB drives.  *NOTHING* else has changed, except, of course, the fact that it now takes 3 times as long as it used to.    :Sad: 

----------

## BradN

Well, the filesystem does come into play here because of the drive.

You might consider a filesystem that can use 4KB blocks (maybe XFS can, I don't know), otherwise the drive will have to make 2 passes at the data to update a 1KB block if the other 3KB aren't being written.  This could explain a 1/3 speed slowdown since what normally might be a 1/2 disk rotation seek on average, now becomes 1 1/2 rotations (half a rotation to reach the data and another full spin to finish updating it).  Also, make sure your partition is 4KB aligned then or this block size adjustment won't help at all.

Honestly I'm surprised it took them this long to move to larger sector sizes, hell I'm surprised 512 even became standard... floppy controllers at the time could do 1KB sectors even.

----------

## dmpogo

 *Moriah wrote:*   

> Please focus on the drives, not the filesystem, or anything else.  Remember (you *DID* read the first post, didn't you?) that the only thing that changed was the drives went from seagate 1.5 TB 7200 RPM drives to WD green power 2 TB drives.  *NOTHING* else has changed, except, of course, the fact that it now takes 3 times as long as it used to.   

 

If it is something related to sector aligning with 4k sectors, the filesystem matters, as the link given above shows.  Different filesystems suffer differently from misaligned partitions, with reiserfs suffering the most, it seems (not sure if it is reiser4 or 3, however).

----------

## dmpogo

 *Moriah wrote:*   

> I am running XFS because it benchmarked fastest when deleting multi-mega-bazillions of hard links when I clear a month off the raid-1 array.
> 
> I too wonder about "intelliseek".  One would hope that they buffred multiple writes and used the elevator algorithm to minimize seeking, but who knows, it could really be "stupidoseek" instead.   

 

Based on WD description, intelliseek relates to mechanical motion of the arm, which is designed to smoothly without jerk arrive to a sector just in time for it to be used. The normal seek moves the arm as fast as it can to required track and then waits the track to spin the sector into position.   Could be that intelliseek implementation leads to additional waits (obviously there are cases when fast arm motion would catch a sector, but smooth one will have to wait an extra turn)

----------

## Cyker

Intelliseek shouldn't affect the seek speed; It's just a fancy term for just-in-time seeking.

It won't 'miss' a seek any more than any other drive - If it needs to do a fast seek to an incoming sector, it will. It only does slower seeks when it knows it has time to.

WD GP drives are not much slower than regular 7200rpm drives, but they do have much higher latency so seek-heavy stuff will suffer quite badly on them.

As others have said, you will also need to check for 4k alignment as writing to misaligned sectors will almost halve the write speed, and will multiply the penalties of seek-heavy stuff even more!

I'm assuming you're already using 4k blocks for your filesystem since almost everyone except FAT32 users are, so once you get the sectors aligned with the filesystem blocks that should give a decent performance boost for seeky writes.

I have RE4-GPs, which are similar but have 64MB caches (!!) and don't use 4k sectors. I've mitigated the long seeks using RAID5 and massive amounts of write-buffering,

It may also be worth testing NCQ vs deadline for the disk schedulers; no-op/deadline tend to perform better on my system for seeky stuff, but as RAID1 isn't striped, NCQ might be better.

----------

## frostschutz

With 4k sector drives you have to be 4k aligned for everything. Any storage layer you put on the drive, from partitioning over raid / lvm to filesystem, must respect 4k boundaries. Otherwise it will be as slow as a crawl. If you see performance problem with these drives, they're either broken, or you're misaligned somewhere. Also especially with the WD drives, alignment is not done for you. You have to take care of it yourself. Because these drives claim they are 512byte and not 4k, when they really are 4k and nothing else.

----------

## dmpogo

 *Cyker wrote:*   

> 
> 
> I have RE4-GPs, which are similar but have 64MB caches (!!) and don't use 4k sectors. I
> 
> 

 

If Green WD's are EARS, the also have 64Mb cache.  EADS have 32Gb.

----------

## dmpogo

 *Cyker wrote:*   

> Intelliseek shouldn't affect the seek speed; It's just a fancy term for just-in-time seeking.
> 
> It won't 'miss' a seek any more than any other drive - If it needs to do a fast seek to an incoming sector, it will. It only does slower seeks when it knows it has time to.
> 
> 

 

Yeah, after I wrote my speculation I had thought that it would be plain stupid if it does not do this  :Smile: 

----------

## New User

I have the WD20EARS advanced format drive and I have been having a lot of trouble getting it to run at an acceptable speed.  It takes about a week to just format it with ext4 -b 4096  I have studied plenty of threads on setting the sector size and  alignment.  Like the following:

http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/index.html?ca=dgr-lnxw074KB-Disksdth-LX

http://ubuntuforums.org/showthread.php?t=1456251&page=3

https://forums.gentoo.org/viewtopic-t-838522-highlight-advanced+format.html

I have tried using the parted and also gdisk

Here is the  gdisk information after I have set up the partition.

```

~ # gdisk /dev/sdc

GPT fdisk (gdisk) version 0.6.13

Partition table scan:

  MBR: protective

  BSD: not present

  APM: not present

  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p

Disk /dev/sdc: 3907029168 sectors, 1.8 TiB

Logical sector size: 512 bytes

Disk identifier (GUID): B0D18586-510A-4137-A201-BAE01F41C538

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 3907029134

Partitions will be aligned on 8-sector boundaries

Total free space is 6 sectors (3.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name

   1              40      3907029134   1.8 TiB     0700  Linux/Windows data

Command (? for help): 

```

So even with the drive aligned and the sector size correct, it still takes a week to format.  Anybody see what I'm missing?

----------

