Im Gegensatz zu RAID-Systemen, bei denen eine SMR Festplatte nicht optimal ist, ist damit die Frage in Bezug auf ein UNRAID-System nicht beantwortet. Ich betreibe zusätzlich zu ein paar RAID-Systemen eine UNRAID System für Backups und hatte eine SMR-Platte übrig, die ich dort verbauen wollte.

Grund genug ein paar Test und Analysen zu machen mit und ohne Verwendung von SMR-Platten in einen UNRAID-System. Die Test waren – in Abhängigkeit des Use-Cases – sehr unterschiedlich. Somit ist es auch bei einem UNRAID-System sehr wichtig bei der Verwendung von SMR-Platten auf den Use-Case zu achten:

  • UseCase 1: Archivlösungen mit großen linearen Data Sets sind gut geeignet für SMR Platten Dies ist der Fall bei Filmsammlungen, ISO-Files, oder – wie in meinem UseCase – gepackte ZIP Files mit Backups. In Fällen, bei denen große Data Sets linear auf die Platte geschrieben werden, ist es nahezu nebensächlich, ob es sich um CMR oder SMR Platten handelt. Ausnahme hierbei ist die Parity Disk. Diese sollte auf keinem Fall eine SMR Platte sein, da bei jedem Schreiben auf eine andere Platte auch auf die Parity Disk geschrieben wird.
  • UseCase 2: NAS mit Zugriffen unterschiedlicher User auf Dateien bei denen die selbe Datei mehrmals verändert wird, die dies typischerweise auf Netzwerkfreigaben passiert, sollten keine SMR-Platten beinhalten. Ich konnte hierbei einen Leistungsverlust von 20-30% feststellen. Ähnlich wird es vermutlich aussehen, wenn eine Transaktionssystem auf eine solche Platte schreibt und Daten verändert.
  • UseCase 3: Noch extremer würde die Sache aussehen, wenn man Datenbank-Dateien, beispielsweise eines SQL-Servers, auf einem solchen System ablegen würde. Die habe ich jedoch nicht getestet, da mir die Leistungseinbuße bei US2 schon gereicht haben.

Fazit

Bei linearen Datensets, die hauptsächlich als WORM (write Once-Read Many) ausgelegt sind, wie beispielsweise Archivsysteme oder Backup-Rechner, kann man getrost auch SMR und CMR Platten mischen. Bei anderen Systemen, wie ZFS oder RAID-Systemen, sollte man das – auch im Fall von Use-Case 1 – tunlichst vermeiden.