5 ms·
>>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 su
by syshum 7y ago
>>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
- chmod775 7y agoBut 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.
- samstave 7y agoSerious question: so basically wikipedia is the only use case?
- tfigment 7y agoTime series historian or some siem logging or similar journaling seem applicable to me. Maybe continuous loop video recording.
- samstave 7y agoAh video makes sense. Thanks.
- eeZah7Ux 7y agowikipedia is not a good use case.
- klodolph 7y agoYou 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.
- toast0 7y agoWith 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.
- Dylan16807 7y agoOnce 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.
- mrjin 7y agoThat'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.
- sixothree 7y agoDue 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.
- labawi 7y agoData 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.
- sixothree 7y agoIf 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.
- wbl 7y agoHost managed SMR is similar to SSD in terms of what needs to be done.
- monocasa 7y agoWith a huge latency difference which makes them totally different in practice.
- wtallis 7y agoThe 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.
- monocasa 7y agoThe 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.
- Dylan16807 7y agoWith 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.