Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Dein "Problem" sind die 22GB Wired Memory. Das ist Speicher, der durch den Kernel in Verwendung ist und nicht ausgelagert werden kann.
Standardmäßig nimmt sich FreeNAS bis zu 80% des verfügbaren RAMs für ZFS Zwecke. ARC wird bei Dir zwar nur mit 4GB angezeigt, aber ich vermute, dass das nur der Netto Lese Cache ist. Was in die ZFS Caching Mechanismen noch alles mit reinspielt kann ich leider nicht sagen. Es gibt aber mehrere Parameter mit denen man die Nutzung reduzieren kann.
Aber drehen wir den Spieß mal um: Hast Du denn Probleme, dass Dir irgendeine Anwendung zu wenig RAM bekommt? Üblicherweise gilt die Regel "unbenutzter RAM ist verschwendeter RAM". Insofern ist nichts verwerfliches daran, wenn Dein Speicher nahezu vollständig ausgelastet wird. Üblicherweise gibt ZFS im Kernel auch wieder Speicher frei, sobald andere Programme nach Speicher verlangen.
Früher lief auf meinem Microserver mit 16GB ein Proxmox mit zfs Pool. Speicher war immer gut ausgelastet. Wenn ich dann eine neue VM starten wollte, kam erstmal der Fehler, dass nicht genug RAM zur Verfügung steht. Dadurch wurde dann zfs getriggert, seinen RAM Verbrauch zu reduzieren und einige Sekunden später konnte ich die VM problemlos starten.
Danke für deine Antwort und Erklärungen dazu.
Es war auch mein Wissensstand, dass viel RAM reserviert wird. Nur ich bin davon ausgegangen, dass er für ARC genutzt und dort auch im Dashboard angezeigt wird, und nicht unter Services. Es läuft ansonsten sehr gut. Ich wollte nur die Hintergründe verstehen.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Normalerweise setzt man Rechte auf Dateien und Ordner für die einzelnen Nutzer und Gruppen. Nur diese Rechte sind dauerhaft im Dateisystem gespeichert, bei Solarish sogar als Windows Security ID sid. Am Einfachsten macht man das per Windows indem man sich als root anmeldet (=volle Rechte) über einen Rechts-Mausklick auf eine Datei/Ordner und Eigenschaft > Sicherheit. Lediglich Deny-Regeln muss man direkt auf Solarish/napp-it setzen.
Wenn man Rechte setzt, kann man die auch auf tieferliegende Objekte anwenden. Das ersetzt dann deren Rechte. Ansonst kann man beim Rechte auf einen Ordner setzen angeben, ob die vererbt werden sollen (Dieser Ordner oder auch enthaltene Ordner und Dateien). Das ACL wirkt für die angewählte Datei/Ordner oder bei einem Ordner auf darin neu erstellte Dateien oder Ordner. Die Vererbung kann man dann bei einem tieferliegenden Ordner auch wieder abschalten.
ACL auf Shares ist eine Möglichkeit Rechte kurzzeitig global zu reduzieren z.B. alle nur lesen oder root only. Wenn man eine Freigabe aus/einschaltet geht das immer zurück auf default (jeder=full).
Vielen Dank für die Hinweise, die ich so 1:1 umsetzen konnte. Einzige wirklich Klippe war die Anmeldung als root bei Windows. Ich hatte nach der Installation von OmniOS keinen SMB-User 'root' angelegt. Nach 'passwd root' war dies aber erledigt.
So ich versuche mich jetzt mal wieder an ZFS send, da ich die Daten vom alten auf's neue NAS migrieren will (mit Rsync würde das ganze schon längst laufen - unter FreeNAS /XigmaNAS)
auf dem Ziel
Die ursprüngliche Befehlszeile
"nc -l -p 9999 | zfs receive Pool-01/DS-01" wurde quittiert mit ""Port number invalid p"
Pool_01 ist angelegt, aber keine Datasets!
Auf der Quelle:
zfs send -v -R Pool-01/DS-01@Now | nc -w 1800 <IPADRESSE vom Ziel> 9999
Grundsätzliche Frage, warum muß eine lokale IP Adresse überhaupt aufgelöst werden?
Mit 'nem einfachen Dateibasierten Transfer (Midnight Commander oder rsync) würde ich die derzeit noch vorhandene Gigabit Schnittstelle nicht derart voll auslasten.
Es gibt ja immer mehr NAS Platten die offen oder eher versteckt mit MSR Technologie arbeiten. Der Vorteil dieser Platten ist die höhere Kapazität. Der Nachteil ist die geringere Schreibleistung.
Bei STH gibt es einen Test, der die WD red MSR Platten
mit herkömmlichen CMR Platten vergleicht.
Das Ergebnis
Beim Lesen sind keine großen Unterschieden
Beim Schreiben sind keine großen Unterschiede, sofern man nur die ersten Minuten Schreiben betrachtet. Danach bricht die Schreibrate komplett ein (Memory Cache + MC (Mediacache/Plattenbereich ohne SMR) voll => Direktes Schreiben auf MSR Bereiche notwendig).
Besonders drastisch wird das bei einem Raid-Z Resilver/rebuild. Mit den CMR Platten war der Rebuild in 17 Stunden fertig. Mit den MSR brauchte es 230 Stunden, also 13x so lange. Besonders problematisch. In dieser langen Zeit ist nicht nur die Raid Redundanz reduziert und man hat ein höheres Risiko eines Datenverlustes sondern auch die Storage Performance ist komplett im Keller.
We tested WD Red SMR v CMR drives to see if there was indeed a significant impact with the change. We found SMR can put data at risk 13-16x longer than CMR
Das ist ein bissl mehr als 2/3 Tag vs. 9 1/2 Tage! Also MO vs. MO - MI-Mittag der nächsten Woche. Und während dessen volles Risiko eines Totalausfalls.
Das schieben die Hersteller den Käufern einfach so unter? Und leugnen auch noch dreist?!? Wie kann ich denn sicher sein, die richtigen Festplatten zu kaufen? Ohne dabei auf WD zurückgreifen zu müssen?
Für uns in D hat das keine Relevanz. Da sind die Amis fein raus. Eine Sammelklage in D gibt es für sowas nicht. Man sieht ja auch, wieviel Aufwand und Risiko da drin steckt, wenn man an den Kampf gegen die offensichtlichen Schwindeleien von VW denkt. Recht haben und Recht bekommen sind halt zwei Dinge. Da hilft nur eines ... Hersteller meiden
Es gibt ja immer mehr NAS Platten die offen oder eher versteckt mit MSR Technologie arbeiten. Der Vorteil dieser Platten ist die höhere Kapazität. Der Nachteil ist die geringere Schreibleistung.
Bei STH gibt es einen Test, der die WD red MSR Platten
mit herkömmlichen CMR Platten vergleicht.
Das Ergebnis
Beim Lesen sind keine großen Unterschieden
Beim Schreiben sind keine großen Unterschiede, sofern man nur die ersten Minuten Schreiben betrachtet. Danach bricht die Schreibrate komplett ein (Memory Cache + MC (Mediacache/Plattenbereich ohne SMR) voll => Direktes Schreiben auf MSR Bereiche notwendig).
Besonders drastisch wird das bei einem Raid-Z Resilver/rebuild. Mit den CMR Platten war der Rebuild in 17 Stunden fertig. Mit den MSR brauchte es 230 Stunden, also 13x so lange. Besonders problematisch. In dieser langen Zeit ist nicht nur die Raid Redundanz reduziert und man hat ein höheres Risiko eines Datenverlustes sondern auch die Storage Performance ist komplett im Keller.
We tested WD Red SMR v CMR drives to see if there was indeed a significant impact with the change. We found SMR can put data at risk 13-16x longer than CMR
Ich zitire mal ein paar Ausagen von mir zum Thema - aus 2005 (Seagate Archive v2 - 8TB)
Ergänzend noch folgende Aussage: Meine Hoffnungen, daß die Progrsammierer für die Dateiesystemtreiber etc. (z.B. auch Treiber für Massenenspeicher) das Thema SMR - insbesonderere Host Aware SMR - relativ zeitnah angehen und entsprechende Anpassungen vornehmen hat sich mitlerweile trotz entsprechender Ankündigungen wohl komplett ereledigt, daher besteht mein neues NAS, welches gerade befüllt wird aus 12x Seagate Exos 16TB - natürlich wieder im Raidz3.
Bei Open-ZFS war man anfanglich äusserst enthusiastisch, was die entsprechenden Anpassungen betraf, mitlerweile wohl komplett verworfen. Auch das Projekt von SMRFFS-EXT4 unter Mithilfe von einem Seagate Mitarbeiter (Lead Engineer: Adrian Palmer) ist komplett eingeschlafen (Stand December 2015)
#563
kleines Zwischenupdate.
Das System ist jetzt satte 24h am Stück gelaufen, ohne Crash. Ich gehe also davon aus, daß die Tweaks die nötige Systemstabilität gebracht haben.
in diesen 24h habe ich dauerhaft Daten via GBit-LAN auf das Raidz3 kopiert. Füllgrad jetzt ca. 13,5 TB von 30,5TB - also noch nichtmal halbvoll
Laut "Status/Graph" pendelte die Transferrate eigentlich permanet so um die 80 MB/s (70-90 MB/s) - auch vorher schon. Ab und zu habe ich Transferpausen von 20-30s gesehen, ob das nun aber eine Folge von SMR ist, oder einfach der Cache leergeschrieben wird, vermag ich nicht zu sagen. Die Pausen traten eher bei Transferende einer Datei auf, aber auch mal mittendrin.
Ich werde das System jetzt erstmal runterfahren, und den Platten ein paar Stunden Ruhe gönnen, Morgen geht's weiter mit Kopieren, ca. 10 TB müssen da noch rauf , danach schaue ich wie lange ein Scrub dauert, und anschliessend wird resilvered.
#579
Raidz3 aus 7 (4+3) Platten ist gut 80 % gefüllt (ca. 24,5 TiB von 30,5 TiB).
Ich habe gerade 'nen Scrub angeschmissen, sieht erstmal recht performant aus.... (bei unter 50% CPU Load) - mal sehen wie's am Ende aussieht!
state: ONLINE
scan: scrub in progress since Sun Apr 19 18:33:08 2015
576G scanned out of 39.9T at 876M/s, 13h4m to go
0 repaired, 1.41% done
#581
Der Scrub wird langsamer, CPU Last nur noch bei rund 25 %
Daraus ersehe ich schonmal, daß meine Entscheidung nur 'nen i3-4150 statt doppelt so teurem Xeon zu nehmen nicht verkehrt war, der Scrub läuft im Plattenlimit und nicht im CPU-Limit. wird sich sicherlich bei mehr Platten im Raidz3 nochmal Richtung CPU-Limit verschieben.
scan: scrub in progress since Sun Apr 19 18:33:08 2015
16.3T scanned out of 39.9T at 813M/s, 8h26m to go
0 repaired, 40.95% done
state: ONLINE
scan: scrub repaired 0 in 16h41m with 0 errors on Mon Apr 20 11:14:21 2015
Zum Vergeich:
Der letzte Scrub auf einem HP-N54L mit 5x4 TB Platten im Raidz1 hat 15h41m gedauert, wobei der zur Zeit gut 99% gefüllt ist (wird wieder weniger, wenn das grosse NAS endlich in Betrieb ist)
#588
Resilver dauert aber lange..... (war eigentlich zu erwarten nach dem Test http://www.storagereview.com/seagate_archive_hdd_review_8tb)
Die CPU schaukelt sich die Eier bei 5 % Last (1-10% - Spitzen bs 25 %), da wird auch 'ne schnellere CPU nichts rausreissen - die würde sich halt die Eier etwas schneller schaukeln .
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Mon Apr 20 13:55:16 2015
494G scanned out of 39.9T at 155M/s, 74h6m to go
70.5G resilvered, 1.21% done
scan: resilver in progress since Mon Apr 20 13:55:16 2015
2.24T scanned out of 39.9T at 110M/s, 100h4m to go
328G resilvered, 5.62% done
Ich habe mal geschaut, ob es zum Thema ZFS SMR Host Aware irgenwelche Neueigkeiten gibt, leider habe ich nichts gefunden. Für das EXT4 Filesystem gibt es bereits eine SMR HA Erweiterung (https://github.com/Seagate/SMR_FS-EXT4).
Bei ZFS gibt es ausser den beiden PDFs von ROBERT E. NOVAK und Timothy Feldman vom letzem Jahr - nach dem Motto "wir müssen da was tun" -, noch gar nichts vorzeigbares .
Es scheint sogar so zu sein, daß die V2 der Seagate Platten bereits für Host Aware SMR vorbereitet ist, nachdem was ich gelesen habe. Es heisst also immer noch abwarten, ob sich was tut.
Richtig so, hier in D bleibt da nur die Gewwährleistung ggü. dem Händler - zumindest bei den Reds wegen des Fehlens einer zugesicherten Eigenschaft!
Die Eigenschaft "Eignung für den uneingeschränkten Betrieb in einem NAS" dürfte unzweifelhaft zugesichert gewesen sein.
Da dürften einige Gewährleistungs-Rückläufer auf den Handel zukommen!
Mit größerem Ramcache und dem Mediacache Bereich auf den zunächst ohne MSR geschrieben wird (um das später in den MSR Bereich zu verschieben) sind die MSR Platten heute viel besser geworden und fallen nur bei längerem konstanten Schreiben ab, das dann aber drastisch. Bei einem normalen Platten Benchmark der ein parr Minuten läuft fällt nichts auf. Damit sind sie aber für Raid ungeeignet. Ein Raid Rebuild und ein Multiuser Server mit konstanter Schreiblast gehört zum normalen NAS Betrieb. Auch wenn Open-ZFS mit sorted/sequential Resilver einen Raid Rebuild heute deutlich schneller kann als noch vor 1-2 Jahren (Solaris und native ZFS konnte das schon viel früher), bleibt das Problem gravierend.
Entscheidend ist, dass die Umstellung quasi unbemerkt erfolgt ist. Würde man sich bewußt für MSR entscheiden um zum gleichen Preis mehr Kapazität zu haben, wäre das sicher ok. Die jedoch einfach ohne Kommentar als NAS Platten zu verkaufen ist Irreführung der Verbraucher die gar nicht davon ausgehen, dass ein wesentlicher NAS Betriebszustand Probleme bereitet.
Erinnert irgendwie an Dieselgate. Auch da wurde der Verbraucher irreführend im Glauben gelassen dass der bessere Abgaswert ohne Abstriche beim Verbrauch angeboten wird. So wie hier dass deutlich mehr Kapazität zum gleichen Preis ohne Performance und Nutzungseinschränkungen angeboten werde.
ich bastele auch gerade mit Software RAID bzw. ZFS in ESXi 6.7 herum. Allerdings läuft es noch nicht zu 100%
Dank @Luckysh0t bin ich auf die Idee mit der Storage VM aufmerksam gemacht worden.
Napp-it sah aufgrund der bequemen Bedienung per Webinterface recht vielversprechend aus. Die SSDs sind per PCIe Passthrough direkt in der VM.
Meinen ursprünglicher Post der Vollständigkeit halber findet ihr hier:
Hallo zusammen, ich würde gern meinen Server aufrüsten, da mir die Festplatten Performance mittlerweile zu gering ausfällt. Bei der Umsetzung gibt es ...
administrator.de
Hintergrund:
Als VM Speicher nutze ich aktuell noch sechs SAS 300G Platten. + LSI RAID Controller. Diese wollte ich durch vier M.2 NVMe SSDs ersetzen.
Leider unterstützt ESXi kein Software RAID, weshalb auch ein neuer Controller nötig wäre. NVMe Controller sind aber mit ~ 1000€ noch verdammt teuer, also fällt das raus.
Daher bleibt nur Software RAID übrig. Also habe ich die vier Samsung 970 EVO Plus 1TB SSDs und den ASUS Hyper M.2 x16 Adapter bestellt.
Darin läuft ZFS mit 2x Mirror + Stripe (RAID 10). Das ZFS habe ich per NFS oder iSCSI über einen internen vSwitch + VMKernel Port wieder im ESXi eingebunden (So wie in der Anleitung All-In-One).
Soweit die Theorie. Das klappt auch einigermaßen. Allerdings erreiche ich nicht annähernd die SSD Performance. Über ATTO Benchmark in einer Windows VM ~ 1 GB/s.
Mit Sync = Disabled sind es immer hin 1,8 GB/s.
NFS (disabled sync writes)
iSCSI (sync writes):
Ein iperf3 Test VM <=> VM liegt auch „nur“ bei ~ 21 Gbit/s und gegen 127.0.0.1 auf der gleichen VM ~ 30 Gbit/s.
Das sollte eigentlich auch mehr sein!?
Wenn ich die SSDs aber direkt per Passthrough in einer Windows VM einrichte, liegen die Geschwindigkeiten bei 3,2GiB/s r/w Single Disk und bei 5,9GiB/s r/w als RAID 10:
Windows Server 2019 auf Proxmox Nested mit PCIe Passthrough (sync writes):
Also irgendwas im Netzwerkstack zwischen Storage VM Solaris und ESXi limitiert, obwohl ich im Internet schon einige Erfolge zu dieser Umsetzung gesehen habe. Zum Beispiel haben einige Leute schon 40 oder 100Gbit Fibre Channel in Benutzung.
Vor allem finde ich das Maintenance ziemlich klasse, wenn Storage und Hypervisor getrennt sind. ESXi läuft nach dem Start im RAM. Außerdem muss man da nicht viel konfigurieren. Daher nach einem Crash innerhalb von 10 Minuten wieder startklar. Genauso der Storage: Solaris Appliance neu hochladen und schon ist das ZFS wieder startklar.
Nur als Test wollte ich auch mal Proxmox und Hyper-V als Baremetal auf dem Host ausprobieren. Hier wäre ZFS bzw. Software RAID direkt im Hypervisor möglich. Daher entfällt eine Storage VM.
Allerdings weiß ich nicht, wie die Performance als Hypervisor bei KVM oder Windows ausfällt. Wenn die wiederum langsam ist, bringt das NVMe Storage nichts, weil dann die VM nur mittelmäßige Disk Performance liefert.
VMware hat hier mit ESXi schon eine echt gute Lösung auf dem Markt.
Mit Desktop SSD/NVMe hat man eigentlich immer Probleme mit sync wite und dauerhaftem Schreiben. Da brechen die regelmäßig ein im Vergleich zu Datacenter Modellen oder gar Intel Optane.
Wenn man NFS und iSCSI vergleicht, immer gleiche Sync Einstellungen nehmen (Dateisystem fest auf sync on/off stellen). Mit sync=default (auto) stellt man sync bei iSCSI mit der writeback cache Einstellung ein. (writeback on=sync off).
Tunen kann man tcp mit der Anzahl der Puffer oder mit Junboframs. Letzeres muss aber überall aktiviert sein (Server, ESXi vswitch, Switche, Clients) und kann dann dennoch noch Probleme machen.
NFS und iSCSI haben als Vorteil, dass man damit den Storage von überall erreicht (AiO intern oder extern). Diese Flexibilität ist allerdings etwas langsamer als "lokaler" Storage ohne Netzwerkstack dazwischen z.B. ESXi local datastore oder lokaler ZFS Speicher für Proxmox VMs oder OmniOS VMs via Zonen, KVM, LX oder Bhyve.
Mit größerem Ramcache und dem Mediacache Bereich auf den zunächst ohne MSR geschrieben wird (um das später in den MSR Bereich zu verschieben) sind die MSR Platten heute viel besser geworden und fallen nur bei längerem konstanten Schreiben ab, das dann aber drastisch. Bei einem normalen Platten Benchmark der ein parr Minuten läuft fällt nichts auf. Damit sind sie aber für Raid ungeeignet. Ein Raid Rebuild und ein Multiuser Server mit konstanter Schreiblast gehört zum normalen NAS Betrieb. Auch wenn Open-ZFS mit sorted/sequential Resilver einen Raid Rebuild heute deutlich schneller kann als noch vor 1-2 Jahren (Solaris und native ZFS konnte das schon viel früher), bleibt das Problem gravierend.
Mal folgendes Idee: Man hat einen Pool mit SMR Platten. Könnte man bei einem Plattenausfall nicht für den Rebuild eine CMR Platte nehmen? Damit dürfte die Zeit für einen Rebuild doch identisch sein wie bei einem reinen CMR Pool da von den SMR Platten nur gelesen wird.
Mal eine ganz abwegige Frage
kann man ein ZFS - Send eigentlich unterbrechen und Später fortsetzen?
Hintergrund: Ich könnte das alte NAs jetzt auf 10 GBe hochrüsten.
Hatte ich mir in der Solaris Doku mal angesehen und soll möglich sein mit einem Parameter (glaube -C).
Aber nie selbst getestet und weiß auch nicht, ob es für alle Derivate gilt.
mal eine Frage: rein technisch spricht nichts gegen ZFS on Linux? Das oft geäußerte Misstrauen bezieht sich nur darauf, dass es keine GUI gibt, was mir allerdings egal ist? Oder gibt es irgendwelche technischen Gründe die dagegen sprechen (ich habe keine gefunden)
resumable zfs send -t resume_token gibt es ca seit 4 Jahren,
vgl https://www.illumos.org/issues/2605 (vor allem die darin enthaltenen erklärenden Links und Videos von Matt Ahrens). Sollt eigentlich in jedem Open-ZFS seit dieser Zeit enthalten sein.
Ich nutze das normalerweise nicht
Prinzipiell müsste man wohl bei receive -s ein Token abfragen und bei send -t angeben.
mal eine Frage: rein technisch spricht nichts gegen ZFS on Linux? Das oft geäußerte Misstrauen bezieht sich nur darauf, dass es keine GUI gibt, was mir allerdings egal ist? Oder gibt es irgendwelche technischen Gründe die dagegen sprechen (ich habe keine gefunden)
Die hohe Anzahl an ZFS Entwicklern aus dem Linux Bereich hat nicht nur dafür gesorgt, dass ZFS on Linux mit Illumos (freier Solaris Fork, da wurde das freie ZFS übernommen nachdem Oracle Solaris geschlossen hatte) gleichgezogen ist sondern dass heute viele neuen ZFS Features auf Linux entwickelt werden und dann in Illumos übernommen werden. Ein aktuelles Linux ist damit was ZFS angeht, auf allerneuestem Stand.
Das Problem bei ZFS on Linux ist traditionell dass es unter jeder Distribution anders installiert wird, anders upgedated wird und andere Probleme hat oder andere Release Versionen. Man sollte daher nicht von Linux reden sondern davon wie gut es in Debian, Ubuntu, RH oder anderen Distributionen integriert ist und funktioniert - auch nach einem Update. Wegen der GPL kann ZFS ja nicht in den Kernel aufgenommen werden.
Unter einem aktuellen Debian oder Ubuntu ist ZFS als Dateisystem technisch kein Problem und vergleichbar zu Illumos, teilweise sogar ein paar Wochen voraus.
Das Hauptproblem bei Linux sehe ich in der Vielfalt der Distributionen und Dateisysteme. Das "Tut einfach" von ZFS aus der Solaris Welt, mit seit 15 Jahren problemlosem Booten von ZFS mit bootfähigen Snaps, der Integration in das OS und der Integration der Sharing Dienste FC/iSCSI, NFS und SMB in den Kernel, das OS und das Dateisystem fehlt halt. Da ist halt das Solaris OS ab 2005 um ZFS only herum entwickelt worden und nicht ein später hinzugefügtes Dateisystem von vielen. ZFS ist halt nicht nur Dateisystem sondern Raidmanager, Volumemanager und unter Solarish zusätzlich Sharemanager mit integriertem und von Sun selbst entwickelten ZFS/kernelbasierten NFS und SMB Server (statt SAMBA als Dritt-Tool). Dieses Maß an Integration kann es unter Linux nicht geben, dazu ist es zu allgemein aufgestellt und nicht so das Spezial-OS für ZFS wie es Solarish ist.
Die GUI für ZFS ist sekundär. Da kommen ja auch gerade einige Optionen auf (Proxmox, Cockpit, Webmin, OMV, TrueNAS). Allerdings sehr Distributionsabhängig.
mal eine Frage: rein technisch spricht nichts gegen ZFS on Linux? Das oft geäußerte Misstrauen bezieht sich nur darauf, dass es keine GUI gibt, was mir allerdings egal ist? Oder gibt es irgendwelche technischen Gründe die dagegen sprechen (ich habe keine gefunden)
Gibt auch keine, große Teile der Entwicklung finden jetzt bevorzugt in ZoL statt und werden dann nach Illumos/FreeeBSD/etc portiert.
In ZoL stecken umgekehrt auch die letzten Jahrzehnte der Entwicklung von ZFS, angefangen von Opensolaris bis heute.
cu
Sieht man auch an "Open-ZFS"
Zu Beginn war das die Koordinierungsplattform damit neue ZFS Features möglichst gleichzeitig ihren Weg in Free-BSD, Illumos und Linux finden. Die komplette Open-ZFS Entwicklung fand ursprünglich in Illumos statt.
Aktuell ist Open-ZFS das Upstream Repo für das freie ZFS. Die Linux und Free-BSD ZFS Entwicklung ist darin aufgegangen. Illumos übernimmt die Features recht schnell. Mittelfristig wird wohl die gesamte Open-ZFS Dateisystem Entwicklung bis auf die plattformspezifischen Besonderheiten von Illumos (ZFS/kernelbasierter SMB Server, nfs4 ACL mit Windows sid) die über das eigentliche ZFS Dateisystem hinausgehen auf dem Open-ZFS Repo stattfinden.
resumable zfs send -t resume_token gibt es ca seit 4 Jahren,
vgl https://www.illumos.org/issues/2605 (vor allem die darin enthaltenen erklärenden Links und Videos von Matt Ahrens). Sollt eigentlich in jedem Open-ZFS seit dieser Zeit enthalten sein.
Ich nutze das normalerweise nicht
Prinzipiell müsste man wohl bei receive -s ein Token abfragen und bei send -t angeben.
Habe da auch selbst was gefunden. Soweit ich das verstehe muß man das von vornherein einplanen, damit überhaut ein Token gespeichert wird.
You can use the -s option of zfs receive which will save a resumable token on the receiving side if the transfer fails. It depends if you are using netcat (nc) or SSH. On the recv machine(netcat only):
nc -l <port> | zfs receive -s -v tank/dataset On the send machine:
Start with the usually send:
zfs send -v snapshot | nc <host> <port>
zfs send -v snapshot | ssh ... zfs receive -s -v tank/dataset If the transfer fails, go on the recv machine and type:
zfs get all tank/dataset Get the receive_resume_token and go on the send machine:
zfs send -v -t <token> | nc <host> <port>
zfs send -v -t <token> | ssh ... zfs receive -s -v tank/dataset
Here you go
Naja Heute sollte Halbzeit sein, wird vermutlich aber erst Übermorgen eintreten, die errechneten knapp 12 Tage werden wohl nicht reichen, werden wohl eher 16 Tage, Bin jetzt bei 53,3T von ca. 126T , um die 9T/Tag werden gesendet
ich hab derzeit auf omnios ein Z1 mit 3x2TB laufen. Das wird nun langsam voll und ich möchte aufrüsten.
Welche Empfehlung habt ihr Mirror oder Z1(3x4TB)?
Was mir noch aufgefallen ist, was ich mir aber nicht erklären kann ist folgendes:
Ich müsste doch bei einem Z1 nur knapp 3,9TB zu verfügung haben oder irre ich mich? .... Wer kann mich mal aufschlauen
Doch, das passt, das sind quasi Roh-Zahlen ohne Redundanz gerechnet. Bsp. 4x 1.92 TB RaidZ1:
Code:
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
ssdpool 6.94T 2.72T 4.21T - - 6% 39% 1.00x ONLINE -
Schon die 6.94T sind natürlich weniger als 4x1.92. Frei verfügbar ist natürlich deutlich weniger, da davon nochmal ca. 1.9T Redundanz und 504G RFRES abgehen.
Dennoch scheinen die Zahlen nicht ohne weiteres stimmig, so aus napp-IT "Pools":
Code:
Pool VER RAW SIZE/ USABLE ALLOC RES FRES AVAIL zfs [df -h/df -H]
ssdpool 5000 6.94T/ 4.9TB 2.72T - 502G 2.90T [ /]
Vermutlich spielt die Kompression auch noch etwas rein.
Unter Pools (zpool list) wird die Kapazität des Pools ohne Redundanz angezeigt. Die Einheit bei ZFS ist T (Tebibyte). Das sind grob ca 10% weniger als wenn man das in Terabyte angibt. (https://en.wikipedia.org/wiki/Tebibyte).
Wenn man die verfügbare Kapazität eines leeren Pools (unter Abzug der Redundanz) mit zfs list anzeigen läßt, so muss man für den verfügbaren Platz davon noch eine kleine Default Reservierung abziehen, damit ZFS keine gravierenden Probleme mit einem überlaufenden Pools hat. Napp-it fügt dazu noch eine 10% Pool Reservierung hinzu damit man immer eine abschaltbare Reserve hat.
Ein Z1 Pool aus 3 x 2TB hat damit nach Abzug der Redundanz ca 4 TB = ca 3.6T, nach Abzug der internen Reservierung ca 3.5T und nach Abzug der napp-it Pool Reservierung ca 3.2T verfügbar.
Wenn der Pool nicht leer ist, können snaps und zvols neben den Daten zusätzlich Platz belegen.
wg Mirror vs 3 Platten in Z1
Die Ausfallwahrscheinlichkeit des Z1 ist minimal schlechter. Auch ist die Leseperformance des Mirrors besser. Man hat allerdings nur 33% Verlust wegen der Redundanz. Beim Mirror sind das 50%. Z1 ist damit meist günstiger im Preis.
Wenn man aber deutlich mehr als 3 Platten hat, sollte man von Z1 Abstand nehmen und stattdessen ein Z2 aufsetzen.
Okay, dass heißt jetzt für zfs List, das ich schon mein Maximum erreicht habe oder „free“ die für mich ausschlaggebende Kenngröße?
Verwende nur OmniOs ohne Napp-It.
www.servethehome.com
www.pcgameshardware.de
administrator.de
docs.oracle.com
