|
|
|
|
|
|
by justsomehnguy
1171 days ago
|
|
|
The problem with SMR is not the worse performance, but inability of operating as just a plain hard drive. You throw terabytes at CMR drive - it's just writes them to LBAs. You do the same at SMR drive - as soon as it's depletes FastCache/MediaCache or whatever it's called (buffer zones in CMR style to handle bursts of incoming data) it crawls to 1990's speeds OR even drops out of system. But honestly, there is almost no options left at the moment. There is no 2.5" CMR drives anymore and with 3.5" it's only a bigger disks with a price premium. |
|
|
A lot of folks don't realize that SMR drives have a lot more in common with SSD firmware with its emulated virtual block layer and wear leveling than a traditional HDD. Having the same kind of virtual block layer is where the problems come from.
With SSDs, virtual blocks stored in pages that are about to be erased have to be relocated elsewhere. SMR drives have to do the same sort of thing but with sequential recording for the overlapping tracks. All the same nightmares exist including garbage collection/reclaimation, de-fragmentation, managing TRIM (or parsing NTFS data structures), etc etc. With SMR, handling the worst case scenarios are made more difficult by seek latency - something that isn't as much of an issue for SSD storage.
All of this tends to invalidate cherished assumptions that unix/linux file systems make about HDD storage. And that's ignoring the issues about the devices reaching timeout thresholds - again, the kinds of things that Windows is OK with but really hurts linux/unix systems.