Harddisk Density vs Data Retention Time ???

If you are using the disk as a cheap mass drive for backups or archives, then the random write speed is /irrelevant/. Reading when writing slowdowns are /irrelevant/.

In a backup or archive situation, your writes are almost entirely sequential, not random. And if you are using a smarter modern filesystem that has copy-on-write, transparent compression (which is appropriate for backups) and block checksums, such as ZFS or btrfs, even your "random" writes are basically sequential.

There's no doubt that SMR drives have their disadvantages and are a poor choice for a lot of other uses. And if your use-case can afford a higher per-bit cost, go for something else. But for backup and archive, they should be absolutely fine. (Dishonesty from the manufacturer about whether or not a drive is SMR, is never fine, obviously.)

Thanks for the nice summary, I had not looked at a drive past its system interface (ATA, SATA, SCSI) for a very long time.

Dimiter

====================================================== Dimiter Popoff, TGI

That depends heavily on the backup method.

If you're doing hardlink versioned directory copies (verisoned rsync backups) there's a lot of random writes to inodes and directory files

With ext4 or xfs, yes. With btrfs or zfs, much less so. (You still get writes to inodes and directories, but they too are COW and don't directly write over the same area on the disk.)

I used to have backups using hardlink copies for snapshots in combination with rsync. Now I use btrfs snapshots (with rsync) - they are much faster and much more space efficient. zfs would also work, I expect - I am simply more familiar with btrfs. (lvm snapshots can be of some use, and also give you COW and therefore SMR friendly write patterns, but you have to specify fixed sizes for your snapshots, which is not convenient.) I don't do this because it is SMR friendly - that is just a happy coincidence.

copy on write is a cause of fragmentation, and btrfs and zfs suffer heavily from this. The more junk you write the more places it ends up. You're suddenly not that far off from throwing random writes at the drive, oh and you're rewriting tracks all over the drive now. Unless you're doing someting like skipping the filestem and writing to raw partitions in a clever way where you control where and how data is written directly to the underlying storage it's all going to slow down like an old SSD where every page has been written to already. You'll easily saturate the cache of basically any drive if you're writing large chunks of data, say chunked sections of a gzip or whatever your "backup" sofware does. Like erasing a page on a SSD, rewriting tracks is a slow process, and if you're writing lots of data, you're going to run into these huge limitations. You might be able to tune you way out of some of these issues, or just use a fraction of the total disk capacity, or just not care about the performance in the first place, because you have a shingled drive.

They're a poor choice for anything but throwing in the trash or keeping paper plates and napkins from blowing away at a picnic.

Being ashamed of the junk they are is the reason manufacturers will lie about it. I can't think of any other instances of this happening with storage before. Even MFM vs. RLL controllers wasn't an issue of a drive manufacturer lying, but rather overly ambitious users or a dodgy PC builder.

Certainly. You rarely get something for nothing, and COW has its disadvantages - it is not the right choice for all types of load. For example, it is notoriously bad for database applications because they prefer to handle their own data integrity and do a lot of changes to files. (In general, COW is bad for uses where files are randomly written.)

Speed is not the only factor in choosing a storage medium. A small company might not be generating more than a few GB new data a day - writing that to SMR drives for backup at night is hardly a challenge. The lower cost and higher density of the drives means its easier to have more duplicates of the backup data - a vastly more useful metric than whether the backup run finishes in 15 minutes or 30 minutes.

Remember, if speed were the only consideration and cost did not matter, we'd use SSDs for everything.

When manufacturers lie, there is /definitely/ a problem. That is my only real concern with SMR. I'd like to be able to choose "You can buy this big SMR drive, or this more expensive big CMR". Let people make informed decisions about what is the best balance for their needs.