[Sammelthread] ZFS Stammtisch

einstellen kannst du viel, aber der Default ist 0% und damit ist das Verhalten wie in 2. beschrieben.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Aus dem Code:

/*
* The zfs_mg_noalloc_threshold defines which metaslab groups should
* be eligible for allocation. The value is defined as a percentage of
* free space. Metaslab groups that have more free space than
* zfs_mg_noalloc_threshold are always eligible for allocations. Once
* a metaslab group's free space is less than or equal to the
* zfs_mg_noalloc_threshold the allocator will avoid allocating to that
* group unless all groups in the pool have reached zfs_mg_noalloc_threshold.
* Once all groups in the pool reach zfs_mg_noalloc_threshold then all
* groups are allowed to accept allocations. Gang blocks are always
* eligible to allocate on any metaslab group. The default value of 0 means
* no metaslab group will be excluded based on this criterion.
*/
int zfs_mg_noalloc_threshold = 0;
 
The default value of 0 means
* no metaslab group will be excluded based on this criterion.

Heißt doch dass ZFS auf alle vdevs schreiben darf wobei vdevs mit geringerem Füllgrad bevorzugt werden.
Mit einem Wert > 0 kann man erreichen dass ab einem festen Schwellwert ausschliesslich auf das leerere vdev geschrieben wird.
 
Ich würde auch davon ausgehen dass ZFS per default nicht mit einem festen Schwellwert arbeitet sondern lediglich beim Schreiben das vdev mit dem geringeren Füllgrad bevorzugt um mit der Zeit unterschiedliche Füllgrade auszugleichen.

Mit zfs_mg_noalloc_threshold könnte man das ausschliessliche Schreiben auf das leerere vdev erzwingen.
vgl Feature #4081: need zfs_mg_noalloc_threshold - illumos gate - illumos.org

Ganz verbieten darf/kann man das Schreiben wohl nicht, die minimale Allokation muss wohl immer erfolgen. Es gibt ein Video von einem älteren Developer Summit dazu https://youtu.be/UuscV_fSncY. Das Ausbalancieren durch ungleichmäßiges Schreiben ist wohl nicht sehr aggressiv implementiert, deshalb das Flag.
 
Hi Leute,

ich nutze ZFS auf meinem Homeserver (2 x 512 GB im RaidZ0 und 1 x 80GB SSD - RAidZ0 mit einer Disk - für das System)
installiert ist Proxmox und ZFS frisst meinen RAM zum Frühstück. Ich habe eine "zfs.conf" (in /etc/modprobe.d/) erzeugt, um
ZFS einzuschrenken, mittels "options zfs zfs_arc_min=4294967296 options zfs zfs_arc_max=68719476736" und mit
"update-initramfs -u" bestätigt. Aber mein RAM steht immer noch am oberen Limit (~15GB).

Habe ich etwas vergessen? :o
 
Neugestartet? ;)

Btw ist belegter RAM gut. Der soll ja nicht umsonst drin stecken. Und ZFS gibt den frei, wenn jemand anders den braucht (KVM).
 
@gea
Ich meine mich zu erinnern, das du auf deiner Webseite geschrieben hast (ich finds nur nicht mehr..), man solle SAS HDDs vorziehen.Lag das nur an den mechanischen Unterschieden,wenn man eine Backplane nutzt die auch SAS kann, oder gab es da noch mehr Gründe ? Dual SAS ist jetzt für mich zB keine Notwendigkeit.

Da sowohl mein Chenbro als auch der H310 SAS kann, stellt sich jetzt für mich die Frage, ob sich das "rentiert".Da der Aufpreis der Ironwolf Pro zur Enterprise Capacity 4Kn nur ca. 20 € sind.
Oder reicht schon die Tatsache das es 4Kn HDDs sind, als Argument für die "mehr investition" von 40 € (Zwei HDDs).
 
Ich würd die SAS nehmen. Das Protokoll kann auch mehr als SATA.
 
SAS ist etwas robuster was die Datenübertragung angeht und verträgt längere Kabel. Für <1m und eine direct attached Backplane ohne Expander wird SAS aber keine praktischen Vorteile haben (gleiches Plattenmodell Sata vs SAS). Meist gibt es aber nur die besseren Enterprise Platten wahlweise.

Mit vielen Platten und Expander sieht das anders aus. Für ein professionelles Setup würde ich da ausschliesslich auf SAS setzen. Es gibt da ab und an Berichte dass eine fehlerhafte Sata Platte den Expander so stört dass mehrere Platten Fehler zeigen was die Fehlerbeseitigung deutlich erschwert.

4kn vs 512e ist bei ZFS egal. Wird eine Platte als physical 4k erkannt wird der 4k Modus/ Ashift=12 aktiviert.
 
Neugestartet? ;)

Btw ist belegter RAM gut. Der soll ja nicht umsonst drin stecken. Und ZFS gibt den frei, wenn jemand anders den braucht (KVM).

Ja, ich habe natürlich neugestartet. :p

Mir ist auch klar, dass ZFS den RAM wieder frei gibt, wenn er benötigt wird. Dennoch sollte die Einschränkung ja auch funktionieren. Muss ich die "zfs.conf" noch irgendwie einbinden? :rolleyes:
 
Selbst unter Solaris - und darauf ist das interne ZFS RAM caching immer noch ausgelegt kann es manchmal Sinn machen, den maximal genutzten Arc Ram z.B. auf 70% zu limitieren da manchmal der RAM für einige kritischen Prozesse nicht schnell genug freigegeben wird. Insofern finde ich z.B. die feste RAM Zuweisung einer Storage VM unter ESXi mit pass-through ganz angenehm.
 
Schau mal mit folgendem was geladen ist:

cat /sys/module/zfs/parameters/zfs_arc_min
cat /sys/module/zfs/parameters/zfs_arc_max
 
Läuft nun wie es soll (ein Neustart hat wohl nicht genügt, aber nachdem ich die Kiste heute angeworfen habe, hält sich ZFS an die Beschränkung).
 
Zuletzt bearbeitet:
Hi Leute,

ich nutze ZFS auf meinem Homeserver (2 x 512 GB im RaidZ0 und 1 x 80GB SSD - RAidZ0 mit einer Disk - für das System)
installiert ist Proxmox und ZFS frisst meinen RAM zum Frühstück. Ich habe eine "zfs.conf" (in /etc/modprobe.d/) erzeugt, um
ZFS einzuschrenken, mittels "options zfs zfs_arc_min=4294967296 options zfs zfs_arc_max=68719476736" und mit
"update-initramfs -u" bestätigt. Aber mein RAM steht immer noch am oberen Limit (~15GB).

Habe ich etwas vergessen? :o

Dein zfs_arc_max Wert enspricht ~68GB. Dann ist eigentlich klar, dass sich ZFS auch 15GB holt. ;) Ich nehme an du wolltest 6GB Limit setzen, dass wären dann 6442450944 Bytes.

Wenn du auf der Konsole "arcstat" eingibst, kriegt du übrigens eine schöne Zusammenfassung wie groß der ARC aktuell ist (arcsz), und wie groß er aktuell (c) werden dürfte.

Mit "cat /proc/spl/kstat/zfs/arcstats" kannst du alle Parameter des ARCs ausgeben lassen. Hier wären wohl c, c_min (zfs_arc_min) und c_max (zfs_arc_max) am interessantesten.
 
Avago/Broadcom/LSI 9305-16i

Ich habe gerade OpenIndiana 2017.10 mit obigen HBA (P15 IT firmware) installiert.
Der HBA funktionierte, nicht aber die Slotdetection mit dem zugehörenden LSI sas3ircu Tool

Nach etwas Googeln habe ich eine Lösung gefunden.
Bug #6784: sas3ircu doesnt detect LSI SAS 9300-16e - OpenIndiana Distribution - illumos.org

Der Workaround geht auch mit LSI HBA 9300
Da gingen auch ältere sas3ircu Versionen die aber den neuen 9305 nicht unterstützen.
 
Gibt da immer mal wieder lustige Entdeckungen. Zum Beispiel macht mein 9207 (4i4e) mit ESXi-Passthrough Probleme. Ist in dieser Hinsicht - soweit ich weiß - wohl eine extreme Ausnahme.
 
Ich habe mich mal daran versucht eine Zone einzurichten mit OmniOS und Nappit, allerdings scheitert es am Netzwerk. Ich habe nur eine Netzwerkkarte im NAS bge0 und möchte vnic für die VMs benutzen.

Bei Network Physical wähle ich "lx1" aus, Gast OS debian8 beispielsweise.
Versucht man dann in der VM ping 8.8.8.8 sagt er das Netzwerk ist nicht erreichbar.
Eine IP bei der Erstellung der VNIC kann ich über Nappit auch nicht setzen, dann beschwert er sich beim booten dass die Nic schon zur Global Zone gehört.

Ist die Einstellung Network ip_type exclusive falsch?
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Ich verstehe nur nicht was der Unterschied network ip_type zwischen shared IP und exclusive ist, auch nach dem lesen der Docs zu Solaris 11.1 ist mir das nicht klar.

Ich könnte doch den ip type auf shared setzen und den Adapter bge0 benutzen

Die vnic habe ich debian zugewiesen, dennoch verstehe ich nicht wieso ich nichts pingen kann von der VM aus.
 
Zuletzt bearbeitet:
Ich verstehe nur nicht was der Unterschied network ip_type zwischen shared IP und exclusive ist, auch nach dem lesen der Docs zu Solaris 11.1 ist mir das nicht klar.

Ich könnte doch den ip type auf shared setzen und den Adapter bge0 benutzen

Die vnic habe ich debian zugewiesen, dennoch verstehe ich nicht wieso ich nichts pingen kann von der VM aus.

Als ich es das letzte Mal versucht habe ging bei mir LX zones auch nur exclusive. Man braucht also eine vnic. Mit Ping hatte ich kein Problem, lediglich DNS musste ich teils in Linux setzen (wurde nicht aus zone.cfg übernommen)

- - - Updated - - -

Update

Es gibt ein neues OpenIndiana 2017.10
Release notes: 2017.10 Release notes - OpenIndiana - OpenIndiana Wiki

Es gibt ein neues OmniOS Community Edition r151024 stable
Release Notes: omnios-build/ReleaseNotes.md at r151024 · omniosorg/omnios-build · GitHub

Ich habe napp-it um eine Option ergänzt um ein aktuelles sas3ircu für Illumos zu patchen.
Siehe Menü Disks > Disks Location > patch sas3ircu

Nötig ist dieser Patch vor Allem für die neuen Avago/LSI 9305 HBA
Bug #6784: sas3ircu doesnt detect LSI SAS 9300-16e - OpenIndiana Distribution - illumos.org
 
Bei mir scheint es zu funktionieren.

IPS in der zone.cfg stand auf 192.168.1.0 welcher ja das Netz addresiert im Grunde. Habe diesen Wert bei mir auf 192.168.1.14 (IP meiner VM , außerhalb des DHCP Pools) geändert und nun funktioniert es. Weiter musste ich nichts ändern soweit ich mich erinnere, war gestern schon spät.

Der virtual Switch wird wohl von Solaris/OmniOS automatisch eingerichtet sobald mal vnics erstellt, habe ich zumindest so verstanden.

P.S.: Der Bugfix für ReadOnly Dateien löschen unter SMB2 wurde noch nicht gefixt oder? Zumindest hat sich noch nichts getan unter dem erstellen Ticket von damals.
 
Zuletzt bearbeitet:
wieso tragen manche images die bezeichnung "lx"? hat man die Bezeichnung bei den neueren images einfach weggelassen weil ausschließlich die Alten lx im Namen haben?

Und ist die Bezeichnung "LZ zones" im Nappit WebGUI ein Tippfehler??
 
Zuletzt bearbeitet:
wieso tragen manche images die bezeichnung "lx"? hat man die Bezeichnung bei den neueren images einfach weggelassen weil ausschließlich die Alten lx im Namen haben?

Und ist die Bezeichnung "LZ zones" im Nappit WebGUI ein Tippfehler??

zu 1. müsste man in der Mailliste SmartOS-discuss fragen
zu 2. Danke und Ja, das ist ein Tippfehler im Menüset "sol"

Ist mir nicht aufgefallen da ich meist in den Sets "en" oder "de" arbeite
 
Bin seit längerer Zeit im Ausland und hab meinen Server angeschalte zu Hause gelassen (haengt an einer USV, Uptime 140 Tage). Ich hab ihn in letzter Zeit kaum verwendet, heute habe ich mich mal in die napp it Console eingeloggt weil auf einmal verschiedene VMs nicht mehr zur Verfügung waren. Und was sehe ich da. Ich hab 3 SSDs verloren... Ich verwende (besser gesagt ich verwendete) 2x 120GB SSD Mirror Pools (mit Sandisk SSD Plus SSDs).

Wo kann man einsehen, warum die SSDs nicht mehr zur Verfuegung stehen. Ich kann mir kaum vorstellen, dass alle 3 defekt sind... Ich hatte kaum Schreibleistung auf den SSDs :(

Siehe Anhang

1.png

2.png
 
Zuletzt bearbeitet:
Im Moment kann man nur feststellen dass die SSD sich nicht mehr melden.
Wenn das nach einem Reboot + Poweroff/On so bleibt so sind die den Weg alles Irdischen gegengen.
 
Du kannst vor dem reboot auf der Konsole noch ein glaub „zpool status -z“ oder „fmadm faulty“ machen und mal schauen, was die ausgeben.
 
Hallo in die Runde,

ich würde gern mien ZFS Storage überwachen, da stellt sich die frage was ist alles sinnvoll zu überwachen?
Es gibt ja neben "zfs get all nc_storage used" auch noch jede menge in /sys/module/zfs/parameters/ und /proc/spl/kstat/zfs/arcstats.

Vielen Dank vorab!
 
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