-
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)