• 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.
 

mr44er

moderater Moderator
Mitarbeiter
#43
https://www.heise.de/news/NAS-Festp...-Red-HDDs-jetzt-als-inkompatibel-4777727.html

Western Digital hatte den Einsatz von SMR-Technik bei einigen seiner WD-Red-Modellen verschwiegen, obwohl der Hersteller diese Serie explizit für den Einsatz in NAS- und RAID-Konfigurationen empfiehlt.
...
Seit Bekanntwerden der SMR-Nutzung haben auch die beiden anderen Festplattenhersteller Seagate und Toshiba eingeräumt, den Einsatz von SMR bei bestimmten Desktop- und Notebook-HDDs nicht angegeben zu haben.
:rolleyes:
 

Rosendoktor

Well-Known Member
#45

Wow... Wenn ich dran denke wie knapp das war mit dem Kauf der WD40EFAX... das war echt allerletzte Sekunde, dass ich hier den Hinweis gefunden habe. Und ja, da kommt irgendwann ein zfs mirror drauf (momentan ein btrfs auf md-raid).
 

mr44er

moderater Moderator
Mitarbeiter
#47

turrican

Well-Known Member
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