Which 4 TB drive should I buy?


Recommended Posts

It's true, unRAID 5.0 beta-14, and possibly earlier versions as well, is/are compatible with the newly released 4 TB hard drives! There are scant few options at the moment, but we at Greenleaf had the opportunity to test and review the offering by Hitachi: the Hitachi H3IK40003254SW 4TB 5400 RPM 32MB Cache SATA 6.0Gb/s 3.5" Internal Hard Drive. In short, we love the drive and highly recommend it! Read the full Greenleaf review for full compatibility and performance test results.

Link to comment
  • Replies 131
  • Created
  • Last Reply

Top Posters In This Topic

  • 3 weeks later...
  • 3 weeks later...
  • 4 weeks later...
  • 4 weeks later...

Raj, I have two of these drives I'm about to preclear. However, I'm curious if you used the -A option in your preclear, to force the partition to start on sector 64 instead of 63. On my 3TB Hitachis I found they still needed to start on 63, and were using 512B alignment.

Link to comment

Raj, I have two of these drives I'm about to preclear. However, I'm curious if you used the -A option in your preclear, to force the partition to start on sector 64 instead of 63. On my 3TB Hitachis I found they still needed to start on 63, and were using 512B alignment.

 

Yes, I used the -A option to preclear (actually, I just had the MBR: 4k aligned setting enabled in unRAID, so I didn't have to add any modifier when starting preclear). You should force the preclear start on sector 64 for every single drive except for an Advanced Format drive that has been modified to start on sector 64 already (such as the WD EARS drives with a jumper installed on pins 7-8). I'm not sure what you mean by your 3 TB Hitachis 'needing' sector 63, I don't believe that is correct. Even a 512B aligned drive will still perform optimally when using 4k alignment starting on sector 64, since 512B is an even multiple of 4k.

Link to comment

Well, basically when I precleared the 3TB drives with -A, they stuttered when running playback. Reclearing them without -A restored their throughput. It's likely this was more a kernel issue within the unRAID beta version I was running at the time, but all of mine currently start on 63 without issue. Thanks for clarifying. :)  In future hard drive reviews, it might be helpful to indicate the full preclear command you issued, so that the results can be repeated easier.

Link to comment

Interesting. I've definitely used 3 TB hitachi green drives that were 4k aligned with no performance issues that I've seen. I'm not sure about the 7200 RPM drives, is that what you are using?

 

Nope... 5K3000 drives. It was unusual to me too, but there was definitely a noticeable change in throughput. I chalked it up to improper sector alignment, but if you didn't have issues, I have to wonder if it was the 5.0 beta version I was using at the time. With all the linux kernel changes in the beta series, it's difficult to trace, and really not worth the effort at this point. At any rate, thank you for the quick response. :)

Link to comment

Raj, I have two of these drives I'm about to preclear. However, I'm curious if you used the -A option in your preclear, to force the partition to start on sector 64 instead of 63. On my 3TB Hitachis I found they still needed to start on 63, and were using 512B alignment.

NO disk, regardless of manufacturer, will ever use an MBR style partition.  They will ALL use a GPT partition.

 

When a GPT partition is used, a protective "partition" is defined in the MBR to appease older utilities that only read the MBR and have no concept of disks larger than 2.2TB.

 

Therefore, on any disk over 2.2TB the preclear script will completely ignore the "-a" or "-A" option, or any "default" setting in the unRAID configuration for disks.   

 

Your 3TB Hitachi drives MUST have a GPT partition in unRAID.  If used in unRAID, they will have the protective partition defined that allocates the entire drive that was possible under the MBR partitioning scheme. 

 

That partition will be defined as starting on sector 1.   

 

Give it a try, type

fdisk -lu /dev/sdX

and see what it tells you. 

 

It could still be using a GPT partition to access the entire disk, but the "protective" partition would not be defined as expected.  If it is not re-defined by unRAID when a parity disk is not present, it is a bug in unRAID.    If it says the partition starts on sector 63, or 64, something is wrong with how unRAID is handling the protective partition.

 

As far as the pre-clear goes, it reads and writes the entire drive regardless of how you invoke it, so you don't have to re-do anything, other than if you expect the drive to be recognized as a valid pre-cleared drive to be added to an existing parity protected array.

Link to comment
  • 1 month later...
  • 4 weeks later...

Hi folks, just want to share my successful (I hope) story:

Using latest rc6 test build:

I have 3 "Hitachi Deskstar 4TB 7200 rpm"  installed in simple old box (Intel duo 2.2 Mhz, 2 GB Ram, 4 built-in SATA-2, 300 W PS). Before starting array, unRAID recognized 2 data disk as green OK status, but parity disk was red DISK_INVALID. Starting preclear shows that process will start from sector 63 and it will NOT be 4K... so I did NOT preclear from console. Start reading forum and getting even more confused what to do, so I just press "start" and left it overnight running. The process of parity sync (or whatever) take about 410 minutes total (I was thinking about days of waiting) and syslog shows some errors, like unable to mount disk and invalid fs. At the morning all disk appear in green status OK, no sync errors. I've stopped and restart array - everything is green and no errors in the log. Just to be sure, I've started "Parity check" process (with checked "Correct errors" check-box) and so far everything is looks good (170 MB/s, 370 minutes to complete). SO if any of you see something wrong is going on, let me know, please. I assume that system correct all errors during night process and all zeros are written correctly on all drives.  BTW: temperature on drives 44-45 C. Is this normal ?

Update:

"Parity check" process has finished. No errors. All disks - green status. 8 TB was checked for less than 6 hours. I've rebuild the box, closing all "default" ventilation openings on sides, front, back. Cut an opening in front for HDD only (for straight air flow), added one more controllable 80 mm fan on back. Set it for quiet spinning. Start array. Disk temperature now is 33-34 C on idle.

Link to comment
  • 4 months later...
  • 1 month later...
  • 4 months later...

Hi

 

the test results shown on this drive, as it's a single drive.

 

what if you want to populate your full system (20 drives) with this drive, what will be the read and write rates?

 

The read and write rates will be essentially the same with 2 or 20 drives.    When you're writing, only 2 drives are involved in the write -- parity and the actual drive you're writing to.  When you're reading, you're only reading from one drive, so the read rate is dependent on that drive's speed.

 

The exceptions are:  (a)  If the system is running at risk, whereby the data for a failed drive has to be reconstructed by reading ALL of the other drives plus parity ... in this case both reads and writes are obviously slower.  and  (b)  if there are a lot of simultaneous writes, which will "thrash" the parity drive while it updates parity for all of the drives being written to.

 

Link to comment

Hi

 

the test results shown on this drive, as it's a single drive.

 

what if you want to populate your full system (20 drives) with this drive, what will be the read and write rates?

 

The read and write rates will be essentially the same with 2 or 20 drives.    When you're writing, only 2 drives are involved in the write -- parity and the actual drive you're writing to.  When you're reading, you're only reading from one drive, so the read rate is dependent on that drive's speed.

 

The exceptions are:  (a)  If the system is running at risk, whereby the data for a failed drive has to be reconstructed by reading ALL of the other drives plus parity ... in this case both reads and writes are obviously slower.  and  (b)  if there are a lot of simultaneous writes, which will "thrash" the parity drive while it updates parity for all of the drives being written to.

You do realize your replying to a post from May of 2012 don't you?
Link to comment

You do realize your replying to a post from May of 2012 don't you?

 

As a candidate in one of last year's presidential debates rather famously said, "Whoops !!"  :)

 

Obviously I didn't notice the date ... the thread just popped up in the list of new posts because of the posting from yesterday.

 

Link to comment

You do realize your replying to a post from May of 2012 don't you?

 

As a candidate in one of last year's presidential debates rather famously said, "Whoops !!"  :)

 

Obviously I didn't notice the date ... the thread just popped up in the list of new posts because of the posting from yesterday.

That's what I figured. ;D
Link to comment
  • 1 month later...
  • JorgeB unpinned this topic

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.