[Sammelthread] ZFS Stammtisch

Hatte jetzt auch schon 2mal den Fehler

NOTICE: cpu1: started, but not running in the kernel yet
WARNING: cpu1: timed out
NOTICE: System detected 8 cpus, but only 7 cpu(s) were enabled during boot.
NOTICE: Use "boot-ncpus" parameter to enable more CPU(s). See eeprom(8).

Kommt aber nicht immer die Meldung.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich würde mit eeprom die Boot Einstellungen nicht ohne große Not verändern.
Um herauszufinden ob das Problem nur beim Booten besteht oder auch danach
kann man sich im Fall der Fälle die CPU cores bei laufendem OS anzeigen lassen:

prtdiag | grep CPU

ps
Falls das Problem "früher" nicht auftrat, kann es auch mit den Anpassungen
aufgrund der aktuellen Sicherheits-Probleme mit Intel und AMD CPUs liegen,
die fortlaufend in Illumos eingepflegt werden.
 
Zuletzt bearbeitet:
Hallo Allerseits, @gea

Ich habe heute mal zum Testen neuer Hardware OmniOS r151048i installiert und dann als Eval napp-it 21.06 -> 23.06 -> 24.01.
Dabei ist mir aufgefallen, dass in der 24.01 der iozone Test nicht funktioniert. Ich habe mich dann auf die Suche gemacht um das Problem zu finden.

Im napp-it Verzeichnis "/var/weg-gui/data/tools/iozone" liegt das iozone File mit 0 Byte Länge. Die Rechte sind aber alle richtig gesetzt.
Zurück auf 23.06 war die Datei mit 255072 Byte vorhanden.

Schlussfolgerung da stimmt was bei der Installation nicht. Ich habe dann die 23.06 und die 24.01 heruntergeladen und das Archiv mal überprüft, dabei kam
Folgendes mit 7-Zip und RAR heraus:

! F:\napp-it-24.01.zip: Checksum error in web-gui\data_24.01\tools\iozone\iozone. The file is corrupt
! F:\napp-it-24.01.zip: Checksum error in web-gui\data_24.01\tools\omnios\fswatch\fswatchbinaries_1.17.1.tar.gz. The file is corrupt
! F:\napp-it-24.01.zip: The archive is corrupt

! F:\napp-it-23.06.zip: Checksum error in web-gui\data_23.06\tools\omnios\perl_5.22\CGI\Expect.pm. The file is corrupt
! F:\napp-it-23.06.zip: The archive is corrupt

Ein Auspackern unter Omnios mit unzip ergibt den selben Fehler File iozone = 0 Byte.

@gea
Es scheinen mindestens diese 2 Install-Zip defekt zu sein. Kannst du das verifizieren?

Vg
Beitrag automatisch zusammengeführt:

@ gea

die 24.dev ist auch betroffen...
mit RAR getestet:

! F:\napp-it-24.dev.zip: Checksum error in web-gui\data_24.dev\tools\iozone\iozone. The file is corrupt
! F:\napp-it-24.dev.zip: Checksum error in web-gui\data_24.dev\tools\omnios\fswatch\fswatchbinaries_1.17.1.tar.gz. The file is corrupt
! F:\napp-it-24.dev.zip: The archive is corrupt
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: gea
Danke für die Info.
Ich habe die ZIP Archive getestet und neu hochgeladen.

Bei welcher Umkopieraktion die Dateien verfälscht wurden, kann ich jetzt nicht sagen.
ZFS meldet das ja sofort, das ZIP Archiv auf dem Webserver erst beim Auspacken,
 
Hallo zusammen,

nachdem ich nun mein Solaris endlich auf den Gigabyte Epyc Board installiert bekommen habe, gibt es nun die nächste Hürde bez. Import des bestehenden Pools.

Der Pool wird mir nicht angezeigt unter nappit als Import bereit, dafür weiter unten folgende Info

warning: Pool hostid does not match physical hostid.
Da sich das MB/CPU/RAM geändert haben, ist diese Meldung erstmal plausibel, nur wie bekomme ich den Pool jetzt Datenverlustfrei importiert?

Grüße

Lucky
 
napp-it macht immer zpool import -f.
Also einfach Pool > Import machen.
 
Also einfach Pool > Import machen.
Konnte ich nicht, weil mir kein Pool zum Importieren angezeigt wurde. Hat genauso wie im Bild ausgeschaut, nur unten bei den exportet Pools war er aufgelistet. Hatte es auf blöd ohne versucht, weil ich mir gedacht hab, vlt macht er dann "import all available" aber nein, ging nicht.
 

Anhänge

  • s.PNG
    s.PNG
    11,8 KB · Aufrufe: 54
Zuletzt bearbeitet:
Fiktives Szenario:
Power Loss beim Resilvering vom Z1.

Was passiert nach dem reboot? Gehts einfach weiter? Neustart vom Resilvering? Kanns sein, dass irgendwas ungünstigeres passiert?
Ist mir bloß eingefallen wegen dem USV-Gedanke...
 
Nachtrag:
...
Wenn ich aber die großen Daten kopiere, 50gb mit je ca. 6 gb/File, dann hab ich den Effekt, dass ich mit 280 mb/s schreibe und nur mit 80 mb/s lese. Ob das evtl. an der LZ4 Komprimierung liegt?
Also ich hab jetzt mit 4 statt 3 Platten ein neues Z1 gemacht, diesmal mit LZ4 wie default, jetzt läuft alles.

Obs echt ein defektes SATA Kabel war oder sowas? Die Backplane, die ich benutzt hab, ist nicht so 100% vertrauenswürdig, irgendwie, 2/5 Slots scheinen nicht zu gehen, wer weiss. Hab zwar keine Fehler bekommen, bestimmt aber auch nicht alle möglichen Tools zur Fehleranalyse (Smart etc.) ausgeschöpft, mangels eingeschränktem Wissen :d...


Hmhmhm, wie isn das mit dem Metadata VDEV? Ist wohl besser das auf den Datendisks zu lassen, bezüglich Ausfallssicherheit und Wiederherstellbarkeit, oder?
Wie isn das mit den Metadaten, können die im RAM-Cache gehalten werden?
Ich hab hier nämlich einige Ordner, wo wirklich viel Dateien drin sind... ist nicht ideal aber ist halt so.
 
Special vdevs sind kein Cache sondern Speicherort für Metadaten oder kleine Dateien. Fällt dieses vdev aus ist der Pool futsch. Mindestanforderung ist daher ein 2way mirror, in kritischen Fällen ein 3way,

Metadaten landen immer im readcache. Special vdev beschleunigt neben dem Lesen aber auch das Schreiben.
 
Special vdevs sind kein Cache sondern Speicherort für Metadaten oder kleine Dateien.
Ich weiss.
Fällt dieses vdev aus ist der Pool futsch. Mindestanforderung ist daher ein 2way mirror, in kritischen Fällen ein 3way,
Das ist weniger praktisch.
Metadaten landen immer im readcache. Special vdev beschleunigt neben dem Lesen aber auch das Schreiben.
Mh das Schreiben ist mir egal, geht eigentlich nur ums Lesen.

Hm, die sind immer im Readcache? Kann man irgendwie eine Priorität vergeben?
 
Hm, die sind immer im Readcache? Kann man irgendwie eine Priorität vergeben?
Arc arbeitet mit einer read last/ read most optimierung.
Wenn der Arc groß genug ist, hat man gute Chancen dass Metadaten beim zweiten Zugriff im Cache sind. Hat man ein L2Arc so hat man zudem einen persistenten Lesecache (vergisst nichts beim Reboot)

Special vdev brauchen den wiederholten Zugriff nicht da die Metadaten direkt auf schnellem Storage liegen.
 
Hm 100% werd ich draus noch ned schlau - sorry.

L2Arc hab ich... aber das mitm beim Reboot nicht vergessen klingt sinnvoll. Arc und L2Arc... holt sich der Arc nachm Reboot dann Daten ausm Arc?
 
Hm 100% werd ich draus noch ned schlau - sorry.

L2Arc hab ich... aber das mitm beim Reboot nicht vergessen klingt sinnvoll. Arc und L2Arc... holt sich der Arc nachm Reboot dann Daten ausm Arc?
Nein, der L2Arc wird selber als zusätzlicher Cache benutzt. Sollte ja bis zu 10x so groß wie der Arc sein aber halt nicht so schnell. Auch verbraucht der L2Arc etwas RAM zum Verwalten.
 
Ist halt die Frage, ob das sinnvoll wäre.
Werden die Metadaten da dann auch rein gelegt?

Mein Ziel isses, dass die Ordnerstruktur und deren Inhalt möglichst schnell angezeigt werden, gar nicht so das schnelle Lesen der Files selbst. Damit man einfach schnell navigieren kann.
 
Die Metadaten werden beim Lesen als Kopie in den Cache gelegt. Schneller wirds also erst beim wiederholten Zugriff. Mit ausreichend Lese Cache (Arc, L2Arc) werden bis zu 80% der Lesezugriffe aus dem Cache bedient. Kontrollieren kann man das mit dem arcstat Script.

Will man beim ersten Zugriff bessere Performance oder wenn viele Nutzer viele kleine Dateien bearbeiten, so ist aber ein special vdev Mirror das Mittel der Wahl.
 
Meingott, ist ZFS nice.
Ich wollt so einen 100gb Ordner mit reichlich "Kleinscheiß" drin auf den drehenden Rost schieben, habs aber wegen schlechten Durchsatz gleich wieder abgebrochen. Dann dachte ich, ich mach ein Archiev draus, als besserer Win-Kacknoob mach ich natürlich erstmal ein 7zip, dauert aber auch ewig (warum auch immer, entweder ist der default-algo so elendig langsam oder... an der Hardware kanns eig. nicht liegen, war alles auf M.2 usw.).

Ich bin dann schnell auf die Idee gekommen einen Tarball draus zu machen, und den einfach so aufs NAS zu schieben (LZ4 eingestellt). .tar war angenehm flott erstellt.
Habs dann aufs NAS geschoben, und die LZ4 Kompression war ähnlich effektiv wie das 7zip (so eins hatte ich noch von der Vorgängerversion des Ordners, Größe fast ident) herumliegen.
Hab mit zfs get compressratio abgefragt, war bei 105% (das 7zip war ähnlich, evtl. im Bereich Richtung 106%).
Ob ich zstd-5 probieren sollte? Wsl. unnötig.

Eigentlich schon ziemlich cool, hat mich heute schon etwas beeindruckt (und ich lass mich nicht so einfach beeindrucken).
 
AutoTrim macht Sinn bei SSDs.
Sollte man aber probieren bevor kritische Daten drauf sind. Es gab Problemberichte vor allem mit billigen Desktop SSDs,
Kann man das mit Pro / Server / Enterprise SSDs (alle PLP, sowohl SATA als auch NVMe) bedenkenlos aktivieren, oder gab es da auch Problemberichte?
 
Mit guten Marken SSD sollte das Problemrisiko gering sein
Super, Danke.

Ich mache gerade eine kleine Benchmark Reihe von Controllern (9300-8i vs 9400-8i vs 9500-8i vs 9600-24i alle am Expander vs 9600-24i direct attach).
Interessante Ergebnisse teilweise.

Aktuell kämpfe ich noch mit dem 9600-24i: An dieser Stelle DANKE FÜR NICHTS Broadcom, dass ich manuell per udev regel TRIM aktivieren muss (SSD Micron 5300 PRO SATA, hängt direkt per direct attach backplane am Controller. Data Set Management TRIM supported (limit 8 blocks) + Deterministic read ZEROs after TRIM. Glaube dem Controller passt nicht dass Write Same nicht supported ist :fire:

Neueste Firmware + Treiber sind natürlich drauf...

Ergebnisse und fio Skripte lade ich hier ASAP hoch
 
Ach... wir lieben ZFS

muss das irgendjemand verstehen?

seq-1m-q8-t1-r: 4355MB/s
seq-1m-q1-t1-r: 6518MB/s

Code:
[global]
direct=1
ioengine=libaio
sync=1
group_reporting=1
time_based=1
runtime=60
size=10G
offset_increment=10g

<snip>

[seq-1m-q8-t1-r]
stonewall
bs=1m
iodepth=8
numjobs=1
rw=read

<snip>

[seq-1m-q1-t1-r]
stonewall
bs=1m
iodepth=1
numjobs=1
rw=read

Pool erstellt mit
Code:
zpool create -o ashift=12 -o autotrim=on -O compression=on -O xattr=sa -O acltype=posix -O relatime=on -O normalization=formD testpool raidz2 <drive 1-8> raidz2 <drive 9-16> raidz2 <drive 17-24>

Platform
Code:
EPYC 7713 @ Supermicro H12SSL-NT (BIOS 2.7, Microcode 0xa0011d1)
proxmox-ve: 8.1.0 (running kernel: 6.5.11-7-pve)
zfs version: 2.2.2-pve1
fio version: fio-3.33

Drives: 24x Micron 5300 PRO 1.92TB (Alle Firmware D3MU001, 512b logical sector size - reformat auf 4096 nicht supported)

Controller:  Broadcom 9600-24i (Firmware 8.7.1.0-00000-00003)
Treiber: Proprietär 8.7.1.0.0
Backplanes: Direct Attach Supermicro BPN-SAS3-216A-N4

SSD writecache: On
 
Wer viel misst, misst viel Mist ...
In meiner Erfahrung verfäscht compression=on Ergebnisse ganz erheblich.

cu
 
Kann man schon machen, aber nur wenn man wissen will wie gut der Cache hilft z.B. im Vergleich zu deaktiviertem Cache - nicht wenn man wissen will wie schnell der Pool eigentlich ist.
 
Hallo @gea,

Ich taste mich gerade an deiner Implementierung von fswatch heran.
Mir stellen sich da ein paar Fragen bez. der Nutzung, denn bei fswatch logs habe ich keine zur Ansicht, mon ist aktiv, daher sitzt die Ursache wohl eher vor den Monitoren ^^
1. Hat die unterschiedliche Beispielangabe bei den Pfaden einen Grund? (.../data1, ../data2 ohne "", bei ../data3, .../data4 ist es mit "")
2. Unter der Voraussetzung, dass es dann funktioniert, stelle ich mir die dann wichtigste Frage, wie nutze ich fswatch, um damit z. B. ein Script ausführen zu lassen. Was ich bisher gefunden habe bezieht sich einmal als Befehl auf die Shell und dann auch auf Linux, nicht auf Solaris. Sollte es da dann überhaupt Unterschiede geben.


Grüße

Lucky
 

Anhänge

  • Unbenannt.PNG
    Unbenannt.PNG
    38,7 KB · Aufrufe: 46
Hab mich mit der Kompression gespielt.

Hab ein Windows-Backup (der Win7 Backupper am Win10) vom C: gemacht aufs NAS, etwa 300gb.
Auf ein Z1 mit LZ4 (3+1 Ultrastar), habs probehalber auf eine SSD (870 evo sata) kopiert (über den Win Explorer, Daten sind am NAS direkt gegangen, da keine Netzwerklast... wie auch immer das über SMB genau geht, da fehlt mir das Wissen). Das Verschieben war "relativ langsam" ~80-300mb/s je nach dem, ZSTD12 gefühlt langsamer, prakitsch aber ähnlich.

LZ4: Quelle.
ZSTD5: ~27 min, ist am Screenshot der "erste" Lauf. Stromverbrauch nicht gemessen.
ZSTD12: ~30 min, ist am Screenshot abgeschnitten, ist der 2. "Lauf". Viel CPU Load. ~122W, idle macht das NAS ca. 50W.
fastZSTD5: ~26 min, sehr wenig CPU Load, ~65W Aufnahme beim Kopieren.

Compressratio über sudo zfs get compressratio
lz4: 1,42
zstd5: 1,59 / sysload mid ~5
zstd12: 1,60 / sysload mid ~14
fastzstd5: 1,44 / sysload mid ~2,5

Müsste man schauen, ob zstd3/4 noch brauchbare jKompression mit weniger Rechenaufwand bringen würde. Freut mich jetzt aber nicht, dauert mir zu lang, und mags nicht mitm halben backup machen.
 

Anhänge

  • 1706392618768.png
    1706392618768.png
    100,5 KB · Aufrufe: 46
Wer viel misst, misst viel Mist ...
In meiner Erfahrung verfäscht compression=on Ergebnisse ganz erheblich.

cu
Wie kann den compression=on die Ergebnisse verfälschen, wenn doch genau der Sinn und zweck ist mit compression die Performance zu messen?

Ein Stripe auf 24 der SSDs, compression=on vs compression=off

compression=on:
-52% seq-1m-q8-t32-w
-52% seq-1m-q1-t32-w
-29% seq-1m-q8-t1-rw read
-14% seq-1m-q8-t1-rw write
-12% seq-1m-q8-t32-rw read / seq-1m-q8-t32-rw write / seq-1m-q1-t32-rw read / seq-1m-q1-t32-rw write / seq-1m-q1-t1-w


Rest +- 0, teils marginal schneller

wie weit da jetzt abnehmende performance durch anfangs fehlendes autotrim=on reingespielt hat kann ich nicht sagen
 
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