[Sammelthread] ZFS Stammtisch

Midnight Commander
Midnight Commander (mc) ist ein Console Dateibrowser zum kopieren, verschieben, betrachten oder editieren von Dateien.

Da mc nicht im aktuellen Solaris 11.4 oder OmniOS Repositoty ist habe ich einen Online-Installer hochgeladen
um das einfach von der Console zu installieren (als root im Ordner /root starten):

wget -O - http://www.napp-it.org/midnight_commander | perl

Falls midnight commander keine korrekten Rahmen in Putty zeigt:
- open Putty settings Window > Translation: ändere UTF-8 nach ISO 8859-1 (Latin-1, West Europe)
- reconnect
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Abend,

da ich aktuell mit iSCSI experimentiere stellt sich mir die Frage worin der Unterschied zwischen iSCSI über Dataset ist und über Comstar.
So rein ersichtlich ist mir erstmal der größere Konfigurationsumfang - gibts da noch mehr ? Performance etc.

Funktionieren zwar beide nicht..über Comstar findet der Windows initiator kein target und über Dataset kreidet er mir immer die Blocksize an..
Aber habe damit auch erst angefangen.

-------------------

Ok, hat sich erledigt, Anbindung über Comstart hat nun funktioniert.
 
Zuletzt bearbeitet:
Ist nach meinem Verständnis beides über Comstar, auch wenn du z.B. in Nappit den Haken auf dem Dataset setzt.

Kann’s grade nicht testen/nachschauen, aber eigentlich war das recht simpel.
 
zu napp-it und Comstar

Mit iSCSI und dem Comstar Projekt hat Sun einen Blockstorage Server abgeliefert der an Flexibilität, Features und Performance kaum Wünsche offenläßt. Ein iSCSI LUN basiert auf einer "Logical Unit" (LU). Das ist eine Datei, eine Platte oder meist eine Zvol (ZFS Dateisystem als Blockdevice). Für den Zugriff der Gäste kann man beliebig viele Targets erstellen. Die Sichtbarmachung der LUs in einem Target erfolgt über Views. Der User nutzt die LUs dann als LUN in seinem Betriebssystem.

Der Zugriff der User auf die LUNs kann man über Target Groups, Host Groups und Target Portal Groups regeln.
COMSTAR and iSCSI Technology (Overview) - Oracle Solaris Administration: Devices and File Systems

Als Sun ZFS erfand, hatten die zuerst ein sehr einfaches Verfahren eingebaut, nämlich das Sharen eines Dateisystems via iSCSI, genau wie Sun es auch mit NFS und SMB gemacht hat. iSCSI als einfache ZFS Eigenschaft war vom Handling schlicht genial aber bei weitem nicht so flexibel wie das heutige Comstar und auch nicht so schnell. iSCSI als ZFS Dateisystem-Eigenschaft ist daher im heutigen Solaris und Illumos nicht mehr verfügbar.

Ich habe daher im napp-it Menü "ZFS Dateisysteme" die Comstar Funktionalität so im Hintergrund versteckt, dass man wieder über ein einfaches "Ein/Aus" ein ZFS Dateisystem per iSCSI freigeben kann und beim Freigeben die wichtigsten Parameter setzt. Im Hintergrund ist das Comstar und man kann auch per Comstar Menü Einfluß nehmen. Das Besondere an meinem Verfahren ist es, dass die GUID also die Kennung eines Luns im Namen des Zvol hinterlegt wird. Dadurch kann man auch nach einer Replikation der LU oder einem Neuaufsetzen des Betriebssystems ein iSCSI Share einfach wieder als Dateisystemeigenschaft aktivieren ohne sich um das ansonst notwendige Backup/Restore der Settings oder komplizierte Einstellungen zu kümmern.
 
Zuletzt bearbeitet:
Bisher war bei aktiviertem L2Arc immer ein Crash die Folge. Seit einer Woche scheint dieser Fehler gefunden. Man kann also durchaus hoffen dass es noch in diesem Sommer zumindest in ZoL und Illumos als Produktivfeature erscheint (Free-BSD scheint fast auf gleichem Stand, kommt eventuell leicht später) und dann bereits im Herbst in OmniOS 151028 stable auftaucht, in der Bloody und in OpenIndiana sofort nach Aufnahme in Illumos.
 
Ich benutze diesen Patch ja nun schon seit einigen Monaten auf Smartos und habe auch immer wieder den aktuellen Stand nachgezogen. In meinen Anwendungsfällen (kvm auf zvols, raw send/receive, compression, dedup ...) hat sich zfs crypto bisher als absolut stabil erwiesen, mit dem letzten Stand konnte ich bislang auch "mit Gewalt" keinerlei Crashes mehr produzieren. Der Patch greift halt schon tief in die Eingeweide von ZFS hinein, deswegen sind die Devs da äußerst vorsichtig und lassen ganz besondere Sorgfalt walten. Wie man an der Historie aber auch sehen kann, können viele Problem von automatisierten Tests nicht erkannt werden und tauchen erst im Paxiseinsatz auf. Insofern würde es sicher helfen, wenn die Userbasis hier verbreitert würde und möglichst viele das in ihren Umgebungen testen und aktiv verwenden. Ich bin gerne bereit, allen Interessenten beim compilieren/patchen zu helfen bzw. könnte auch fertige Smartos ISOs zur Verfügung stellen, falls Interesse besteht.

cu
 
Ich habe mal wieder zwei Fragen zu napp-it:
Ich habe einen Autosnap-Job, der alle 15 Minuten einen Snap eines Filesystems macht. Ich habe die Option "delete multiple snaps with size=0" aktiviert und würde eigentlich erwarten, dass in der Übersicht der vorhandenen Snapshots dann keine "leeren" Snaps auftauchen. Klappt aber nicht - auch wenn ich z.B. nachts keine Veränderungen an den Dateien vornehme, sind in der Übersicht unzählige Snaps (alle 15 Min.) vorhanden. Habe ich da was falsch verstanden?


Zweiter Punkt:
Versuche ich nun die überflüssigen Snaps über Snapshots/Mass-delete zu entfernen, habe ich das Problem, dass die Funktion "Delete only if size=0" bei mir genauso wenig funktioniert - Ergebnis: 0 snapshots would be deleted bei der Simulation.

Wo ist hier mein Denkfehler?
 
OK, danke.
Als User der Free-Version habe ich aber gegenwärtig nur Zugriff auf v18.01, oder?
 
Ja, die Free Version enthält nur Basis-Support

Die Basis/Free Version wird meist jährlich aktualisiert. Sie erhält dazwischen nur die Unterstützung neuerer Betriebssysteme (Solaris 11.4, OmniOS 151026) oder kritische Updates wie letzte Woche als bekannt wurde dass zumindest unter ESXi 6.7 die aktuellen Smartmontools beim Zugriff auf virtuelle ESXi Platten einen Kernel Panic verursachen (behoben in 18.01b free).

Dazwischen wandern alle kleineren Bugfixes oder neue Features und Anpassungen in dev Zweig (aktuell 18.09 dev) und daraus wird alle 3-6 Monate eine neue Pro Version generiert (aktuell 18.06 pro) - je nachdem wie groß der Anpassungsbedarf ist. OmniOS bringt ja alle 6 Monate eine neue Stable mit neuen Features und alle paar Wochen Bugfixes, OpenIndiana aktualisiert sein Repository degegen fließend (immer aktuelles Illumos, neue Features sofort dabei). Bei Solaris passiert ja gerade auch sehr viel mit 11.4. Das ist dann meist nur in der Dev enthalten.

Die nächste Basis/ Free Version wird 2019 kommen.
 
Kann man beim smb Server in omnios noch irgendwelche Einstellungen ändern?

Die meisten Apps unter iOS haben enorme Probleme mit dem Server.
Habe schon alles erlebt von: zeigen gar nix an (zb vlc), sagen Login ist falsch, versuchen sich ewig zu verbinden und es passiert nix, oder zeigen mir unter ner Freigabe alle Ordner als „(null)“ an.
Die einzige App die bislang geht ist RManager. Hatte auch mal ne andere noch die ging ab dem es in omnios smb2 gab nicht mehr obwohl man selber in der App smb2 an und ausschalten konnte.

Oder muss man nen Gast Account anlegen?
Die meisten Entwickler testen ihre Software anscheinend nur am Windows smb Server und Samba.

PlayerXtreme geht auch nicht obwohl das eigentlich ne recht verbreitete App ist.
 
Zuletzt bearbeitet:
Das liegt eher an mangelhaften Apps, bei VLC ist mWn immer noch kein SMB2 Support dabei. Da gab es schon seitenlange Diskussionen auf Github nachdem Microsoft begonnen hat bei neueren Windows Versionen den SMB1 Support zu deaktivieren.
 
Man Kann in OmniOS wie in jedem Solarish mit sharectrl einiges einstellen. Für die jeweiligen Optionen man sharectrl aufrufen oder siehe sharectl Command (System Administration Guide: Network Services)

Teilweise liegt es auch daran dass bei OmniOS für die Verbindungsaufnahme teils noch SMB1 benutzt wird und nur der Traffic dann auf SMB2.1 wechselt. Wie sich das mit Solaris 11.4 und NexentaStor5 (Nexenta hat SMB2 in Illumos eingepflegt) verhält kann ich nicht sagen. Die unterstützen ja beide jetzt auch SMB3. Ich hoffe ja dass SMB3 bald auch in Illumos kommt. Wer möchte kann ja einen Feature request mit seinem Problem in der Illumos-discuss Mailliste stellen. Wenn da sich viele melden gehts manchmal schneller.
 
moin,

gibt es ein How to für die Network / Virtual Switch Settings für Napp it / ESXI ?

Ich würde gerne so ein System aufsetzten, komme aber mit der Erklärung vom GEA "Napp in one PDF" nicht zurecht, verstehe das Senario des internen Netzwerktransfers (noch) nicht.
 
Man kann in ESXi ein oder mehrere virtuelle Switche anlegen. Jeder Port dieser Switche kann untagged arbeiten (Switchen einfacher IP Packete) oder man kann den Port auf ein bestimmtes getaggtes Vlan schalten.

Im enfachsten Fall - zumal am Anfang legt man nur einen Switch an und benutzt den ohne Vlans. Mit dem vSwitch verbindet man die physikalische Netzwerkkarte, den ESXi Kernel (darüber geht Management und NFS) sowie die beiden Netzwerkkarten die mein AiO Template standardmäßig anbietet (e1000 und vmxnet3). Ich nehme immer e1000 für napp-it Management und die vmxnet3 für NFS zum ESXi. Im einfachsten Fall nutzt man DHCP (z.B. vom Internet-Router). Im einfachsten Fall kann man die e1000 deaktivieren und nur die schnellere vmxnet3 nutzen (erst alles mit vmxnet3 nutzen, dann erst e1000 deaktivieren)

Man kann später oder alternativ zwei vSwitche nutzen und einen für ESXi Management, napp-it Management sowie NFS einsetzen und den zweiten Switch für normale Filerdienste. Wenn man nur eine physikalische Netzwerkkarte hat kann man dann Vlans nutzen um Netze zu trennen.

Für ganz hohe Sicherheitsanforderungen kann man auch zwei OmniOS Instanzen haben, eines für ESXi Storage und eine für allgemeine Filer und Backup Dienste.

Ansonsten: Googeln nach "esxi netzwerk einrichten"

ps
Bei ESXi 6.7 napp-it wenigstens auf napp-it 18.01b free updaten. Da gibt es ansonst ein Problem mit smartmontools und ESXi vdisks (Kernelpanic)
 
Zuletzt bearbeitet:
Vielen Dank GEA, für deine tolle Arbeit und deine sehr kompetenten Erklärungen !

für alle Interessierten: Hier ist eine bebilderte Anleitung zum Thema Netzwerk http://www.tinkertodd.com/1930-enable-vmxnet3-esxi-vspehere-napp-omni-os-vm/

Nun bin ich fast durch. leider ist ein neues Verständnis Problem aufgetaucht.

Ich habe deiner Empfehlung folgend mir eine Intel 900P für folgende Konfig zugelegt.

Dell T20 >USB Stick>ESXI>Nappit all in one (auf 40GB Partion Optane)
>Passtrough interner Sata Controller > NFS Datastorage (4xSSD ( 2x2 mirror))

Wie reiche ich jetzt den freien vorhanden Speicherplatz der Optane an Napp it weiter ?
einfach jeweils einen Datastore in ESXI erstellen für Zil und L2Arc ?
 
Zuletzt bearbeitet:
Wie reiche ich jetzt den freien vorhanden Speicherplatz der Optane an Napp it weiter ?
einfach jeweils einen Datastore in ESXI erstellen für Zil und L2Arc ?

Viel einfacher.
Man fügt einfach der OmniOS VM zwei virtuelle Platten hinzu die auf der Optane liegen.
Für Slog ca 20 GB rechnen und für L2Arc ca 5 x RAM.

Die kann man dann dem Pool als Slog bzw L2Arc hinzufügen.

Die leichten Geschwindigkeitseinbußen von virtuellen Platten vs Pass-through kann man angesichts der brachialen Performance der Optane verschmerzen - zumal Pass-trough mit den Optane noch nicht unterstützt wird.
 
Zuletzt bearbeitet:
Ist es nicht ziemlich unpraktisch dass der guest user der von nappit angelegt wird die userid 101 hat?

Ich habe bei einem Server jetzt OmniOS neu installiert und meinen alten pool wieder importiert. Da der Pool aus einer früheren Installation stammt kann ich jetzt erstmal überhaupt nicht mehr auf meine Freigaben zugreifen weil der user account mit dem ich es versuche die userid101 hat die nun dem Gastaccount zugeordnet ist.

Bzw denke ich dass mein Problem da liegt, mit dem root account kann ich zugreifen, allerdings dürfte auf dem Pool noch die ganzen Eigenschaften und Besitzer auf userid101 verweisen.

Hätte man den nicht irgendwo erstellen können wo er weniger stört?

Alle Dateien und Ordner die ursprünglich mich als Owner hatten haben jetzt den Owner Guest
 
Zuletzt bearbeitet:
Moin,

ich überlege gerade ein NAS zu bauen und bin unweigerlich auf das Thema ZFS gekommen.
Der Server soll vor allem 2 Aufgaben übernehmen, bei welchen hohe Geschwindigkeiten nötig sind:
1) Ablage von CAD/CFD Projekten. Hier müssen wenige hundert MB große Projekte mit vielen Dateien in MB Größe in möglichst kurzer Zeit geschrieben/lesen werden
2) Quelle für Videoschnitt. Hier werden wenige hundert GB große Projekte mit mehreren GB großen Dateien (aktuell nutze ich GoPro CineForm als intermediate codec) als streaming load gelesen

Für ZFS sprechen für mich die Datenintegrität (regelmäßige scrubs) und speziell für usecase 2 die lz4 Kompression. Problematisch ist vor allem, dass RaidZ1 nicht erweitert werden können (für OpenZFS zumindest angekündigt).

Meine Hauptfrage ist, wie viel RAM ich benötige. Aktuelle Idee eines naiven Neulings lautet:
Eine Optane 900P mit 280GB als SLOG/L2ARC und so wenig RAM wie möglich (dieser kann später dann gut aufgerüstet werden, wenn die Preise nicht mehr so verrückt sind).

Ein SLOG möchte ich nutzen, da ich "single points of failure" minimieren möchte und ohne USV die Idee nicht so gut finde, mehrere Sekunden Schreiblast nur im RAM zu haben. Als Kompromiss würde ich dann gerne eine Optane SSD und sync=always nutzen. Hierfür würde ich als Daumenregel 5 Sekunden Schreiblast vorhalten, was (begrenzt durch die 2GB/s Schreibgeschwindigkeit bei Optane) ca 10GB RAM wären. Kommt das hin?
Die verbleibende Kapazität der SSD würde als L2ARC mit einer blocksize von 32kb genutzt, woraus sich ein Mindestbedarf von ca 2GB RAM ergibt (für jeden L2ARC block muss ein 70 byte header im ARC abgelegt werden, max. 30% des ARC werden hierfür genutzt -> 270GB L2ARC / 32kb blocksize = ca 8500 Blöcke -> ca 600MB im ARC -> 2GB ARC). Setze ich dann noch l2arc_noprefetch=0 sollte doch das Laden des Projekts dazu führen, dass die Videodaten im L2ARC vorgehalten werden und ich flüssig durch die Timeline scrollen kann (hoffe ich...)

Als Anbindung nutze ich Connect-X 3 Pro Karten, sprich 40GbE mit RoCE.

Dazu drei Fragen:
- Kommen meine Überlegungen zum Thema RAM hin? Sollte ich also mit nur 16GB RAM dank Optane SSD und lz4 Kompression flüssig arbeiten können?
- Treten bei einem ZFS Storage eher single task Lasten auf, sprich wenige Kerne mit hohem Takt sind gut, oder lässt sich alles gut parallelisieren, wodurch ich auch eine günstigere CPU mit vielen Kernen aber geringerem Takt kaufen könnte?
- Soll ich die Idee verwerfen und einfach Windows mit Storage Spaces nutzen, wo ich die SSD als Cache nutze.

Vielen Dank
 
Laut Intel Optaneâ„¢ SSD 900P Series (280GB, 2.5in PCIe x4, 20nm, 3D XPointâ„¢) Produktspezifikationen hat die 900P keine power loss protection, ergo würdest du bei einem Stromausfall ohne USV wohl trotzdem Daten verlieren beim Einsatz als SLOG. Den Einsatz als L2ARC sehe ich ebenfalls kritisch, denn wie du ja schon schreibst, jeder Eintrag dort benötigt einen Pointer im RAM und reduziert den ARC. Der ARC ist aber defintiv einem L2ARC vorzuziehen, weil wesentlich schneller als eine Optane.
Streaming Workload (wie dein Videoschnitt) wird übrigens von ZFS recht zuverlässig erkannt und grundsätzlich nicht im L2ARC vorgehalten.

- Ich würde investieren in eine USV und viel RAM, evtl. eine Enterprise SSD als SLOG und natürlich möglichst viele Platten als Mirror+Stripe (nicht RAIDZ).
- Für 40GbE wirst du wohl kaum um eine schnellen CPU mit ordentlich Takt+Kerne herumkommen, sonst wird das nie befüllt.
- Zu Storage Spaces sag ich lieber nix :)


cu
 
Zuletzt bearbeitet:
Okay werd ich mal probieren. Aber nichts destotrotz wäre es sinnvoller gewesen den user guest wo anders hinzulegen, userid101 dürfte quasi von jedem schon unter Benutzung sein der frühere Versionen von Napp-It benutzt hat und dort Pools erstellt hat, sodass quasi jeder vor dem Problem stehen wird der einen Pool importieren möchte bei einem neuinstallierten Omnios + nappit:)
 
Die 900p hat aber keinen DRAM wie die üblichen Flash-Speicher.
Abgesehen davon wurde in den ersten Specs der 900p durchaus von Powerloss gesprochen, Intel hat das Statement aber dann relativ schnell rausgenommen.
Man kann nun mutmaßen, ob das nicht schlicht zur Marktsegmentierung diente, damit die Profis die teuren 4800X kaufen statt der 900p....
Oder ob da was mit bestimmten Firmwarerevisionen disabled wurde.
Unterm Strich ist das Risiko mit einem Slog per 900p wohl deutlich kleiner als mit sync=disabled. Eventuell ist es sogar gar kein Risiko. Von Intel wird man da nichts hören, denn man will dort schliesslich viel Geld an der P4800X verdienen.
Im kommerziellen Bereich wird mans sicher eher nicht machen.

L2Arc muss man dann später beim Workload schauen, obs was bringt oder ggf. sogar hinderlich ist. Echter Ram ist natürlich vorzuziehen.

Hier gibts übrigens ein Video zu dem Thema.
 
Zuletzt bearbeitet:
Meine Hauptfrage ist, wie viel RAM ich benötige. Aktuelle Idee eines naiven Neulings lautet:
Eine Optane 900P mit 280GB als SLOG/L2ARC und so wenig RAM wie möglich (dieser kann später dann gut aufgerüstet werden, wenn die Preise nicht mehr so verrückt sind).

Nunja
RAM ist gerade teuer, dennoch ist RAM um ein vielfaches schneller als eine NVMe - selbst eine Optane. Der Plan ist also eher schlecht. 10 GB RAM + Optane als readcache ist sicher erheblich langsamer als keine Optane und 32 GB RAM.

Da es sich um einen Filer handelt ist ein Slog nicht unbedingt nötig. Im Crash-Fall verliert man ohne sync write zwar den Inhalt des Ram-Schreibcaches - ZFS bleibt aber immer fehlerfrei (dank CopyObWrite, ganz im Gegensatz zu z.B, ntfs oder ext4)

Lz4 ist zwar toll, bringt aber bei bereits hoch komprimierten (Video) Daten nichts mehr, schadet aber meist auch nicht. Bei 40G Netzwerk sieht das aber eventuell anders aus.

Das Erweitern eines Raid-Z um eine Platte ist nur wichtig at home um von 2 Platten auf 3 zu gehen statt von 2 auf 4 oder statt von 6 auf 7 statt von 6 auf 12. Im professionellen Bereich eher unerheblich. Da wird Kapazität und Performance nicht um 20% erweitert sondern um 100%.

Ansonsten: RAM = ZFS Performance als Schreib-Lesecache
L2Arc kann bei Videodaten was bringen - vor allem wegen read ahead
Takt ist wichtiger als Cores aber unwichtiger als RAM oder ZFS Pool Layout

Connect X3 geht nur bei Linux, die Unix Optionen (Solarish und Free-BSD) mögen das eher weniger. Die sehe ich bei ZFS aber eher als empfehlenswerter/ einfacher/ schneller - tun einfach auch bei Updates, vor allem bei Solarish. Da ist ZFS daheim. Ansonst lieber eine Intel Dualport 10G oder 40G oder Chelsea nehmen, STHs Guides

Storage Spaces sehe ich als Verfahren um beliebige Platten unstrukturiert zusammenzufassen. Raid mit Redundanz entsteht dan durch Organisation beim Partitionieren. Datensicherheit durch das Dateisystem (ReFS). Performance und "Keep it Easy" ist aber was anderes.

zur Optane
Als Intel die auf den Markt brachte war "Powerloss Protection" noch in den technischen Daten. Wurde erst später zurückgezogen. Da die Optane keinen Ram-Cache hat kann man jetzt spekulieren ob das technische oder Marketinggründe hat. Wenn man die Intel Garantie braucht kostet es halt (Optane 4800). Ich habe mit der Optane 900 als Slog aber für die meisten Anwendungsfälle eher ein gutes Gefühl.


@CommanderBond
guest wird im napp-it online-installer bei der Erstinstallation angelegt.
Werde ich auf eine andere user-id setzen.
 
Zuletzt bearbeitet:
Wobei bei 10GB und mehr im Ernstfall schnell mal einige Gigabytes nicht aus dem Schreibcache weggeschrieben wären. Insofern hab ich auch daheim lieber eine USV vor die Kiste, um das Risiko zu drücken.

Auf nem Pool schalte ich LZ4 grundsätzlich ein, für Videos lege ich einfach ein dafür dediziert genutztes Dataset ohne LZ4 an. Ferner setze ich bei Videos-Datasets die Recordsize=1M.

Bei Sharing via Samba kann man eine Art Tiering ja quasi mit 2 Pools emulieren und Mountpoints so verschachteln, dass man das in einem einzigen Samba-Share in Form von Verzeichnissen hat. Ein Client sieht dann das ja als eine einzige Freigabe.

Btw, es wird schon auch Gründe haben, warum die 900p und 905p nicht in der jeweils höheren Kapazität als U.2 angeboten wird...
 
Zuletzt bearbeitet:
Wow, vielen Dank für die ganzen Antworten!

@Optane und PLP
Ja, das ist nicht perfekt. Aber das kritische Zeitfenster wird doch um den Faktor ~1000 kürzer.

@lz4
Die Videos sind nicht so stark komprimiert, speziell nutzen sie keine inter-frame compression. Das ist der Sinn - der SchnittPC muss weniger Rechenleistung aufs Decodieren verwenden, gerade das skippen durch die timeline wird deutlich flüssiger. Nachteil sind die deutlich größeren Daten.

@Netzwerk
Ich muss das nicht auslasten, sondern wollte eher sagen, dass es keine Begrenzung darstellt.
Oh und ich habe die Karten unter ESXi 6.5 zum Laufen gebracht, dort würde ich dann eine Solaris VM drauf laufen lassen. Ich will bei dem Projekt ja auch was lernen, also würde ich gerne das "echte" Solaris nutzen.

@RAM vs L2ARC
Das ist ja die Kernfrage. Ist bei streaming workload ein ARC schneller, in welches nicht das gesamte Projekt passt - oder ein L2ARC, welches das ganze Projekt vorhalten kann? Im Prinzip sollte ARC besser sein, wenn es immer die gerade benötigten Daten enthält, klar. Aber wie machen sich 20GB ARC bei 200GB Projektgröße?

Bei Sharing via Samba kann man eine Art Tiering ja quasi mit 2 Pools emulieren und Mountpoints so verschachteln, dass man das in einem einzigen Samba-Share in Form von Verzeichnissen hat.
Das ist generell die Alternative zu meinem Optane SLOG+L2ARC Plan, dass ich einen zweiten Pool auf SSD(s) erstelle und diesen dann fürs Schneiden nutze. Nachteil wäre, dass ich dann beim HDD Pool nicht von einem Optane SLOG profitiere, Vorteil die konstante Geschwindigkeit (selbst wenn die Daten nicht im ARC vorgehalten werden, erreiche ich noch die SSD Geschwindigkeit).
Ich vermute fast, dass dies für mich der bessere Weg ist.
 
Ich bin mir nicht sicher ob dir folgendes klar ist

Arc und L2Arc sind Lesecaches die blockbasiert (und nicht filebasiert) mit einer Optimierung auf read most/ read last arbeiten. Sie beschleunigen damit vor allem Reads auf die Metadaten und kleine random reads. Für sequentielle Daten bringt das eigentlich nur etwas weil die Metadaten gecacht sind. Die eigentlichen sequentiellen Daten kommen immer von Platte. Für L2Arc kann man allerdings read ahead aktivieren um sequentiell schneller zu lesen. In der angepeilten Performance könnte eine Intel Optane 900P als L2Arc Sinn machen.

Slog ist kein Schreibcache. Schreibcache bei ZFS ist rambasiert. Bei Open-ZFS ist der per default 10% des RAM (max 4GB). Bei Solaris und original ZFS hält der ca 5s der letzten Schreibvorgänge. Der Schreibcache dient dazu aus kleinen langsamen random writes große schnelle sequentielle zu machen. Das Slog schützt jetzt diesen Cache bei Stromausfall. Das Slog wird im normalen Betrieb nie gelesen - nur nach einem Crash um die Writes beim nächsten Boot nachzuholen. Für einen Filer ist das aber unerheblich. Da würde ich sync deaktivieren und mir das Slog sparen. Bei einem Crash sind zwar die letzten Sekunden Schreiben verloren und damit das geschriebene File eventuell korrupt. Um das abzufangen müsste man aber auch den Client und alle Switche absichern. Ansonsten hat man ZFS Snaps oder das schreibende Programm kümmert sich darum.

Für sequentielle Videodaten und Videoschnitt kann ein SSD only Pool Vorteile bringen. Das steht aber in keinem Verhältnis zu den Kosten. Ich würde einen normalen Plattenpool aus schnellen 7200 U/m Platten als Multi-Mirror aufsetzen. Meine Lieblingsplatten dazu sind die SAS Versionen der HGST Ultrastar HE. Für L2Arc und read ahead dazu optional eine Optane 900P. Die sequentielle Performance skaliert ganz gut mit der Anzahl der Mirrors.

https://napp-it.org/doc/downloads/performance_smb2.pdf
https://napp-it.org/doc/downloads/optane_slog_pool_performane.pdf
 
Zuletzt bearbeitet:
Hallo!

Habe Debian Jessie und ZFS seit 2 Jahren ohne Probleme am laufen. Nun habe ich beim raidz1 von 3x2TB auf 3x6TB gewechselt, d.h. eine HD nach der anderen per Replace ausgetauscht. Aber die Geamtkapazität hat sich am Ende nicht erhöht. Ich dachte bisher, das geht aber so. Hab ich was übersehen oder falsch gemacht?

Ciao
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh