I was examining a new hard drive when I noticed something peculiar:
It's a 1 TB HDD from Seagate, and CrystalDiskInfo shows that it supports TRIM! AFAIK, TRIM is some SSD feature that allows the controller to recycle and erased unused pages for better write performance in the future. But HDD just overwrites the old data and doesn't need any "deletion notify".
What does this TRIM support on an HDD indicate?
This probably means that your HDD is an SMR drive. Since SMR drives work differently, a TRIM operation is needed to improve performance over time.
WD's support page provides a good explanation for this:
TRIM/UNMAP is supported for external hard drives with SMR (Shingled Magnetic Recording) drive inside, like SSDs, for dataset management and to improve SMR performance over time. One of the shingled write benefits is that all physical sectors are written sequentially in a direction radially and are only rewritten after a wrap-around. Rewriting a previously written LBA (Logical Block Addressing) will cause the previous write to be marked invalid and the LBA will be written to the next sequential physical sector. The TRIM/UNMAP enables the OS to inform the drive which blocks are no longer considered to be in use and can be reclaimed internally by the HDD to ensure that later write operations perform at full speed.
The documentation for this drive from Seagate lists the SATA commands it supports, and does not include TRIM in that list.
Said documentation based on the make and model reported by the displayed screenshot:
Today i was suprised when a new ST2000DM008 arrived, and it claims support for TRIM. I noticed this after lvcreate was trimming the free space.
SMART reports the trim support. Kinda hints that both my and yours are SMR drives.
Trim on SMR HDDs works similarly but also very differently than for SSDs.
On both technologies the disk is divided into large areas which are written at once, and in both cases the TRIM helps the firmware to make more efficient writes - but once you get into the details they work very differently indeed.
SSDs have cells containing many sectors and can read and write each sector individually, however you can only write to an erased sectors - when you want to overwrite a used sector, then you need to:
This need to read an entire cell just to write one sector is called "write amplification". And there is a mapping that allows cells to be mapped to LBA ranges to make this work.
When you delete files, the TRIM command tells the SSD firmware that the relevant sectors are no longer in use, and the firmware can then:
SMR HDDs are different in that you can read sectors individually, but you can only write the entire cell. So, to write a single sector, if a cell is used then you need to read the entire cell, change the sector and write the entire cell back again similar to SSDs, but if the disk knows that the cell is completely empty it can simply write to it without reading the existing contents which is twice as fast. SMR drives have a CMR cache where writes are written first, and then in the background it destages these writes to the main SMR area. (And if you are doing bulk writes of random blocks, you can fill up the cache far faster than it can be destaged in the background, and then everything slows down by a factor of (say) 100.)
Having now thought about this, IMO I consider it likely that this means that for SMR HDDs:
TRIM is only effective when you have large contiguous empty areas of disk - this happens only when the disk is relatively new or when you have created such areas by running defrag. If you don't do defrag, it becomes increasingly likely that every cell has at least one sector used, and then bulk write performance becomes universally poor - but if you do defrag to create large areas of contiguous free space, then bulk performance will be better.
Whilst TRIM and automated regular defrag is supported as standard on Windows and windows file systems and has a GUI, other operating systems may not turn trim on automatically for SMR drives or may not defrag automatically.
I am unclear whether defrag programs have been enhanced to issue trim commands during defrag (which would be important for defrag speeds) or at the end of defrag (for future write speeds) or whether the operating system will handle one or both of these as sectors are marked unused by defrag.
Some file systems simply do NOT have a defrag capability (e.g. ZFS) - so over time it is likely that bulk writes with ZFS on SMR drives will slow to a crawl.
The performance of SMR drives during resilvering of redundant RAID1/5/6 or ZFS mirrors or RAIDZ will very much depend on whether the resilvering code TRIMS the entire drive before starting to write and whether the writes are then done sequentially across the drive or randomly - with ZFS RAIDZ the writes are done randomly and thus the time for resilvering can be exponentially larger.
