Very Slow Performance of Western Digital Elements 5TB SMR HDD


Would you like a taste of HDD performance circa 1993? My Seagate 20 MB Internal PATA drive was the speed champ with transfer speeds topping out at about 2 – 3 MB / sec. Look no further than buying a Western Digital Portable USB drive that uses SMR technology.

This month I purchased a Western Digital Elements 5 TB External Drive that connects to a computer using USB 3.0 and is bus powered. Prior to this purchase, I had a Western Digital Passport 4 TB drive that I was using for personal backup. That drive was delivering CrystalDiskMark performance of 100 – 125 MB / sec sequential Read and Write performance and even when Reading / Writing to encrypted partitions, this performance was in the range of 40 – 80 MB / sec.

So I had no hesitation in buying the new 5 TB model for a Client’s backup task. I fully expected this drive to meet or exceed the performance of it’s 4 year old brethren.

Running CrystalDiskMark on this drive reports usual performance number, more or less identical to the older 4TB drive. Some of these numbers are unbelievable, particularly the 300+ MB / sec reported for 16 MB file Read tests.

Drive Performance of 5TB (New) and 4TB (Old) SMR HDDs by Western Digital, as reported by CrystalDiskMark

Armed with this data, I set about transferring about 3.5 TB data from the client’s collection of backup HDDs to the 5TB drive in an attempt to consolidate the data.

The files being transferred are an eclectic mix of small to very large files ranging from 20 KB to 10 GB. The number of files is over 1 million, so its a great test case of this drive’s real world performance. The files are being transferred to an encrypted partition. This means that all sectors of the HDD are filled with random data in advance and writing files to the disk changes data in more sectors than strictly the amount of data being transferred.

Issues Noticed:

  1. Initial Write Speeds top out at about 10 MB / sec, which is shockingly slow by a factor of 10x. Disk Utilization shoots to 100% immediately and stays there for the rest of the read / write session.
  2. Within 10 minutes of transferring hundreds of files that are between 1 – 5 MB in size, the Write Speed drops to about 3 MB / sec.
  3. Within 30 minutes of transferring thousands of files that are between 1 – 5 MB in size, the Write Speed drops to about 1 – 1.5 MB / sec.
  4. Within an hour of beginning to transfer a few large files ranging from 50 – 250 MB in size, the Write Speed drops to about 300 KB / sec (0.3 MB / sec).
  5. Interrupting the transfer takes a few minutes while the disk finishes emptying some non-interruptible buffer. After interruption is complete, the interrupted file can be discovered to be incomplete; necessitating a manual delete.
  6. After interruption, Disk continues to show Data Writes at about 2 MB / sec and Disk Utilization at 100% with Average Response Time in the 400 – 600 ms range. Sometimes it takes well over 20 minutes for disk-writes to become zero, sometimes it takes well over an hour for disk-writes to become zero.
Poor Write Performance on WD Elements 5TB SMR HDD. The Disk Active time reaches and stays at 100%, Average Response Time increases to up-to 600 ms, Write-Speeds range from 300 KB/sec to 3 MB / sec, about 100x slower than claimed by CrystalDiskMark. Note that Host PC infrastructure is largely idle.

Searching for information about SMR drives, I found two excellent resources
1) https://horizontechnology.com/news/shingled-magnetic-recording-smr-data-center-capacity/
2) https://www.reichelt.com/magazin/en/guide/smr-cmr-which-hard-drive-is-best-for-which-purpose/

The information I gleaned, results in the following conclusions and something that Western Digital engineers failed to foresee and cater for, in their design.

  • Unlike Conventional Magnetic Recording (CMR) drives, where each track has distinct physical space, Shingled Magnetic Recording (SMR) drives have overlapping tracks to increase track density, thus increasing data density in the same physical space.
  • When writing data on a track, the overlap results in data of adjacent tracks getting destroyed. Hence, SMR drives must first read all overlapping tracks into internal memory, modify the data to indicate the changed bytes, then write all the overlapping tracks back to the disk.
  • Hypothetically, assuming that
    • the disk is structured as 8 overlapping tracks followed by a single track-gap; each sector stores 512 bytes, and the disk is formatted as NTFS default which results in 8 sectors per cluster (4096 bytes)
    • it means that even if a single byte has to be changed, 32768 bytes (1 cluster (4KB) * 8 tracks = 32 KB) have to be read-modified-written back to the disk. Physical disk read/writes are always very slow due to the mechanical moving parts.
    • If 35 Trillion bytes (3.5 TB) have to be altered, this will result in Gazillion bytes being processed.
  • Reading the data has minimum penalty since the read-heads are much finer in size and can differentiate between the overlapping tracks.
Disk Activity remains at 100% for a very very long time after Disk Writes have been aborted / completed. The disk does not report Read/Write activities to the OS, but behind the scenes, the HDD Controller is busy transferring Cached data from the CMR section of the HDD to the SMR section or re-writing the tracks.

Based on the amount of data to be written, average performance numbers, I calculated the following durations for the data transfer:

  • At the top speed of 10 MB/sec, it would take 6117 minutes or about 4.24 days
  • At the more likely average of 1.5 MB/sec, it would take 40,778 minutes or about 28 days
  • God forbid, if the transfers actually average out to 300 KB/sec (which I actually noticed happening), it would take 141 days!

Clearly, it appears that this product made by Western Digital is totally unfit for real world use. CrystalDiskMark results are not at all representative of the real-world complications associated with this drive. Further, if drives using these technologies are used in RAID arrays, data-transfers from the array will probably come to a halt while the drives do their house-keeping internally.

Experiment Setup:

  • All source drives are a mix of Seagate, Western Digital, Toshiba 2.5″ External bus-powered USB drives connected to USB 3.0 interface. The drives have been tested to transfer data at 40 – 100 MB / sec to the Internal 240 GB Kioxia SSD of a Lenovo Laptop featuring 7th Gen Core-i7 CPU, 16 GB DDR4 RAM on updated Windows 10 OS.
    Some tests were performed on a Acer Laptop featuring 8th Gen Core-i7 Hexacore CPU, 32 GB DDR4 RAM 1 TB Internal HDD accelerated by Intel Optane 16 GB Memory. The source drive was connected to a USB 2.0 port with Read test to RAM and Internal HDD clocking at 30 – 40 MB / sec, while the target drive was connected to a USB 3.0 port.
  • The target drive is also connected to a USB 3.0 port on the laptop and the partition has been encrypted using VeraCrypt to provide basic data security against drive-theft.
  • Using other VeraCrypt drives on this computer has shown consistent data transfer (Read & Write) ranging from 25 MB / sec – 45 MB / sec. The performance depends on file-size as usual, with larger files delivering higher throughput. Throughout these tests, the CPU utilization does not exceed 15% and Windows OS uses maximum possible unallocated RAM as Cache memory to copy the files from the Source drive into memory and then write to the target drive.
  • The files being transferred are an eclectic mix of small to very large files ranging from 20 KB to 10 GB. The number of files is over 1 million, so its a great test case of this drive’s real world performance. The files are being transferred to an encrypted partition. This means that all sectors of the HDD are filled with random data and writing files to the disk changes data in more sectors that strictly the amount of data being transferred.
1. Write-Performance of disk with real-world files ranging from 1 MB – 20 MB in size is extremely slow and rated at about Class-4 performance from USB Pen Drives.
2. After the initial test of writing about 34 GB, the disk went into some sort of calibration mode and the next job could not start even after waiting 4 hours.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.