• 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

foxit

Well-Known Member
#27
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.
 

turrican

Well-Known Member
Themenstarter #28
...aus Gaudi mal SSDs und HDDs, resp. SATA3 und SATA2 in einem pool zusammengekloppt. Lüppt problemlos.
Ja, als Pool kannst bei ZFS so ziemlich alles zusammenknoten - haste damals auch ne Platte mal rausgeworfen und ein resilver gemacht?
Da scheinen die (gemischten) Pools wg der SMR Platten Probleme zu haben.
 

jmt

Well-Known Member
#29
Ja, als Pool kannst bei ZFS so ziemlich alles zusammenknoten - haste damals auch ne Platte mal rausgeworfen und ein resilver gemacht?
Da scheinen die (gemischten) Pools wg der SMR Platten Probleme zu haben.
Ich habe den Pool nachträglich mit Geli verschlüsselt und somit jede Platte einmal resilvert. Kein Problem.
 

mr44er

moderater Moderator
Mitarbeiter
#30
haste damals auch ne Platte mal rausgeworfen und ein resilver gemacht?
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. :rolleyes:
 

turrican

Well-Known Member
Themenstarter #31
.... Selbstbau-ZFS-NASler sind eine Minderheit ....
Verdammt, ich WUSSTE es...


Wegen der SMR, naja, ich will halt bewußt keine SMR kaufen, bzw beim Kauf untergeschoben kriegen; ich will nur CMR... wenn schon Minderheit, dann aber mit CMR! :D
 

Azazyel

Well-Known Member
#32
Weiß jemand zufällig, wie weit bei BSD-ZFS das mit dem Host-Aware und Host-Managed SMR gediegen ist?
Ich darf mich selber zitieren: :)
Aktuell hinkt hier die Software aber noch hinterher, auch wenn es coole Projekte wie libzbc oder ZoneFS gibt.

Bei den Dateisystemem ist aktuell nur bei F2FS (unterstützt schon nativ SMR) und btrfs (in Arbeit) Bewegung. Bei OpenZFS, geschweige denn der Legacy-ZFS-Implementierung in FreeBSD, herrscht aktuell meines Wissens (noch) Stille.
Die Aussage gilt für HA-SMR und HM-SMR und es tut sich leider allem Anschein nach tatsächlich nix. :(
 

mr44er

moderater Moderator
Mitarbeiter
#33
ich will nur CMR... wenn schon Minderheit, dann aber mit CMR!
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. :p

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

Andy_m4

Well-Known Member
#34
Mich würde interessieren, was ihr so für eure zpools im Einsatz habt,
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.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#36
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. 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.
 

mr44er

moderater Moderator
Mitarbeiter
#37
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. ;)
 

serie300

Well-Known Member
#40
Ganz einfach: PCI in all seinen Varianten nutzt DMA, das Gerät mappt seine internen ....
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)
 

turrican

Well-Known Member
Themenstarter #41
@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?
Nein leider nicht; hab von damals nichts mitgenommen, auch mein now login funktioniert nicht mehr, kann also auch nichts mehr downloaden.
 

Rosendoktor

Well-Known Member
#42
Falls es jemandem hier hilft: ein Link zu iXsystems, in welchem bekannte SMR Plattentypen gelistet werden

[1] List of known SMR Drives
Danke für den Link, hat geholfen ;) Hab' mir gerade dank dieses Threads in letzter Sekunde zwei WD40EFRX statt der WD40EFAX geholt. Die sind zwar für den Medienserver (btrfs), aber irgendwann wenn sie da wieder zu klein werden wandern sie in den PC und da kommt wohl ein zfs drauf.