Contact

Mail: Please enable JavaScript.
Phone number within Sweden: Please enable JavaScript.
Phone number internationally: Please enable JavaScript.

Harddrive - determine if disk is using SMR

Debian 9.9

I needed to check whether two almost identical Western Digital Elements Portable 4TB disks were infected with the SMR (Shingled Magnetic Recording) technology. One had the 2016 design with the white logo and the other had the 2017 design with the engraved logo.

Both were equally thick, 2016 weighted 226g and the 2017 228g.


General disk identification

They had the same model number and also firmware but different serial numbers according to smartctl -a -d sat /dev/sd<X>. Note the addition of "-d sat" to get compatibility with the USB bridge.


Check by cache size

It can be possible to hint if the drive is SMR by the cache size. Small cache sizes like 32 MB or below is usually PMR, while 128 MB is usually SMR.

Result: These drives did not have cache size specified.


Check using sg3-utils - ask if the drive uses sg_rep_zones

The SCSI generic utilities can be used to ask the drive for special zones that SMR drives use.

sudo bash
apt install sg3-utils
sg_rep_zones /dev/sd<X>

Result: Unsupported command on both disks.


Check by exhausting the cache by writing on random locations

SMR can be determined by filling up the cache by doing random writes, as suggested here:
https://unix.stackexchange.com/questions/286432/how-to-determine-whether-hard-drive-uses-smr

I did however encounter some difficulties with this test. So first some prerequisites.

- Ensure you test on a Ext4 file system or other that is not in the way of the test, not on a extFAT file system. I first tested the disks using the latter using plain badblocks -sv /dev/sd<X> reading and it differed 10-20 MB/s between the disks.

- Ensure you format using mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sd<X> if formatting a new Ext4 file system, otherwise you will have to wait for the ext4lazyinit process to complete the file system creation in the background because it takes huge amounts of bandwidth.

- Ensure you add --fallocate=none, otherwise the test will hang for hours before starting.


Install the required software:
sudo bash
apt install fio

Find your partition, take note of the correct /dev/sd<X> location
blkid

Mount the partition and go there:
mkdir -p /mnt/<somewhere>
mount /dev/sd<X> /mnt/<somewhere>
cd /mnt/<somewhere>

Run the test:
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randwrite --size=500g --io_size=1500g --blocksize=10m --ioengine=libaio --iodepth=1 --direct=1 --numjobs=1 --runtime=3600 --group_reporting --fallocate=none

This output lines like this:
Jobs: 1 (f=1): [w(1)] [86.1% done] [0KB/110.0MB/0KB /s] [0/11/0 iops] [eta 08m:22s]

The important things are the percentage (86,1%), the speed (110 MB) and the IOPS (11).
At first the speeds will stay normal, and if it is an PMR drive it will continue so, but not if it is an SMR, then when the cache is exhausted it will begin to return low speeds, like 0-10-20-30-40-50 MB/s.

2017 kept outputting high speeds at high percentages:

Jobs: 1 (f=1): [w(1)] [63.5% done] [0KB/100.0MB/0KB /s] [0/10/0 iops] [eta 21m:53s]
Jobs: 1 (f=1): [w(1)] [63.7% done] [0KB/100.0MB/0KB /s] [0/10/0 iops] [eta 21m:48s]
Jobs: 1 (f=1): [w(1)] [63.8% done] [0KB/92160KB/0KB /s] [0/9/0 iops] [eta 21m:43s] 
Jobs: 1 (f=1): [w(1)] [63.9% done] [0KB/92160KB/0KB /s] [0/9/0 iops] [eta 21m:38s] 
Jobs: 1 (f=1): [w(1)] [64.1% done] [0KB/92160KB/0KB /s] [0/9/0 iops] [eta 21m:33s] 

It goes around 70-110 MB/s.

While the 2017 outputted high speeds until about 25% of the test switched to output low speeds:

Jobs: 1 (f=1): [w(1)] [64.6% done] [0KB/0KB/0KB /s] [0/0/0 iops] [eta 21m:13s]    
Jobs: 1 (f=1): [w(1)] [64.8% done] [0KB/0KB/0KB /s] [0/0/0 iops] [eta 21m:08s]    
Jobs: 1 (f=1): [w(1)] [64.9% done] [0KB/51200KB/0KB /s] [0/5/0 iops] [eta 21m:03s]
Jobs: 1 (f=1): [w(1)] [65.1% done] [0KB/10240KB/0KB /s] [0/1/0 iops] [eta 20m:58s]
Jobs: 1 (f=1): [w(1)] [65.2% done] [0KB/40960KB/0KB /s] [0/4/0 iops] [eta 20m:53s]

It goes around 0-50 MB/s.

In fact, the 2016 stayed above 70 and the 2017 stayed on 50 and below.

Result: It looked like the 2016 was PMR, while the 2017 was SMR.


Check the Gnome disk utility or HD Tune Benchmark graphs

Both the Gnome disk utility in Linux and the HD Tune in Windows has benchmark test that plots a graph which shows the read speed all over the disk. For a PMR this graph should begin high but fall down the closer it gets to 100%. SMR disks on the other hand has an SSD like graph that never falls the closer it gets to 100%.

To install and run the Gnome disk utility:
sudo bash
apt install gnome-disk-utility
gnome-disks &

Select a disk in the left panel, then in the top right is a hamburger menu. Click it and Performance test disk, then click the Start performance test button in the bottom left. Uncheck the perform write test checkbox, then run the test.

To run the HD Tune in Windows then download the free version, install it, then on the Benchmark click Start.

Both the 2016 and the 2017 disks generated non-PMR graphs. 2016 had speeds ranging 80-105 MB/s with some spikes and a spike at the end above 200 MB/s. 2017 outputted speeds around 220 MB/s. The access time jitter looked like an PMR disk for the 2016, it was all over the bottom of the graph, while for the 2017 it was just a line in the bottom.

Result: 2016 was not a pure PMR drive, 2017 was definitely an SMR drive.


Check for TRIM support

PMR disks do not have support for TRIM, while SSD:s and SMR disks may have it.

To check:
sudo bash
hdparm -I /dev/sd<X>|grep TRIM

If it reports it, then most likely it is an SMR drive.

Tested it on some smaller regular hard drives, nothing there. Tested it on an SSD, got two lines as expected.

Tested it on the 2016 and 2017, both resulted in the same two lines:
  *	Data Set Management TRIM supported (limit 255 blocks)
  *	Deterministic read data after TRIM

Result: Both 2016 and 2017 drives are SMR.


Summary of SMR detection methods

Check cache size - is it 128 MB or bigger, then it is SMR.
Check with sg3-utils - does it have zones, then it is SMR.
Check with fio - if it can't keep the write speed through the test, then it is SMR.
Check benchmark graphs - are they not falling in the end - the it is SMR.
Check for TRIM support - if it has it, then it is SMR.

I conclude that WD Elements Portable disks above 2 TB are SMR.

This is a personal note. Last updated: 2019-07-02 02:38:59.



LinkedIn
Klebe.se

Don't forget to pay my friend a visit too. Joakim