[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SOLVED] Is squeeze compatible with WD20EARS and other 2TB drives?



#include <hallo.h>
* Klistvud [Sat, Dec 18 2010, 10:32:10PM]:

> First of all, let me thank all of you who responded. As promised, I
> am giving feedback to the list so that future purchasers of Western
> Digital WD EARS/EADS models and similar "Advanced Format" hard
> drives may benefit.

Err, what? EADS don't use AF, TTBOMK.

> The first thing of notice is that the Load_Cycle_Count of the drive
> heads increases every 8 seconds by default. As seen on the Internet,

That only refers to EARS. And it's wrong. Umount everything on that disk
and wait a while, no loading/unloading should stop.

What really happens is that the disk parks after 8 seconds when it's
IDLE. Which is ok when you either read or write stuff all the time or
don't do anything at all. It is not ok if you use them as system disks
where a few bytes are written every couple of seconds and certain
popular Linux filesystems like to flush (means: write out to disk) that
data every 10..15 seconds (just a bit more than 8 seconds) and so
causing the LCC growing quite quickly over time.

So DO NOT use an EARS drive as SYSTEM DISK.

> this may pose a problem in the long run, since these drives are
> "guaranteed" to sustain a limited number of such head parking
> cycles. The number given varies from 300.000 to 1.000.000, depending
> on where you look. The first thing I did was, therefore, launch a

There is no reason to put the word guaranteed into double-quotes or
refer to weird sites. Just have a look at the official data sheet and
the common definition of MTBF please.

> the WD proprietary utility wdidle3.exe, and the first link obtained
> by googling for "wdidle3.exe" did the trick:
> http://support.wdc.com/product/download.asp?groupid=609&sid=113
...
> thousand ticks overnight. Interestingly enough, the drive loaded and
> unloaded its heads at the amazing rate of twice per second even
...
> "disabled" to "every 300 seconds", which appears to be the maximum
> interval allowed. It would seem that, for the time being at least,
> this made the Load_Cycle_Count stay put at 22413. Whew!

Err, what? You play with a dangerous toy which was not designed for your
drive and you wonder that it's all messed up now?

> Now, the second issue: the hardware/logical sector alignment.
> Since it will affects real-world transfer speeds, let's first check
> out the theoretical speeds of this drive in this particular
> environment -- a 3GHz Pentium-IV motherboard with a humble
> integrated SATA controller (I think it's an early SATA-I
> generation).

My company had a lot of them. The SATA controllers were crap
performance-wise. I remember a colleague who got a shiny new OCZ SSD
drive which was supposed to deliver >>200MB/s but never got beyond
70MB/s on his system. The solution was a 15EUR PCIe controller card
which suddenly make it work as expected. 

> obelix# hdparm -tT /dev/sda

Err, what does this have to do with pro/contra of logical sector sizes?
Counter-example, WD20EARS on an AMD-78xx mainboard:

/dev/sdc:
 Timing cached reads:   8042 MB in  2.00 seconds = 4023.46 MB/sec
 Timing buffered disk reads: 360 MB in  3.02 seconds = 119.38 MB/sec

<ignored the rest of the posting, ENOTIME to read all of the voodoo>

Eduard.

-- 
Naja, Garbage Collector eben. Holt den Müll sogar vom Himmel.
       (Heise Trollforum über Java in der Flugzeugsteuerung)


Reply to: