-
Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr
NAS Drives und SMR - welche Platten kauft ihr für NAS/zpools
- Themenstarter turrican
- Beginndatum
Ich habe meine 4 Disks im NAS vorgestern kontrolliert und eine war tatsächlich eine SMR Festplatte. Diese hatte ich gerade erst vor 6 Monaten getauscht, da mir eine kaputt gegangen ist. Gestern hatte ich Zeit und hab mal beim Support von WD angerufen (gratis Hotline). Was soll ich sagen? Ersatz ist unterwegs und ich bekomme problemlos eine Festplatte als Garantieaustausch ohne SMR.
Ja, ging problemlos. Knarzig und doof ists nur mit nem USB-Stick geworden. Der hat die Geschwindigkeit in den Keller gezogen, aber insgesamt keine Scherben.
SMR gibts doch auch schon wieder 24 Monate aufm Markt...kann daher auch sein, dass es insgesamt wenig Probleme gibt. Die Selbstbau-ZFS-NASler sind eine Minderheit, aber nicht unbedingt eine kleine. Als das neu war, hab ich viel logisch nachvollziehbare Panik und Vermeidung gelesen, aber wenig über tatsächliche Crashes und Datenverlust. Zumal Mensch ja geneigt ist, eher Schlechtes herauszuposaunen als Lobeshymnen. Im Nebenthread zu den 'Schwächen' von FreeBSD gab es ja sinngemäß den Kommentar, dass wenig Lobeshymne kommt. Tzja, die Lobenden genießen ihre Uptime, sind entspannt und nehmen den Thread daher nicht wahr.
Nochmal zu dem TLER: 7 Sekunden für jeweils Schreiben und Lesen sind gute Werte, die sich als Standard eingespielt haben. Platten neueren Datums haben das schon eingestellt und dauerhaft aktiviert. Manchmal habe ich den Eindruck, dass nur diese Einstellung in der PlattenFW den Unterschied zwischen normal und pro-Serie darstellt.
SMR gibts doch auch schon wieder 24 Monate aufm Markt...kann daher auch sein, dass es insgesamt wenig Probleme gibt. Die Selbstbau-ZFS-NASler sind eine Minderheit, aber nicht unbedingt eine kleine. Als das neu war, hab ich viel logisch nachvollziehbare Panik und Vermeidung gelesen, aber wenig über tatsächliche Crashes und Datenverlust. Zumal Mensch ja geneigt ist, eher Schlechtes herauszuposaunen als Lobeshymnen. Im Nebenthread zu den 'Schwächen' von FreeBSD gab es ja sinngemäß den Kommentar, dass wenig Lobeshymne kommt. Tzja, die Lobenden genießen ihre Uptime, sind entspannt und nehmen den Thread daher nicht wahr.
Nochmal zu dem TLER: 7 Sekunden für jeweils Schreiben und Lesen sind gute Werte, die sich als Standard eingespielt haben. Platten neueren Datums haben das schon eingestellt und dauerhaft aktiviert. Manchmal habe ich den Eindruck, dass nur diese Einstellung in der PlattenFW den Unterschied zwischen normal und pro-Serie darstellt.
Scho' richtig so, ist definitiv ein Bemängelungsgrund an den Händler, sollte der einfach was aus 'Abbildung kann abweichen' schicken. Grad wenn die Modellnummer nicht passt.
Ich weiß nicht, wo die Reise hingeht. Ergo ob CMR ausstirbt oder beides parallel weiter existiert. Weil man bei Herstellung Material spart und somit mehr Centregen an leitende Posten generiert, könnte man vorsichtig ne Prognose stellen. Es ist ja so, wenn du heute einen Datenbestand von 10TB hast, spielt man lieber jetzt damit rum und testet, als wenn du dann übermorgen in zwei Jahren mit Bauchschmerzen eine SMR zu den CMR bei 20TB stecken musst, weil es nix mehr anderes gibt.
Andererseits wird ZFS (oder vielmehr openZFS) bis dahin 200% startklar sein.
Man weiß halt nicht, wie man sich effektiv die Kniescheiben in der Sackgasse wegballern soll.
Da du ja auch die NetApp in Betracht gezogen hast: du musst sie ja heute nicht voll bestücken oder kannst zwei kaufen. Wenn es dann soweit ist, kannst du souverän auf den SMR-pool
Ich weiß nicht, wo die Reise hingeht. Ergo ob CMR ausstirbt oder beides parallel weiter existiert. Weil man bei Herstellung Material spart und somit mehr Centregen an leitende Posten generiert, könnte man vorsichtig ne Prognose stellen. Es ist ja so, wenn du heute einen Datenbestand von 10TB hast, spielt man lieber jetzt damit rum und testet, als wenn du dann übermorgen in zwei Jahren mit Bauchschmerzen eine SMR zu den CMR bei 20TB stecken musst, weil es nix mehr anderes gibt.
Andererseits wird ZFS (oder vielmehr openZFS) bis dahin 200% startklar sein.
Man weiß halt nicht, wie man sich effektiv die Kniescheiben in der Sackgasse wegballern soll.
Da du ja auch die NetApp in Betracht gezogen hast: du musst sie ja heute nicht voll bestücken oder kannst zwei kaufen. Wenn es dann soweit ist, kannst du souverän auf den SMR-pool
zfs senden. 
Also ich hab mir ein NAS aus folgenden Komponenten gebaut:
Als Basis Hewlett Packard Enterprise MicroServer Gen10 X3216
Als Platten kommen 3 Western Digital (WDC WD20EFRX68EUZN0) als zpool im RAID-Verband (RAID-Z1-Konfiguration) zum Einsatz. Dann gibts noch eine Hitachi HDS723020BLA642 als weiterer Pool, die aber keine Redundanz hat. Außerdem noch ne 120GB große SSD fürs System.
Als System drauf laufen tut ein aktuelles FreeBSD 12.1 (bei dem MicroServer Gen10 muss man allerdings ein hw.pci.realloc_bars=1 in die /boot/loader.conf packen, sonst bootet der Rechner nicht; gilt übrigens auch bei der Verwendung von anderen FreeBSD-basierten Systemen wie FreeNAS).
Das Storage wird via NFSv4 ins lokale Netz exportiert. Daneben hat der Rechner auch noch die Funktion von DHCP und DNS fürs lokale Netz sowie ein lokaler Webserver.
Die Maschine läuft jetzt inzwischen seit Ende 2017 quasi durch. Bisher keinerlei Probleme. Alles tut wie es soll.
Zur Frage: Ist die Basis-Hardware für ein NAS überdimensioniert?
Ja. Ist sie. Das ist aber mit Absicht so, weil ich mir die Option offen halten möchte damit eben auch mehr machen zu können. Und es kommt auch immer wieder was hinzu.
Als Basis Hewlett Packard Enterprise MicroServer Gen10 X3216
Als Platten kommen 3 Western Digital (WDC WD20EFRX68EUZN0) als zpool im RAID-Verband (RAID-Z1-Konfiguration) zum Einsatz. Dann gibts noch eine Hitachi HDS723020BLA642 als weiterer Pool, die aber keine Redundanz hat. Außerdem noch ne 120GB große SSD fürs System.
Als System drauf laufen tut ein aktuelles FreeBSD 12.1 (bei dem MicroServer Gen10 muss man allerdings ein hw.pci.realloc_bars=1 in die /boot/loader.conf packen, sonst bootet der Rechner nicht; gilt übrigens auch bei der Verwendung von anderen FreeBSD-basierten Systemen wie FreeNAS).
Das Storage wird via NFSv4 ins lokale Netz exportiert. Daneben hat der Rechner auch noch die Funktion von DHCP und DNS fürs lokale Netz sowie ein lokaler Webserver.
Die Maschine läuft jetzt inzwischen seit Ende 2017 quasi durch. Bisher keinerlei Probleme. Alles tut wie es soll.
Zur Frage: Ist die Basis-Hardware für ein NAS überdimensioniert?
Ja. Ist sie. Das ist aber mit Absicht so, weil ich mir die Option offen halten möchte damit eben auch mehr machen zu können. Und es kommt auch immer wieder was hinzu.
Ganz einfach: PCI in all seinen Varianten nutzt DMA, das Gerät mappt seine internen Konfigurationsregister, seinen eigenen RAM und so weiter auf normale Speicheradressen. Damit kann die Software das Gerät ansprechen, indem es einfach aus diesen Adressen liest und in sie schreibt. Diese DMA-Speicherebereiche werden durch das Base Address Register oder kurz BAR beschrieben. Beim Initialisieren des Geräts liest der Kernel das BAR und allokiert die dort gewünschte Menge auf einer durch das Gerät vorgegebenen Speicheradresse. Die Allokation kann aber fehlschlagen. Beispielsweise wenn mehrere Geräte sich überschneidende Adressbereiche wählen, wenn sie in durch das BIOS, das UEFI oder das Betriebssystem reservierte Bereiche wollen und so weiter.
Damit das klappt, muss das Gerät aber mitspielen. Das Problem dabei ist, dass es immer noch genügend Geräte gibt, die es nicht tun. Das kann zu ganz bösen Fehlern führen. Beliebt ist zum Beispiel, dass das Gerät so tut, als sei alles in bester Ordnung, aber anfängt einfach wirr Daten durch den ganzen Adressraum und damit auch den physischen RAM zu schreiben. Das führt dann zu extremer Speicherkorruption mit all seinen Nebenwirkungen. So ein [zensiert] hat mir mal einen ganzen zpool gekostet... Daher ist die Möglichkeit auf anderen Speicheradressen zu allokieren bei Linux und FreeBSD in Standardeinstellung aus und sollte nur genutzt werden, wenn es anders nicht geht.
hw.pci.realloc_bars=1 erlaubt dem Kernel solche Allokationen zu verschieben. Das Gerät bekommt sozusagen nach friss oder stirb Methode eine Speicheradresse für seine Allokation diktiert.Damit das klappt, muss das Gerät aber mitspielen. Das Problem dabei ist, dass es immer noch genügend Geräte gibt, die es nicht tun. Das kann zu ganz bösen Fehlern führen. Beliebt ist zum Beispiel, dass das Gerät so tut, als sei alles in bester Ordnung, aber anfängt einfach wirr Daten durch den ganzen Adressraum und damit auch den physischen RAM zu schreiben. Das führt dann zu extremer Speicherkorruption mit all seinen Nebenwirkungen. So ein [zensiert] hat mir mal einen ganzen zpool gekostet... Daher ist die Möglichkeit auf anderen Speicheradressen zu allokieren bei Linux und FreeBSD in Standardeinstellung aus und sollte nur genutzt werden, wenn es anders nicht geht.
Ich danke mal wieder für die bombigst gute Erklärung. Definitiv was fürn Hinterkopf, scheint ja doch nicht so selten vorzukommen und lässt nicht unbedingt auf die 'Qualität' schließen. Wobei das bei dir eine der ruhmreichsten realtek-NICs war, oder?
@turrican
Hattest du beruflich mit den NetApps auch mal Berührung zu diesen SATA-SAS-Interposern von LSI? Hast du vielleicht noch einen Datenhaufen von früher, wo firmware und flashtools für selbige vorhanden sind?
Nach meiner Recherche gab es die Dinger eher selten, aber genau um solche Probleme mit timeouts und vom RAID fliegende Platten bei SATA-Kunden in den Griff zu kriegen. Weil man wenig bis gar nichts mehr darüber im Netz findet, scheint diese Ära sehr kurz gewesen zu sein.
Ich selber benutz die Dinger für SATA-SSDs, klappt prima. Die FW auf den Interposern ist jedoch so eingestellt, dass sie sämtliches caching deaktiviert. Umstellen geht nur, wenn man sich mit den tools selber FW bäckert und die dann flasht.
Diese Interposer könnten ggf. nützlich als letzte Bastion für SMR-Platten mit ZFS sein, nur so als Idee.
@turrican
Hattest du beruflich mit den NetApps auch mal Berührung zu diesen SATA-SAS-Interposern von LSI? Hast du vielleicht noch einen Datenhaufen von früher, wo firmware und flashtools für selbige vorhanden sind?
Nach meiner Recherche gab es die Dinger eher selten, aber genau um solche Probleme mit timeouts und vom RAID fliegende Platten bei SATA-Kunden in den Griff zu kriegen. Weil man wenig bis gar nichts mehr darüber im Netz findet, scheint diese Ära sehr kurz gewesen zu sein.
Ich selber benutz die Dinger für SATA-SSDs, klappt prima. Die FW auf den Interposern ist jedoch so eingestellt, dass sie sämtliches caching deaktiviert. Umstellen geht nur, wenn man sich mit den tools selber FW bäckert und die dann flasht.
Diese Interposer könnten ggf. nützlich als letzte Bastion für SMR-Platten mit ZFS sein, nur so als Idee.
Hallo
eine technische Frage dazu. Abgesehn davon, daß PCI Geräte ggf. via DMA Speicherbereiche füllen - ist das technisch Memory Mapped IO oder schießt das PCI Gerät tatsächlich Daten via DMA dahin / von dort zu sich? Beim Schreiben vom Prozessor in diesen Bereich müßte dann ja der Prozessor oder die MMU das PCI Gerät antriggern, DMA zu machen (außer es hat 'ne Bus Snooping Logik)
eine technische Frage dazu. Abgesehn davon, daß PCI Geräte ggf. via DMA Speicherbereiche füllen - ist das technisch Memory Mapped IO oder schießt das PCI Gerät tatsächlich Daten via DMA dahin / von dort zu sich? Beim Schreiben vom Prozessor in diesen Bereich müßte dann ja der Prozessor oder die MMU das PCI Gerät antriggern, DMA zu machen (außer es hat 'ne Bus Snooping Logik)
Themenstarter
#44
Es geht sogar noch weiter - WD wird nun verklagt;
[1] Western Digital gets sued for sneaking SMR disks into its NAS channel, arstechnica
[1] Western Digital gets sued for sneaking SMR disks into its NAS channel, arstechnica
Themenstarter
#48
Noch ein kleiner Nachtrag zum Thema:
Mutmaßlich wussten die bei WD genau dass die DM-SMR nicht bzw nicht gut mit ZFS in der aktuellen Form laufen, waren aber insgesamt als Firma zu träge, um dagegen anzuarbeiten - und damit ggf. den eigenen Ruf zu retten, siehe [1]
Stattdessen ließen sie vor ein paar Wochen noch das übliche Marketinggeseier vom Stapel, siehe [2]:
"All our WD Red drives are designed meet or exceed the performance requirements and specifications for common small business/home NAS workloads..."
Das "exceed" ging hier aber wohl in die andere Richtung, und die wussten davon - zumindest die damit befaßten Ingenieure, welche über HGST zu ihnen kamen (damals mit HGST eingekauft wurden), und das ja auf der OpenZFS Konferenz 2015 [3] auch sagten (hier im Beispiel Manfred Berger).
Dreist war auch, dass sie (sie == WD) bewußt verleugneten:
"The information you shared from [Geizhals] appears to be inaccurate..."
Unter Umständen wußte der die Info gebende Mitarbeiter der Firma jedoch wirklich (noch) nichts von der Thematik, was auch auf die oben besagte "Trägheit" innerhalb des Konzerns hindeuten könnte;
Da also alle Hersteller (WD, Seagate, Toshiba, HGST is ja eh WD) das SMR heimlich still und leise (ohne besondere Kennzeichnung auf der Disk) unter die Leute bringen wollten, könnte man schon Absicht unterstellen.
Schaut so aus, als ob WD vorgeprescht ist (vorpreschen musste?) und die anderen Hersteller sich dann schnell noch in ne Sicherheitszone brachten (Seagate, sinngemäß: "Keine unserer NAS Platten nutzt SMR...", [4]), obwohl ja eigentlich alle Hersteller SMR Technologie auf gerade vermarkteten Platten wie z.B. Seagate auf den Barracuda und FireCuda nutzen, siehe auch [5].
Faustregeln zur Erkennung von SMR; kann - muss aber nicht zu einem korrekten Resultat führen:
- SMR Platten haben meist nen wesentlich größeren Cache als CMR (256MB (SMR) zu 64 MB (CMR) bei WD, kann bei Platten für den Professionellen Markt jedoch weniger eindeutig sein, da auch die CMR dort schon einen größeren Cache haben);
- SMR Platten werden vom OS ggf sogar als "SSD" erkannt, da die SMR meist die "Trim" Funktionalität unterstützen - aber auch für dieses Kriterium kann man keine 100%-ige Aussage treffen, da das von Hersteller zu Hersteller und Modell zu Modell unterschiedlich ausfallen kann;
Die Entwickler der smartmontools arbeiten kontinuierlich an ner Verbesserung des Tools zur genauerern Erkennung der SMR Drives, [6]
Die bekannten SMR Platten von WD werden jetzt mit den neusten Patches als "...<Typbezeichnung> (SMR)" eindeutig angezeigt, sowie mit dem Zusatz "Zoned Device: Device managed zones" - was auf DM-SMR hindeutet.
[1] WD Knew DM-SMR and ZFS were a bad match!?!
[2] Kommentar von WD zum Thema auf blocksandfiles.com
[3] Manfred Berger - HGST SMR - OpenZFS European Conference 2015
[4] Seagate says Network Attached Storage and SMR don't mix
[5] Seagate, Liste CMR/SMR Platten
[6] smartmontools, Ticket #1313
Mutmaßlich wussten die bei WD genau dass die DM-SMR nicht bzw nicht gut mit ZFS in der aktuellen Form laufen, waren aber insgesamt als Firma zu träge, um dagegen anzuarbeiten - und damit ggf. den eigenen Ruf zu retten, siehe [1]
Stattdessen ließen sie vor ein paar Wochen noch das übliche Marketinggeseier vom Stapel, siehe [2]:
"All our WD Red drives are designed meet or exceed the performance requirements and specifications for common small business/home NAS workloads..."
Das "exceed" ging hier aber wohl in die andere Richtung, und die wussten davon - zumindest die damit befaßten Ingenieure, welche über HGST zu ihnen kamen (damals mit HGST eingekauft wurden), und das ja auf der OpenZFS Konferenz 2015 [3] auch sagten (hier im Beispiel Manfred Berger).
Dreist war auch, dass sie (sie == WD) bewußt verleugneten:
"The information you shared from [Geizhals] appears to be inaccurate..."
Unter Umständen wußte der die Info gebende Mitarbeiter der Firma jedoch wirklich (noch) nichts von der Thematik, was auch auf die oben besagte "Trägheit" innerhalb des Konzerns hindeuten könnte;
Da also alle Hersteller (WD, Seagate, Toshiba, HGST is ja eh WD) das SMR heimlich still und leise (ohne besondere Kennzeichnung auf der Disk) unter die Leute bringen wollten, könnte man schon Absicht unterstellen.
Schaut so aus, als ob WD vorgeprescht ist (vorpreschen musste?) und die anderen Hersteller sich dann schnell noch in ne Sicherheitszone brachten (Seagate, sinngemäß: "Keine unserer NAS Platten nutzt SMR...", [4]), obwohl ja eigentlich alle Hersteller SMR Technologie auf gerade vermarkteten Platten wie z.B. Seagate auf den Barracuda und FireCuda nutzen, siehe auch [5].
Faustregeln zur Erkennung von SMR; kann - muss aber nicht zu einem korrekten Resultat führen:
- SMR Platten haben meist nen wesentlich größeren Cache als CMR (256MB (SMR) zu 64 MB (CMR) bei WD, kann bei Platten für den Professionellen Markt jedoch weniger eindeutig sein, da auch die CMR dort schon einen größeren Cache haben);
- SMR Platten werden vom OS ggf sogar als "SSD" erkannt, da die SMR meist die "Trim" Funktionalität unterstützen - aber auch für dieses Kriterium kann man keine 100%-ige Aussage treffen, da das von Hersteller zu Hersteller und Modell zu Modell unterschiedlich ausfallen kann;
Die Entwickler der smartmontools arbeiten kontinuierlich an ner Verbesserung des Tools zur genauerern Erkennung der SMR Drives, [6]
Die bekannten SMR Platten von WD werden jetzt mit den neusten Patches als "...<Typbezeichnung> (SMR)" eindeutig angezeigt, sowie mit dem Zusatz "Zoned Device: Device managed zones" - was auf DM-SMR hindeutet.
[1] WD Knew DM-SMR and ZFS were a bad match!?!
[2] Kommentar von WD zum Thema auf blocksandfiles.com
[3] Manfred Berger - HGST SMR - OpenZFS European Conference 2015
[4] Seagate says Network Attached Storage and SMR don't mix
[5] Seagate, Liste CMR/SMR Platten
[6] smartmontools, Ticket #1313
Ebenfalls noch lesenswert:
https://www.heise.de/news/NAS-Festp...D-Red-Plus-fuer-CMR-Garantie-ein-4794455.html
Sowie neuer #aufschrei
:
https://www.heise.de/newsticker/mel...an-irrefuehrender-5400-RPM-Class-4888581.html
https://www.heise.de/news/NAS-Festp...D-Red-Plus-fuer-CMR-Garantie-ein-4794455.html
Sowie neuer #aufschrei
:https://www.heise.de/newsticker/mel...an-irrefuehrender-5400-RPM-Class-4888581.html