WD Caviar Black 2TB The 2TB Caviar Black is the second hard drive we have seen with a capacity of two terabytes. Glance back to our 2008 round-up of 1TB drives, which used three or four platters, and you can see that this is pretty much a doubling of areal density. Western Digital Caviar Black 2TB Western Digital's Caviar Black 2TB: covered up …
But who needs a 6Gbps link from a single drive only capable of actually reading data from the platters at around 100MBytes/sec?
The data interface speed is important only when transferring from cache -- i.e. from the 64MB cache on this particular drive. Correct me if I'm wrong.
But yes, the speed of this SATA II 2TB Black should plummet when the faster SATA 3 drives come onstream.
Just a quick note on TLER mentioned in the article. TLER is enabled in the enterprise versions and disabled in the Caviar Blacks.
Search for wdtler.zip and you can enable TLER so you can use your nice Caviar Black drives in a RAID array. Just done it on 5 1TB drives to go into a RAID 6 array on a 3Ware 9690SA-8i card.
I figured a RAID 6 is pretty secure against drive failure so could save £50 per drive and go for the standard drives rather than the enterprise ones.
The seagate might be cheaper and it might have a faster SATA connection (not that the drive is anywhere near the speed of SATA 3.0Gbps yet), but given seagates history on SATA firmware, I will stick with WD.
Also the drive is 2 TB. There is no such thing as 'formated capacity'. Just because windows uses power of 2 values and the harddisk uses power of 10 doesn't change anything.
The drive is 2 TB using power of 10, meaning 2000000000000 bytes. If you use the power of 2 definition (sometimes called TiB/GiB/etc unfortunately), then you get 1863GiB. Formating made no difference at all. Using different units made the difference.
Wrong. See:
- http://en.wikipedia.org/wiki/Hard_drive_capacity#Formatted_disk_overhead
- allocation unit size in the Windows disk format dialog.
Small allocation unit size -> more space used for metadata -> less space left for data -> smaller "formatted capacity"
Large allocation unit size -> files that are smaller than the allocation unit result in "wasted" space
I find it hard to believe that after decades of confusion between binary and decimal units, and even with the invention of special units to denote the binary type (e.g. the gibibyte/GiB), these mistakes are still appearing in reviews on specialist IT sites, and the confusion goes on.
Lennart is correct, of course. There is no "formatted capacity" here - filesystem overheads have been completely ignored. 2 TB is equal to 2000 GB, which is equal to 1863 GiB. You haven't lost any capactiy in the unit conversion, in exactly the same way that 2 inches isn't any shorter than 5 centimetres.
The real annoyance is that Windows and Mac OS X both insist on measuring in GiB, but use the "GB" suffix like they're just trying to confuse you. Hence the icon.
Generally wikipedia is not a place to go quoting. At the same time if you read what it did say, the filesystem overhead is less than 1% of the space. The difference between 2000GB and 1863GiB is a lot more than 1% (6.8% in this case). So it has nothing to do with the filesystem overhead or formatting or anything else, it is simply a matter of the HD makers and Microsoft using different units. Back when harddisks were measured in MB the difference was smaller and many people just claimed it was the overhead of the filesystem, even though it wasn't true then either. Now that we are starting to see rather large differences people actually start to really notice it. If you were to convince windows to show you the size in bytes instead of GiB then you would still have a capacity of the filesystem even with the filesystem overhead of very close to 2000000000000 bytes.
Leo Waldock writes, "This is thoroughly good news but of course it’s the combination of performance allied to the colossal 2TB capacity that catches the eye. That said, the formatted capacity is a ‘mere’ 1863GB."
Under OpenSolaris with ZFS - you will have more of the 2TB potential, if you are running with redundancy, since ZFS can perform the error correction for you, instead of being done on the disk drive... no sense in doing the error correction twice and losing the space twice when the loss of space in CRC's is redundant...
http://netmgt.blogspot.com/2009/10/zfs-next-word.html
I think the statement "You can buy 1TB 2.5" WD drive" is incorrect. 1TB 2.5" drive is still only a WD marketing dream and exists only as HTML page on Western Digital site. I cannot buy it neither from WD site nor from any other channel. Only 500GB drives on stock, same as half a year ago.
I think Western Digital managers developed and excellent way to get bonuses. If the product is not ready on time - just place nice description on web page, and you can put a plus sign that it is "released". When, in reality, half a year will pass until customers are able to buy the product.
I suggest to clearly mark all the pages where product is not yet on sale. I.e.: "Future product. Estimated availability date - December 2009."
No you can't. CRC checks in the filesystem are a nice feature but they are only checks, they are not error correcting at all just error detection, they are nothing in comparison to the ECC the disk performs. And you (fortunately) can not disable the ECC of the disk. Solaris gets the same 2000000000000 bytes as windows does. What units it chooses to use to display them is a different issue.
> CRC checks in the filesystem are a nice feature but they are only checks, they are not error correcting at all just error detection
You are wrong. ZFS detects *and corrects* errors. The 256 bit block checksums are compared with the data read back during a file read or scrub operation, and if an error is detected it is corrected using parity data in redundant vdevs.
If you don't believe this, try reading the ZFS tech info available -- look under 'self-healing'.
No I am right. The CRC did not correct, it only detected. It then used RAID to get more data (which hopyfully is correct unlike what the RAID originally returned by only reading the primary storage location rather than the parity data as well), and if the new data is correct when the checksum is used, then it is happy. BTRFS does the same thing. In both cases it is still much preferable to have the disk do ECC first to avoid having to go through all that work. The ZFS developers would call you an idiot if you suggested to them that the disk should stop doing ECC.
CRC (checksum) detects errors. ECC or parity data (combined with the filesystem checksum) takes care of correcting it.
"The real annoyance is that Windows and Mac OS X both insist on measuring in GiB, but use the "GB" suffix like they're just trying to confuse you. Hence the icon."
Yeah, both major operating systems are trying to confuse you, not the HDD manufacturers. *sigh*.
Windows and Mac OS X have been *correctly* reporting in "MB" and "GB" since before MiB and GiB were even invented.
For reference:
MB = megabyte (2^20 bytes)
GB = gigabyte (2^30 bytes)
MiB = Men in Black, a movie starring the Fresh Prince
GiB = Girls in Black, a little known blaxploitation sequel
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
