Review: Toshiba X300 6TB HDD
Reviewed by: J.Reynolds
Provided by: Toshiba
Firmware version: 0101
Welcome to Myce’s review of the Toshiba X300 6TB SATA Consumer HDD (hereafter referred to as the X300).
I normally review Enterprise Storage products, particularly Enterprise SSDs. As you will see below, Toshiba targets the X300 at professional workstation users; or to put it another way the heavy weight end of the consumer market’s requirements. I am a self-confessed storage freak and I have in excess of 10TB of SSD storage in my home PC, including an NVMe based SSD as my boot drive and SATA and SAS SSDs being run in RAID 0 configurations. These days I can’t imagine that I would ever recommend anyone uses an HDD as a boot drive but I was motivated to investigate what it is like to live with a state of the art, high performance, HDD for data storage in conjunction with an SSD based boot drive. So, with this in mind, I jumped at the opportunity to review the X300.
Please read on to see what I discovered with the X300.
Market Positioning and Specification
This is how Toshiba positions the X300 series of HDDs –
‘Tunnel Magneto-Resistive recording technology’ sounds good to me :o)
The X300 has a large 128MB disk buffer.
So what is a disk buffer, what is it used for, and is it good to have a large one?
Borrowing from Wikipedia –
A disk buffer is the embedded memory in an HDD acting as a buffer between the rest of the computer and the physical hard disk platter that is used for storage.
The disk buffer is controlled by the microcontroller in the hard disk drive.
When executing a read from the disk, the disk arm moves the read/write head to (or near) the correct track, and after some settling time the read head begins to pick up bits. Usually, the first and/or last sectors to be read are not the ones that have been requested by the operating system. The disk’s embedded computer typically saves these unrequested sectors in the disk buffer, in case the operating system requests them later.
ii) Speed matching
The speed of the disk’s I/O interface to the computer almost never matches the speed at which the bits are transferred to and from the hard disk platter. The disk buffer is used so that both the I/O interface and the disk read/write head can operate at full speed.
iii) Write acceleration
The disk’s embedded microcontroller may signal the main computer that a disk write is complete immediately after receiving the write data, before the data is actually written to the platter. This early signal allows the main computer to continue working even though the data has not actually been written yet. This can be somewhat dangerous, because if power is lost before the data is permanently fixed in the magnetic media, the data will be lost from the disk buffer, and the file system on the disk may be left in an inconsistent state.
iv) Command queuing
Newer SATA and most SCSI disks can accept multiple commands while any one command is in operation through "command queuing" (e.g. NCQ). These commands are stored by the disk’s embedded controller until they are completed. One benefit is that the commands can be re-ordered to be processed more efficiently, so that commands affecting the same area of a disk are grouped together. Should a read reference the data at the destination of a queued write, the to-be-written data will be returned.
NCQ is usually used in combination with enabled write buffering.
I imagine the X300 uses Write acceleration conservatively to minimize the risk of data loss.
So, the larger a disk buffer the more likely it is for read requests to be serviced from the buffer and for write requests to be optimized, however the relationship between likelihood and size is not at all linear and a disk buffer that is twice the size of another will, in real world uses, not see anything like twice the number of buffer hits.
Here is a picture of the X300 I tested –
Now let’s head to the next page, to look at the Testing Approach adopted in this review…..
NEW PAGE NEW PAGE NEW PAGE NEW PAGE