WD Black2

The WD Black2 is a dual hybrid drive solution from Western Digital with a 120GB SSD coupled with a 1TB traditional rotating media on a single SATA device. Factory configuration of the drive allows a SATA host to only recognize the 120GB capacity per the SSD.

The 1TB media is "unlocked" via a Windows or MacOS installer tool available from Western Digital's product website. Although the WD Black2 seems to be a device that does not work with Linux, the installer simply "unlocks" the upper 1TB and partitions the drive in 2 parts to distinguish between storage on the SSD and storage on the HDD. Once the HDD storage is unlocked, it may be used on any operating system. This article will explain how to use this drive under Gentoo Linux.

Unlocking the 1TB HDD
Unfortunately, physical access to a machine running Microsoft Windows is required for this step. If your drive already shows capacity of 1120GB in the BIOS, you may skip this section.


 * 1) Note that you should better check the drive sector count before enabling HDD, for example by connecting it to a Linux machine and checking dmesg (it will say something like "... xxxxxxxxx 512-byte sectors"). You will use this number as your SSD-HDD partition boundary. In my case it was 234441648 sectors.
 * 2) Connect the WD Black2 to a system with a free SATA port (impossible through USB cables, even those that support SMART i.e. scsi-to-ata translation) and boot into Microsoft Windows
 * 3) Use a system that is already running Microsoft Windows and connect drive as a slave
 * 4) OR install Microsoft Windows onto the drive from scratch.
 * 5) Run the WD Black2 installer which can be downloaded from the product page
 * 6) Confirm that you are able to see 1120GB capacity in the BIOS

In fact WD utility only sends several VSC (Vendor-Specific Commands) to the drive. If you're familiar with disassembly you can try to discover these commands by looking into the official MacOS utility: it contains a small and simple command-line utility called xlba (WD_Black2_Configuration_Utility/WD Black2 Dual Drive Initialize.app/Contents/Resources/xlba in the package) - it's written in C++ and it's relatively easy to disassemble.

Partitioning the drive
Once the drive is unlocked, it may technically be used on any system or configuration as long as read/write commands do not cross over from the SSD to the HDD. This is why the tool available from Western Digital partitions the drive automatically, to protect itself from receiving a read/write command that would cross the boundary. NOTE VitaliyFilippov (talk) 09:51, 11 July 2015 (UTC): Although it's of course stupid to mix SSD and HDD in one partition, I didn't experience any issues when reading/writing across the boundary.

Use the SSD sector count from the previous step as the boundary between your SSD and HDD partitions. In my case the exact number of 512-byte SSD sectors was 234441648 and total drive size was 2187966778 sectors. If your numbers don't differ, just make sure your SSD partitions end with sector number 234441647, and that your HDD partitions begin with 234441648.

Windows partitioning scheme
The partitioning scheme after running the installer may look something like this if setup as an MBR drive

It seems the installer tool makes a boundary between partitions 2 (ending with 114472MiB) and 3 (starting with 114474MiB). It's not required in any way - the HDD partition may start exactly the next sector after the last SSD sector, but if you're getting some unexpected issue (unresponsive drive or so) you can also add some free space between SSD and HDD partitions. For example with a VERY big (> 16 GB) boundary the partitioning scheme may look like the following:

Here partitions 1 and 2 are located on the SSD while partitions 3-6 are on the HDD. The root file system and boot partitions are stored on the SSD for fast data read speeds. /var/tmp is a location that will see many writes on Gentoo due to compiling which can reduce the life of an SSD so it is stored on the HDD. Similarly, /usr/portage sees writes on emerge --sync commands. Naturally /home and swap are stored on the HDD as they consist of data that is accessed slowly.

Random access
'fio' (Flexible I/O tester) may be used for getting much more correct benchmark results than using quick&dirty methods like 'hdparm' or 'dd'.

My method is to run the following command with  equal to "4096-16384" (4k-16k random read/write) and "1048576" (1M random read/write) on SSD and HDD partitions:

fio -name iops -rw=randrw -numjobs 8 -filesize=512m -bs= -runtime=20 -iodepth 64 -directory  -direct 1

Testing results:


 * WD Black2 HDD:
 * 4-16 Kb: 0.46/1.57 Mb/s (read/write)
 * 1 Mb: 37/32 Mb/s
 * WD Black2 SSD:
 * 4-16 Kb: 13/43 Mb/s
 * 1 Mb: 64/51 Mb/s
 * For reference, normal 2.5" SATA SSD Plextor PX-128M3:
 * 4-16 кб: 23/78 Mb/s
 * 1 мб: 128/114 Mb/s

Which means WD Black2's SSD is ~2x times slower than separate 2.5" SSD (probably because it consists from only 2 flash memory chips), but it's still SSD and it's still much faster than HDD part during random access.

Sequential read
It's easy to check sequential read speed by using 'dd' utility:

dd if=/dev/sda1 of=/dev/null bs=1048576 count=1000 dd if=/dev/sda2 of=/dev/null bs=1048576 count=1000 dd if=/dev/sda2 of=/dev/null bs=1048576 count=1000 skip=950000
 * 1) test SSD part
 * 1) test HDD beginning
 * 1) test HDD end

Here I assume /dev/sda1 is the whole SSD (sectors 0 to 234441647), and /dev/sda2 is the whole HDD (sectors 234441648 to 2187966777).

By running these tests, I've got the following results:
 * WD Black2 SSD: seq.read speed 133 Mb/s
 * WD Black2 HDD beginning: seq.read speed 110 Mb/s
 * WD Black2 HDD end: seq.read speed 57 Mb/s

Which again tells us that WD Black2 SSD is 2x times slower than my Plextor PX-128M3 (its seq.read speed is about 240-250 Mb/s).

Note that it's INCORRECT to check read/write speed by creating a temporary file in the target FS, unless you're using the O_DIRECT flag, because you'll be benchmarking Linux page cache and not the drive itself.

hdparm
A very quick and dirty method to benchmark the drive can be used with hdparm. Following the partitioning scheme above, the SSD and HDD is accessed as followed:


 * /dev/sda1 - SSD
 * /dev/sda2 - SSD
 * /dev/sda3 - HDD
 * /dev/sda4 - HDD
 * /dev/sda5 - HDD
 * /dev/sda6 - HDD

With that in mind, you can pass partitions to hdparm to focus the I/O.

dd
The utility dd can be used to test reads/writes. Since /root is part of the SSD, I will use it as the directory for testing.

Test writes:

Clear the buffer cache:

Test reads:

Test cached reads by running it again:

Delete tempfile: