So far I know that
cat /sys/block/<devicename>/queue/rotational will tell me whether my drive is a SSD or HDD. Is there something similar to find out if it uses SMR (Shingled Magnetic Recording)?
So far I know that
The only way to be sure is to benchmark the drive with enough random write access. "drive managed" SMR is supposed to be totally transparent to the host computer and sometimes manufacturers fail to mention SMR. However, the "transparent" is only about logical behavior, not performance (or latency).
I'd suggest following. Run
fio as follows (first
cd to directory on the disk to test because following will create benchmark test file in the current working directory):
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
This example will create 500 GB file filled with pseudorandom data and then select a random location within it and write 10 MB of pseudorandom data into the file. It then repeats selecting random location and writing for up to 1 hour or until 1.5 TB has been written. Watch the ETA lines that look something like this:
Jobs: 1 (f=1): [w(1)] [20.0% done] [0KB/40960KB/0KB /s] [0/4/0 iops] [eta 00m:28s]
The above command will emit a new ETA line every 5 seconds. Look at the current throughput and IOPS between the slashes (
4) above. For SMR drive you should get good values first (100MB+/s and 10+ IOPS) but as the test goes on and the internal cache of SMR drive fills up (usually around 20 GB) the performance will go all over the place. Sometimes it will be near the starting speed, sometimes it will be long periods of time around 0 MB/s and 0-1 IOPS. There should be never errors, though.
Be warned that SMR drives will get slower when used or benchmarked! Some drives support TRIM command and
fstrim may help to get the drive speed back to original.
Even without TRIM, a well done "drive managed" SMR will acquire its original speed once left idling powered for long enough. You might need to disable spinning down the disk (power management) if it goes to sleep before the internal cache has been fully flushed to SMR area. As an alternative, you can setup a look that writes a little bit every now and then. Even a single-liner such as
while true; do date >> timestamps.txt; sleep 5m; done
in a directory that's stored on the device to test will do just fine and you just have to end it with Ctrl+C when you're done. For the Seagate SMR drives I've used, full flush of the cache seems to take around half an hour. During this time the drive sounds like it's writing data even though nothing is written to drive by the computer. Unfortunately, I don't know any way to query the status of flushing from the drive. Either listen to drive sounds or simply wait for long enough.
Example: Seagate SMR drive seems to be happy to go sleep in the middle of SMR flush (probably to pretend to be fully transparent to the user) and continue flushing once waken up again in the future. This is transparent in the sense that no data corruption will happen even if power is cut. However, this results in very poor performance if you write big bursts every now and then and immediately put the drive to sleep afterwards (e.g. use such drive as as a backup drive that is immediately unmounted and disconnected after backup is logically complete). The next time you're taking another backup, the new backup is going to compete with SMR flush of previous backup and the performance will be very low. If you keep such drive always powered and write only up to 10 GB on one go, it will be as fast or faster than regular PMR HDD drive.
Modern versions of sg3_utils have a command sg_rep_zones, which will interrogate the drive and ask about its SMR configuration. You may have to build this manually if your distribution doesn't have a recent version.
That can tell you definitively if the drive is SMR.
However, even if the command reports
Report zones command not supported, that doesn't tell you for sure that the drive isn't SMR. Some SMR drives use "drive managed" SMR, which means that the drive handles everything magically and you supposedly don't need to worry about it. In this case, it wouldn't necessarily support the report zones command.
Another thing to try - see if the drive supports the "unmap" or "trim" commands - sg_unmap, also part of sg3_utils. A non-SMR drive is unlikely to support that command (but again, not all SMR drives will support it).