Final Word on the Samsung HD204UI

[KYThrill]

Well, I guess there are two parts to this analysis...

The part where I'm a little disappointed in the drives performance and the other part where I eat crow... 

Anyway, I got my Samsung in today and have been playing with it most of the night (for way, way too long).

I think we have enough info to put its suitability for unRAID to bed.  Here is what I did.  On my benchmark, I tested the HD204UI with an aligned partition (2048) and with an unaligned partition (63) for a 4k drive.

I ran HDTune and Crystal Disk Mark each time.

The HDTune results are almost identical whether aligned or unaligned.  Either way it was 103.3 MB/sec average transfer.

However, CrystalDiskMark brought out the difference.  Sequential read/write was almost the same aligned vs unaligned.

However, the 512k and 4k random tests brought out the difference.  The write speeds were roughly half when misaligned.  This was similar to what was observed with the EARS drives.

And to compare the two (EARS vs HD204UI), I would have to say that I think the EARS drives come out on top.  Compared to my benchmark on the EARS, the HD204UI had a sequential transfer rate about 10MB/s faster.  However, the HD204UI is much slower at the random data.  Even when aligned, the 204 was about 20 MB/s slower on 512k writes, and about 10 MB/s slower on reads.  The 4k transfer on the EARS drive is about 5% faster vs the HD204UI.  Overall, I would say the EARS is a slightly faster drive.  For the same money, I would rather have the EARS (strictly from an aligned perspective).

So for unRAID, where sector 63 will be forced, you may be able to use the drive, but  it depends...

As a parity drive, no way.
For small files, scratch drive, etc, probably not.
To store large DVD iso's, you could probably get away with it.

It is still something of a mystery to me how preclears could be so fast on the HD204UI unaligned and very slow on an unaligned EARS.  One would think both should be equally as slow.  But this doesn't appear to be the case.

And I haven't had a chance to play with the Samsung jumpers yet.  I doubt they have a jumper like the WD's did, but who knows.  I will try it out tomorrow on an unaligned drive to see what happens.

[KYThrill]

And the mis-aligned data...

[Chris Pollard]

Seems 4k sectors are the new standard anyway so unraid will need to be fixed at some point.

[Blofeld]

interesting thread...thanks for your testing. I hope this leads us all somewhere, and that it will be a non-issue at some point.

[bubbaQ]

It is still something of a mystery to me how preclears could be so fast on the HD204UI unaligned and very slow on an unaligned EARS.  One would think both should be equally as slow.

There are several possible explanations for this.

The simplest is that the HD204UI is using buffers in write-back mode, or a less aggressive write-through mode.  Or the buffers are just tuned differently and preclear hits a sweetspot on the HD204UI (think of the old concept of interleave when doing low-level formatting... different sweetspot for different drives and controllers).

[madpoet]

Sooo... This is bad . Guess I shouldn't have bought 8 of them.  They are just for data drives but it seems like I'm going to have a lot of problems.

[BRiT]

madpoet, the real bad part about your drive purchase isn't the make or model of them, but the fact that you purchased them all at or around the same time. That's generally considered a big no-no, something that shouldn't be done. If there happens to be a bad batch, then the odds of two drives or even all your drives failing at the same time are significantly higher. They will also age at approximately the same rate given the same usage patterns and need to be replaced around the same time too.

Like KYThrill says, if you're using it to store DVDs or BluRays or large files, you could probably get away with it.

It's clear that it would be beneficial to the community if unRAID implemented alignment handling (able to use sector 63 or 64 partition start positions) sooner rather than later.

I commend KYThrill for taking the initiative and putting the drives through various benchmarks and test scenarios. The results will benefit the community. Lets hope there's some jumper or even firmware setting that can be enabled on the drives to alleviate the performance issues.

 It's a bit of a shame there's so many issues with the various drives. In a consumer market, it really should be as simple as selecting the brand you feel most comfortable with and not having to worry about different sorts of issues. If I had to pickup a new drive today, I'm not certain which I would go with.

[madpoet]

But they were so cheap . I get what you mean, I will certainly pre clear them all and hope that flushes out any immediate problems.

[KYThrill]

I was bold and tried every possible jumper configuration, both vertical and horizonal.  One and two jumpers installed.  The drive would only even power up in one of those configurations, and I couldn't immediately tell a difference.  I thought maybe it locked in SATA150, but according to Crystal Disk, it was still SATA300.  So I don't know what that jumper was doing.  Transfer speeds were still 1/2 when aligned to Sector 63.

Which looking at Samsung's history, they usually fix this type of thing through firmware.  For several of their past models, it is a firmware change that is required to force SATA150 (the claim it should auto sense with default firmware, but doesn't always).  I logged a complaint with Samsung but haven't heard anything back yet.  I just stated that the drive was not fully compatible with XP, because aligned with Sector 63, as XP's default format, drive write speeds are 1/2.  I then complained that it wasn't printed on the drive label like it is with the WD advance format drives.

Maybe if more people contact their support department, it might speed up getting a firmware patch.

[reggie14]

So, I have four Samsung HD203WI 2TB drives which I've been happy with.  But pretty soon I'm going to need to add a drive or two.  I was planning on getting another one or two HD203WI drives, but they're getting harder to come by.  If I understand correctly, it will be almost impossible to get 512-byte sector drives after January 1st.  On top of that, I guess there's some sort of 2TB drive limit that we're running into too.  So, I'm a little nervous moving forward.

What really concerns me is what happens if one my 2TB HD203WI drives fail in a year.  Will I run into a problem trying to replace it with an Advanced Format drive?  Forgive my ignorance, but its my understanding that the parity drive *has* to just as large all of the data drives, and a replacement data drive *has* to be just as large as the drive it is replacing.  So, given the 2TB limit (not to mention the lack of 3TB drives), that basically means any replacement parity/data drive has to be exactly the same size as my current 2TB HD203WI drives, right?

So, do the advanced format drives create any problems?  Will a HD204UI drive look the same size as a HD203WI drive?  Will a 2TB Western Digital EARS drive look the same size?  What if the 2TB EARS drive has the jumper set (which apparently just throws away one of the sectors, I think)?

[Rajahal]

You won't have any trouble replacing a dead drive after January 1st, however, you may have to buy a different brand.  In my opinion, the WD Green EARS drives are the best option at the moment, just remember that jumper.  Install the jumper as soon as you remove the drive from the packaging, then you won't have to think about it again.  All 2 TB drives will appear to be the same size to unRAID (barring any HPA issues, but that's a separate matter that only affects people with older Gigabyte motherboards).

[PeterB]

I have three 1GB drives in my system ... a WD EADS, a WD EARS (with jumper installed) and a Samsung HD103.  They all report exactly the same size : 976,762,552

[boof]

In my opinion, the WD Green EARS drives are the best option at the moment, just remember that jumper. 

They aren't perfect, there are reports of excessive read head parking issues under certain linux kernels (inc the one unraid uses..) which a friend mentioned to me a couple of weeks ago :

http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=5357&p_created=1266947046&p_sid=Os7DQL2k&p_accessibility=0&p_redirect=&p_srch=1&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9NTEsNTEmcF9wcm9kcz0yMjcsMjk0JnBfY2F0cz0xMzAmcF9wdj0yLjI5NCZwX2N2PTEuMTMwJnBfcGFnZT0x&p_li=&p_topview=1

http://forums.anandtech.com/showthread.php?t=2085685

From my own unraid box :

Model Number:       WDC WD20EARS-00S8B1                     
Firmware Revision:  80.00A80

9 Power_On_Hours          0x0032   094   094   000    Old_age   Always       -       4421
193 Load_Cycle_Count        0x0032   196   196   000    Old_age   Always       -       14963


Only the WD disks in my box count the load cycle count (or at least give a specific smart attribute for it). Another different model WD to highlight the difference :


Model Number:       WDC WD5000AAKS-00TMA0                   
Firmware Revision:  12.01C01
9 Power_On_Hours          0x0032   073   073   000    Old_age   Always       -       19991
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       85

No idea if this is actually a problem and likely to cause premature failure of the drives. It doesn't bother me much and there may be a fix / workaround I'm not aware of.

But in the interests of being fully informed when choosing a 2TB disk it might be enough to push you towards another model / brand for now.

[madpoet]

So what 2TB drives SHOULD we buy

[BRiT]

That's difficult to say, but ...
It seems the Hitachi model is the current favorite.
If you can get past the forced firmware update the Seagate LPs (5900 RPMs) seem to be decent.

My original WD EADS are doing very well in my unRAID array, none of the LCC issues at all, but there's a chance the new EADS come with advanced format now, so I can't outright recommend them either.

  9 Power_On_Hours          0x0032   086   086   000    Old_age   Always       -       10383
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       1095

  9 Power_On_Hours          0x0032   086   086   000    Old_age   Always       -       10284
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       800

  9 Power_On_Hours          0x0032   086   086   000    Old_age   Always       -       10368
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       865