> SMR is cheaper for them to manufacture, and is TERRIBLE technology

It's not that terrible if the customer knows what they're getting. It's just that SMR competes with tape more so than with conventional (CMR) hard drives. Many workloads are good enough for SMR.

>>Many workloads are good enough for SMR.

One workload is, which is what you said.. Archiving, what one would normally do to Tape.

Everything else is is substandard and should not be used

But what if you need random reads?

SMR sounds like it's great (value) at providing random read access to large amounts of data if you only have sequential writes or infrequent writes.

That's true. There would be no issue as long as the fact is clearly displayed in data sheets. The problem is not really with SMR, but with hiding the fact.

Due to the "staging area", I would not expect this to be true. Contiguous data written to an SMR does not land on disk in a linear fashion.

Data is juggled while staging, but doesn't it end up in its "proper" place? Do you have any info on how data is managed?

I mean, it could pull-off global block remapping, I just didn't expect it.

If it's in staging, it's not in its proper place. We know roughly how long it takes to fill staging. But I don't know how long it takes to clear.

During that time, data is not contiguous. Nor is there any guarantee that it will ever be.

Serious question: so basically wikipedia is the only use case?

Time series historian or some siem logging or similar journaling seem applicable to me. Maybe continuous loop video recording.

Ah video makes sense. Thanks.

You don’t need to write the entire drive sequentially with SMR, it’s just that you need to write sequentially within a given “chunk” of data. So there are some workloads that can, at least in theory, work on SMR. Think of object storage or log-structured data.

With proper system design and tiered storage, it would fit a lot of archival uses if it's visible.

Things like data warehousing, where you would want to store on something else for the current time period, but could store a big blob as the data gets finalized (once all nodes have reported in, or maybe after N days if you drop some columns at that time). Or household archival where data basically doesn't get changed once it's put on the storage --- wait for a block sized write to accumulate and then do it (need a different tier for the intermediate writes... Some SMR drives have a PMR section for this too).

But, device managed SMR is not a very good solution, even if the use case would be good for SMR, because the filesystem is most likely not aware of the need to cluster writes.

wikipedia is not a good use case.

Once the software problems are fixed, then just about anything you might want to put on a NAS is suitable for an SMR drive. Big files work just fine. Put all your big media files on it. Little files are fine in limited amounts, or in occasional bursts. You could install a program to it, but you wouldn't want to put your user folder on it. Don't put cache or temp files on it, or a database. Don't put a virtual machine's disk on it, since that implies an internal filesystem that doesn't know about the layout.

With a filesystem that understands the layout, they're almost as good as normal hard drives. With a filesystem that understands the layout and $3 of flash, you can make something that solidly outperforms a normal hard drive, at a much lower cost.

Also tape drives are too expensive for normal consumers.

With a huge latency difference which makes them totally different in practice.

The latency difference means the two are suited for very different real-world workloads. But they're similar enough in the access patterns they prefer that the software work to make your IO fit those patterns can be shared between SMR and flash.

The latency difference means that the access patterns are extremely different in practice. Even random reads get really painful on SMR since they get structured as logs that need to be replayed.

SMR is way more like tape than an SSD.

I’m still confused how SMR is suitable even for archive storage. The drives slow down tremendously when doing long sequential writes. I don’t think tape even does this.

Tape is pretty constant. It has a (let say) "optimum" throughput, and as long as you get the data to the drive controller fast enough that's what it'll do.

If you don't then the tape drive write speed falls off pretty quick as it does stuff to cope.

Dropbox has half their data on SMR drives. They did customize their storage software to work well with SMR, however.

They keep around old versions of your files for a time anyway, so the use case is almost a perfect fit.

Archival storage shouldn’t be use anything other than tape, in my opinion.

> SMR has a terrible rep for a reason, and no one with any knowlege of what SMR is would buy which is why they have to be unethical by removing this spec from the spec sheets

I have a couple of 8 TB Seagate SMR drives i use for backup, and for that purpose they've been great. They're cheaper than PMR drives, and i honestly don't care if the backup takes an hour extra to complete.

Unless you're in a business scenario, how much of your data on your x*8TB drives at home do you actually write to on a regular basis ?

Half of mine is family photos, backups of clients, movie/music media, etc. For this purpose SMR also works well.

I'm far more worried about power consumption for NAS drives than write performance.

To be fair your parent did say SMR is fine for your usecase of backups (archive).