[Sammelthread] ZFS Stammtisch

Ok danke für die TIpps bereits.
Also ich werte meinen 12x HDD Pool rausreissen, und daraus 4x 16TB HDDs in einem mirrored + striped vdev machen. Das gleiche mache ich mit dem 3x SSD RAID-Z Pool, da kommt noch eine dazu, und mache dann das gleiche.
Ich nutze als SSDs 1TB Platten vom Typ Samsung 870 EVO. Ich habe eine 4TB Variante davon nun in meinem Rechner, hat die 4TB QLC NVMe SSD ersetzt, weil das Ding kontinuierlich mit 480MB/s schreiben kann. Meine QLC NVMe SSD geht nach irgendwie 200GB auf unter 100MB/s runter, das ist nicht mehr zumutbar bei meinen Datenmengen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@Luckysh0t Ich hab Napp-IT auf OmniOS installiert.

@gea Ich kann leider kein Perl und verstehe auch dein Script nicht im Detail.

Kann man dein Script auch über Komandozeile mit entsprechenden Parametern triggern? Also quasi das, was die Weboberfläche macht, auch über SSH anstoßen? Das wäre ja dann eine erprobte und zuverlässige Methode, wie man über SSH unlocken und sicherstellen kann, dass SMB/NFS sofort wieder funktioniert.

Falls das nicht so ohne weiteres geht:

Reicht es aus, wenn man in das Makro einfach noch die share-Befehler hinzufügt? https://docs.oracle.com/cd/E23824_01/html/821-1448/gayne.html#gayno

Share Befehle bei Solaris 11.4 und OmniOS sind unterschiedlich. Bis 11.2 waren die noch identisch.
https://docs.oracle.com/cd/E23824_01/html/821-1448/gayne.html#gayno

Wenn ich das aus deinem Perl-Script richtig raus lese, setzt dein Perl-Skript "nur" die legacy-Befehle zfs set sharenfs=on tank/fs1 ab und nicht die new share syntax. Ist das richtigt oder müsste man sonst noch was beachten?

set sharenfs=on schaltet die Freigabe ein wenn sie davor aus war

Oder gibts sowas wie ein "systemctl restart smb/nfs" ?

svcadm macht Servicemanagement in Solarish

siehe Menüs Services für NFS und SMB z.B.
svcadm enable -r smb/server
svcadm disable smb/server
svcadm refresh smb/server
svcadm clear smb/server

siehe Menü Scripts Services > SMB oder NFS
/var/web-gui/data/napp-it/zfsos/02_Services=-lin/15_SMB/action.pl
/var/web-gui/data/napp-it/zfsos/02_Services=-lin/11_NFS/action.pl
 
ZFS ACLs rekursiv ändern?

Tach auch!

Bin auf OmniOS CE r151038, hab diverse SMB shares mit ZFS ACLs und müsste diese alle "zurücksetzen" - genauer gesagt:
auf
Code:
everyone@:list_directory/read_data:allow /tank/blah
umstellen, so dass ich das ich alle Dateinen im (Heim-)Netzwerk temporär auf ein anderes System umkopieren kann.
Warum? (langes Thema - anderer Thread kommt noch... ;-) )

Hat da jemand da ein Skript parat? Da sind zu viele Dateien drauf, als dass ich die alle händisch updaten kann.

Danke!
TLB
 
Entweder in napp-it Menü Dateisysteme > ACL auf Dateien gehen, dann werden ACL angezeigt. Unter der Anzeige gibt es die Option "reset ACL". Damit kann man auch rekursiv die ACL zurücksetzen, entweder auf einfache Sachen wie everyone=modify oder root only. Alternativ kann man auf den aktuellen Ordner speziellere ACL anwenden und die rekursiv setzen.

Oder
In Windows per SMB als root verbinden und über "Eigenschaft > Sicherheit > Erweitert" Rechte setzen. Geht auch da dass man Rechte auf den aktuellen Ordner setzen kann und die rekursiv anwendet (nachdem man die Vererbung deaktiviert)
 
Ich hab das Makro von oben nochmal angepasst. Es funktioniert jetzt mit SMB (inklusive ABE) und für NFS shares.

@Luckysh0t Das Makro ist für OmniOS getestet (und funktioniert daher wahrscheinlich auch bei Illumos und OpenIndiana), ziemlich sicher aber nicht ohne Anpassung mit Solaris. Ich würde aber vemuten, dass du das Makro auch für Solaris einfach anpassen kannst, indem du die nachfolgenden Befehle ersetzt:

"zfs sharesmb=off Tank1/cryptotest"
"zfs sharesmb=name=cryptotestshareSMB,abe=true Tank1/cryptotest"
durch
# zfs set share=name=cryptotestshareSMB,abe=true,path=/cryptotestshareSMB,prot=smb Tank1/cryptotest
# zfs set sharesmb=on Tank1/cryptotest

und

"zfs set sharenfs=off Tank1/cryptotest"
"zfs set sharenfs=on Tank1/cryptotest"
durch
# zfs set share=name=cryptotestNFS,path=/cryptotestNFS, prot=nfs Tank1/cryptotest
# zfs set sharenfs=on Tank1/cryptotest


Code:
; Skript für TeraTerm um auf Illumos / OpenIndiana / OmniOS verschlüsselte DataSets
; über SSH zu entschlüsseln, mounten und als SMB/NFS-Share freizugeben.
;
; Datum / Version 2022-01-04
;
; Die Syntax ist auf Illumos basierte Systeme ausgelegt und auf OmniOS getstet.
; Solaris verwendet teilweise eine andere Syntax und wird wahrscheinlich nicht ohne
; Anpassung funktionieren.
;
; Dieses Skript muss in einer Textdatei mit Endung .ttl abgespeichert und mit TeraTerm ausgeführt werden.
; TeraTerm und Infos dazu gibts hier: https://ttssh2.osdn.jp/
; Befehle für TeraTerm-Makros gibts hier: https://ttssh2.osdn.jp/manual/4/en/macro/command/index.html
;
; Relevante Doku zu Illumos/Openindiana/Omnios:
; Beschreibung der Sharemanager-Properties wie z.B. ABE: https://illumos.org/man/1M/sharemgr
; Die Solaris-Syntax ist hier zu finden: https://docs.oracle.com/cd/E23824_01/html/821-1448/gayne.html
;
; Erläuterung des nachfolgenden Beispielscripts:
;
; Es wird eine SSH-Verbindung zu einer Napp-IT-Installation auf einem OmniOS-Host
; über SSH aufgebaut. IP:Port des System lautet 192.168.1.100:22,
; die Logindaten sind root / p4ssw0rd . SSH muss dazu auf OmniOS aktiviert werden.
;
; Das Skript bindet ein verschlüsseltes Dataset "cryptotest" welches auf dem Pool
; "Tank1" liegt ein und verwendet zum entschlüsseln den Key "zfskeyupto64chars".
; Das Dataset wird als SMB-share mit dem Namen "cryptotestshareSMB" und
; gleichzeitig als NFS-share mit dem Pfad /Tank1/cryptotest freigegeben.
; Für SMB wird zudem noch ABE aktiviert.


; --- TeraTerm-Einstellungen ---

; Versteckt das TeraTerm Makro-Statusfenster
show -1

; --- Makro für OmniOS ---

; Verbindung zu Host aufbauen, Syntax: connect '<Host-IP>:<Port> <Protokoll> <Authentifizierungsart> <Username> <Passwort>'
connect '192.168.1.100:22 /ssh /auth=password /user=root /passwd=p4ssw0rd'

; Entschlüsseln und mounten

; Dataset 1 Entschlüsselung START ------------------------------------------
; Entschlüsseln und mounten von Dataset 1 START
; FÜR MEHRERE DATASETS DIESEN BLOCK VON START BIS ENDE UNTER DIESEN BLOCK KOPIEREN

mpause 500
wait ':~#'
sendln 'zfs load-key -r Tank1/cryptotest'                                        ; Initialisiert das setzen des Datasetkeyspassworts
wait 'Enter passphrase for'
sendln 'zfskeyupto64chars'                                                                    ; Gibt den Key ein
wait ':~#'
mpause 500
sendln 'zfs mount Tank1/cryptotest'                                                ; Mountet das Dataset mit dem zuvor gesetzten Key
wait ':~#'
mpause 500
sendln 'zfs sharesmb=off Tank1/cryptotest'                                        ; Deaktiviert vorsorglich bereits existierende SMB-shares dieses Datasets
wait ':~#'
mpause 500
sendln 'zfs sharesmb=name=cryptotestshareSMB,abe=true Tank1/cryptotest'         ; Aktiviert den SMB-Share mit ABE
wait ':~#'
mpause 500
sendln 'zfs set sharenfs=off Tank1/cryptotest'                                    ; Deaktiviert vorsorglich bereits existierende NFS-shares dieses Datasets
wait ':~#'
mpause 500
sendln 'zfs set sharenfs=on Tank1/cryptotest'                                    ; Aktiviert den NFS-Share
wait ':~#'
; Dataset 1 Entschlüsselung ENDE --------------------------------------------



; Dataset 1 Entschlüsselung aufheben START ------------------------------------------
; Nützlich wenn man zum testen gleich wieder unlocken möchte
;wait ':~#'
;sendln 'zfs sharesmb=off Tank1/cryptotest'
;wait ':~#'
;sendln 'zfs set sharenfs=off Tank1/cryptotest'   
;wait ':~#'
;sendln 'zfs unmount Tank1/cryptotest'
;wait ':~#'
;sendln 'zfs unload-key -r Tank1/cryptotest'
; Dataset 1 Entschlüsselung aufheben ENDE ------------------------------------------



; Beendet TeraTerm nach N Sekunden
pause 5                                                                            ; 5 Sekunden warten bevor TeraTerm schließt
closett                                                                            ; Schließt TeraTerm
 
Gibt es aktuelle Empfehlungen an SSDs (SATA, M2(SATA), M2(PCIe) oder PCIe) die halbwegs günstig und haltbar in einem ZFS-Mirror (VM-Storage) eingesetzt werden können?
Größe so 512GB - 1TB wäre ideal.
 
Kommt halt auf die Art von Last an die deine VMs verursachen.

IMHO: Würde mal sagen im Heimbereich tuts so ziemlich jede SSD die du auch in einem normalen Desktop-PC stecken würdest der 24/7 läuft (sofern dein ZFS auch 24/7 laufen soll). Vielleicht nicht das billigste vom billigen, aber jede Samsung Evo oder Pro sollte da ja schon ausreichen. Im Grunde ist ja der Vorteil von ZFS schon, dass man da jetzt nicht unbedingt so spezielle Hardware braucht wenn man auch keine speziellen Anforderungen hat. Für ein paar VMs auf denen n Teamspeakserver, private Nextcloud, sonst was in der Art läuft braucht man ja keine Highend-Performance.
Wenn die Anforderungen spezielle sind (Videobearbeitung, Datenbankserver, sonst was...) dann steigt natürlich auch die Anforderung an die SSD.

Also lass mal raus, was deine VMs so tun sollen und wieviel VMs da so laufen sollen.
 
Zuletzt bearbeitet:
Hallo zusammen,

hat es hier eigentlich Mal jemand geschafft, funktionierenden Zugriff von Android-Devices auf OmniOS SMB-shares zu realisieren, am Besten noch eines Domain-joined OmniOS?
In der Vergangenheit, als es unter OmniOS noch nur SMB1 gab, hat das einigermaßen funktioniert. Dann kam die eigentlich auch von mir sehnlichst erwartete SMB2-Implementierung, ab dann aber waren Zugriffe über die meisten Android Apps, die keine eigenständige (systemunabhängige) SMB-Client-Implementierung mitbrachten, nicht mehr möglich. Hat mich zunächst nicht groß gestört und die wenigen Male die ich es Abseits von Kodi benötigt habe, hat mir der X-plore Filemanager (der Einzige den ich auftat, der mit >= SMB2 zurecht kam/kommt) gute Dienste geleistet.
Aktuell versuche ich das jedoch Mal wieder ans Laufen zu bringen, um eine Nvdia Shield TV mit dort laufendem Plex Server für Transcoding von 4k-Quellmaterial zu testen.
Es will mir aber ums Verrecken nicht gelingen, die Shares auf der Shield zu mounten. Das Mounten schlägt einfach ohne irgendwelche Fehlermeldungen fehl bzw. es wird wiederholt nach den Login-Daten gefragt. Alle Hinweise zu Problemen dieser Art deuten immer auf irgendwas bzgl. NetBIOS hin (z.B. bei ähnlich gelagerten Problemen unter TrueNAS). Bislang dachte ich, das geht eigentlich in die Richtung von "netbios_enable=true", das uns in den Anfängen der OmniOS >=SMB2-Implementierungsphase dann das Browsen der Freigaben ermöglicht hat, leider zeigt das hier aber keinerlei Wirkung.
Jemand noch eine Idee?

Danke
ces
 
Also mit FX Explorer have ich keine Probleme auf einen aktuellen OmniOS ZFS SMB Share eines Domain joined Systems zuzugreifen.
 
Mit x-plore ebenfalls kein Problem (oh, hattest Du ja auch nicht).

Ich hatte aber Probleme mit einer Reihe von Android Apps, vermutlich weil sie nur SMBv1 sprachen.

Auch einige angeblich SMBv2 fähige machten Anfangs Probleme.
 
Wenn die Anforderungen spezielle sind (Videobearbeitung, Datenbankserver, sonst was...) dann steigt natürlich auch die Anforderung an die SSD.
Nein, ich würde sagen keine speziellen Anforderungen! Vielleicht 2 Linux VMs und 2 Windows mit maximal normaler Workload.

Ich dachte vor allem auch im Hintergrund an die Anforderung der SSD für ZFS.
Oft habe ich schon gelesen, dass es bei ZFS unbedingt eine SSD mit "Power Loss Protection" sein muss, weil es sonst sein kann, dass die Daten im Cache beim Stromausfall weg sind.
ZFS ist zwar ein copy-on-write Dateisystem, aber das ist auch nur dann was wert, wenn die SSD wirklich alles weggeschrieben hat , was sie dem Host rückgemeldet hat.
Die Frage ist, ob günstige SSDs nicht schon zurückmelden, dass es weggeschrieben ist, wenn es noch im flüchtigen Cache liegt?!
 
Bedenke aber auch, dass bei ZFS (aber auch anderen Dateisystemen) bei Stromausfall evtl. auch noch aus asynchronen Schreibvorgängen x GB an Daten im Writecache im Ram stehen und überhaupt noch auf den Schreibvorgang vom Ram auf die SSds warten....die sind dann weg wenns Dir den Strom wegzieht... da hilft Dir copy-on-write nix.
Drum hab ich neben SSDs mit powerloss-Protection auch noch ne USV vor der Kiste. Minimiert das Risiko weiter.

Am Ende ist es immer ein Balancieren mit Wahrscheinlichkeiten und Budget.
 
Die Frage ist, ob günstige SSDs nicht schon zurückmelden, dass es weggeschrieben ist, wenn es noch im flüchtigen Cache liegt?!

Die Frage dahinter lautet ob der Hersteller auf Performance oder Sicherheit optimiert hat. Nur bei Datacenter SSD die PLP garantieren kann man von letzterem ausgehen. ZFS hat dann auch keine Moglichkeit das abzufangen - im Gegensatz zum ZFS eigenen Schreibcache den man mit sync write absichern kann.

Für VM Storage würde ich PLP bei SSD Storage + sync write als Muss sehen.
 
Für VM Storage würde ich PLP bei SSD Storage + sync write als Muss sehen.
Das habe ich fast befürchtet. Danke für deine Rückmeldung und fundierte Aussage!(y)
Da steigt der Preis pro TB natürlich enorm. Es benutzten scheinbar zwar viele auch bei ZFS im Heimbereich normale SSDs, aber da will ich eigentlich kein Risiko eingehen!
Wäre ggf. eine USV eine Alternative um sich die teureren PLP-SSDs mit gutem Gewissen sparen zu können oder macht das am Ende auch keinen Sinn?
 
Wäre ggf. eine USV eine Alternative um sich die teureren PLP-SSDs mit gutem Gewissen sparen zu können oder macht das am Ende auch keinen Sinn?
Ergibt keinen Sinn.

USV ist natürlich ein weiterer Schutz gegen Data loss, s.o., aber ersetzt keine PLP, jdfs nicht für Zwecke der Performance oder Haltbarkeit der SSDs
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
PLP + hohe Kapazität + viel write iops bei 4k + viel TBW kostet natürlich
In der Tat.
Was mich nur wundert ist, dass die Enterprise SSDs im Vergleich zu den Consumer-SSDs bei den Read-IPOS mithalten können. Bei den Write-IPOS meist gut um Faktor 5-10 schlechter sind. Ist wahrscheinlich der PLP und dem somit kleineren Cache geschuldet oder?
Naja, werde ich wohl in den saueren Apfel beissen müssen oder ggf. versuchen auf dem Gebrauchtmarkt etwas zu finden, aber das ist sicher nicht ganz einfach.
Aber vielen Dank für euere Hilfe.
 
Nein, bei Consumer SSD wird immer das erreichbare Maximum angegeben, welches aber nur kurzzeitig und unter bestimmten Bedingungen erreicht wird. Marketingsprech halt: "schaut her wie super duper mega unsere SSD ist". Bombardierst Du z.B. eine richtig gute Consumer SSD wie die 850Pro z.B. dauerhaft mit Schreibzugriffen, brechen Dir diese gnadenlos ein und können Dir auf Sync-Writes auf 5-10 MB/s absacken. Haben hier im Forum schon welche erfahren.
Kurzzeitige "Super Werte" unter Crystaldiskmark, ASSSD, ATTO und wie die Tools alle heissen liefert Dir mittlerweile fast jede Billo-SSD. Realworld-Betrieb und v.a. dann Datacenter-Betrieb schaut ganz anders aus.

Bei Enterprise SSDs wird in der Regel (aber auch nicht immer) die dauerhaft erreichbaren IOPS angegeben. Wichtig auch: Nicht geizhals oder anderen Shoppingportalen blind glauben, sondern immer die Datenblätter lesen. Verschiedene Hersteller und Modelle werden teilw. unterschiedlich gemessen und angegeben.

Die angegebenen maximalen Schreibwerte der beiden SSD-Klassen sind daher nicht vergleichbar.
 
Zuletzt bearbeitet:
Bei Enterprise SSDs wird in der Regel (aber auch nicht immer) die dauerhaft erreichbaren IOPS angegeben. Wichtig auch: Nicht geizhals oder anderen Shoppingportalen blind glauben, sondern immer die Datenblätter lesen. Verschiedene Hersteller und Modelle werden teilw. unterschiedlich gemessen und angegeben.
OK, danke. Das erklärt es dann natürlich. Das Datenblatt schaue ich mir natürlich an. Trotzdem vielen Dank für den Hinweis.

Leider findet man zu den Enterprise SSDs nicht mal 5% der Reviews oder Tests im Netz.
Somit ist es auch viel schwerer ggf. rauszufinden wie das Vorgängermodell ggf. hieß um es im Gebrautmarkt zu suchen.
Falls also wer hier ggf. eine gute Seite mit Tests zu Enterprise SSDs hat dann nur her damit! :d
 
Klar ist das rar, weil diese Modelle die meisten User nicht ansprechen. Und diese die auch gar nicht brauchen.
Die Medienreichweite ist entsprechend gering.
Storagereview kannst Du z.b. mal anschauen , Anandtech mag ich auch gern.

Wichtig bei allen Reviews ist: schau vor allem auf Tests bzgl. Konsistenz/Dauerbelastung. Bildschirmhardcopies von den typischen o.g. Consumertests bringen nichts.


Entscheidend ist dann, dass man die richtigen SSDs für die Anforderungen findet. Man kann viel Geld ausgeben und ist dann trotzdem auf dem eigenen Rechner enttäuscht.

Beispiel Intel i750 vor ein paar Jahren. Eine sehr leistungsfähige SSD damals, abgeleitet von den seinerzeitigen höchstperformanten Intel Datacenter PCIe-SSDs.
Die 750 war auch sehr gut, aber nur bei mehrfach parallelen Zugriffen und tiefen Warteschlangen. Entsprechend gut waren auch die einschlägigen Benchmark-Tools.
Im Desktop für Windows eingebaut waren dann viele Leute von der eigenen Realworld-Performance enttäuscht, weil man seltenst tiefere Warteschlangen als 2 hat. Hier hat man die Datacenter-Abstammung und die Auslegung darauf stark gemerkt.
Heutige typische Consumer PCIe-SSDs sind dagegen so ausgelegt, dass sie auch bei kurzen Warteschlangen mehr Leistung abliefern. Drum ist die Intel 750 schnell wieder ohne Nachfolger vom Markt verschwunden (Ausnahme: die Optanes da die bereits ab QD 1 vollen Durchsatz bieten; das wollte aber offenbar niemand bezahlen und so wurden sie eingestellt im Consumerbereich).
Das Verhalten unter welchen Umständen welche Leistung erbracht wird, ist aber nicht genormt; jeder Hersteller und jede Serie kann da anders sein.

Ich hab z.B. Samsung SM863/SM883 als ZFS-Pool im Einsatz. Das sind i.W. die Enterprise-Versionen der 850pro/860pro, haben also ggü. den Consumerversionen zusätzlich Powerloss-Protection, Firmware für konsistente Performance unter Dauerbelastung und auch mehr Overprovisioning. Bei leichter Belastung zeigen sie z.B. ähnlichen Leistungscharakter wie die Consumer-Versionen.


Zusammenfassend: Man muss sich genau ansehen und überlegen, was man für Anforderungen hat und dementsprechend passende SSDs einsetzen. Ansonsten schmeisst man Geld zum Fenster raus und ist evtl. trotzdem enttäuscht. Das gilt für Windows und NTFS und auch für Unixoide Systeme mit ZFS.
 
Zuletzt bearbeitet:
Da mein Anwendungsfall ähnlich ist kann ich dir auch zu den Samsung SSDs mit PLP raten. Für meinen VM-Pool nutze ich eine einzige Samsung PM983 in der 2TB-Variante.

Ja, ist bei nem Defekt halt blöd, aber dafür kann man ja die darauf liegenden Datasets auch einfach auf langsameren Speicher wegsynchronisieren, sofern deine Software das her gibt.
 
ch hab z.B. Samsung SM863/SM883 als ZFS-Pool im Einsatz.
Danke für die Tipps. Die PM-Varianten hatte ich auch schon im Auge. Die SM ist für Homelab fast schon extrem, aber natürlich fast unkaputtbar laut Datenblatt!

Ja, ist bei nem Defekt halt blöd, aber dafür kann man ja die darauf liegenden Datasets auch einfach auf langsameren Speicher wegsynchronisieren, sofern deine Software das her gibt.
Naja der Defekt wäre es gar nicht mal.
Mich hat es irgendwie gereizt die VMs auch auf einem ZFS-Pool zu haben und somit absolute Sicherheit, dass keine Daten korrupt werden können bzw. Bit-rot erkannt und geheilt wird.
Dazu braucht man dann aber leider die teure Enterprise SSD mindestens 2 mal ....! :(
 
also ich habe nen ssd plp mirror für vms und nen mirror aus 2 mx500 von crucial für normale daten. Hätte fast auch die QVO genommen von Samsung wenn der Preis gestimmt hätte war dann aber zum Zeitpunkt des Kaufs doch net so.

Ich schreibe aber auch nicht viel drauf. Der Grund auf ssds zu gehen bei den userdaten war dass es etwa Strom spart im Vergleich zu Hdd und dass es hier und da auch nochmal etwas schneller ist.
Ergo der eine pool ist auf Sicherheit ausgelegt beim anderen nen möglichst gutes Euro/TB Verhältnis.
 
Ich hätt da gern nochmal'n Problem:

Folgendes hat sich letzte Nacht zugetragen:
Mein NFS basierter ESXi VM Datastore auf meiner NAPP-IT Instanz meines AiO Servers ist vollgelaufen.
Das hat natürlich alle VMs zum Crash gebracht.
Also habe ich alle VMs im ESXi deregistriert, den Datastore gelöscht, einige VMs verschoben, Datastore wieder angelegt und VMs wieder registriert.
Läuft wieder!

Dann habe ich mir mal die Storage Situation angeschaut und irgendwie werde ich nicht schlau draus.

Der Pool (ESXi) besteht aus 4 x 150GB SSDs im RaidZ1 und es gibt nur ein Filesystem "vm" für den Datastore.

esxi6.PNG


esxi2.PNG


esxi0.PNG
esxi1.PNG


391GB usable bei 600GB nominell und 556GB Raw Size macht ja soweit auch Sinn.
61GB available im Pool und 22GB GB im Filesystem macht auch Sinn, sollte ja dann 39GB sein, die reserviert bleiben.

D.h. im NAPP-IT Webinterface ist das erstmal schlüssig.

Im ssh Terminal dann das:

esxi3.PNG


das erste df -h . macht Sinn und passt zur Angabe im Webinterface. Das würde bedeuten, dass ungefähr 370GB belegt sein sollten.
Danach sieht man, dass nur das Filesystem "vm" vorhanden ist. Das Verzeichnis .zfs ist leer, d.h. keine Snapshots.
Ein du -s vm ergibt dann 374301854 (kbytes? blocks?) allerdings mit einem "df -h vm" sind es dann in Summe 178GB statt 370GB.

Die 178 GB entsprechen auch der angezeigten Größe in ESXI: (einige der unten angezeigten VMs liegen auf einem anderen Datastore)

esxi4.PNG


Die Frage ist also: Warum ist bei einem Pool mit 391GB usable und nur einem Filesystem auf dem 178GB VMs liegen die Platte quasi voll (89% laut ESXi):

esxi5.PNG



Ich bin sicher, ich hab irgendwo nen Denkfehler, aber ich komm nicht drauf.
ESXi Snapshots existieren übrigens auch nicht für die VMs.

Kann da jemand Licht ins Dunkle bringen?
Liegt es an der Blockgröße?

Danke im Voraus!
 
Thin Provisioning macht dir nen Strich durch die Rechnung?
Oder die ZFS Compression (Falls nicht thin provisioned) schneidet die Nullen weg und deklariert den SPeicher als frei?

Das waeren meine 2 Vermutungen, sofern ich das Problem richtig verstanden habe.
 
Thin Provisioning macht dir nen Strich durch die Rechnung?
Die virtuellen Platten sind Thin-provisioned. Aber was bedeutet das genau? Auch wenn sie Thin Provisioned ist, dann sollten sie zwar kleiner starten, aber nicht über das Limit hinausgehen, oder?
Wenn ich ins napp-it Filesystem (/ESXi/vm/<vm-name>) schaue, dann sind die VM Files auch nicht wirklich größer als die Thin Provisioned Größe, die ich im ESXi sehe.

Und die Summe der virtuellen Plattengrößen die ich in ESXI angelegt habe ist für die 8 VMs auf dem Datastore 175GB.
 
1642090129927.png

Scheint hier ein aehnliches Problem zu geben.
Habe Netto etwa ~20TB zur Verfuegung.

CIFS Spuckt jedoch nur ~10TB aus. Vielleicht klemmts irgendwo an den Diensten.
In meinem Fall TrueNAS FreeNas, denke jedoch dass es bei dir aehnlich laeuft auf Napp-IT.

Vielleicht kann gea etwas dazu sagen.
 
Keine HotSnaps oder gar keine Snaps von dem Dateisystem?
Das war der Hinweis!!!
Ich hab immer im .zfs Verzeichnis auf Poolebene geschaut.
Aber es existierte tatsächlich ein Snapshot mit dem Namen nightly-1640037429_2021.12.20.23.47.00 im /ESXi/vm Filesystem.
Der ist 295GB (effektiv 152GB). Ziemlich genau der Platz nach dem ich gesucht habe. Oh mann ... das Problem war wieder mal 50cm vor dem Bildschirm.

Aber was genau ist das für ein Snapshot, bzw. wodurch ist er erstellt worden. Das ist mir noch nicht ganz klar. Ist das ein Snapshot, der aus meinen Tests mit ESXi Hotsnaps resultiert? Kann ich den einfach "destroyen", um den Platz freizugeben und im aktuellen Status zu bleiben?
 
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