mgutt

Manche NVMe haben Bugs und kommen mit ihren eigenen propagierten Schlafzuständen nicht 100%-tig klar. Es kommt dann zu Übertragungsfehlern, die aber durch wiederholtes Senden der Daten oder durch den mitgelieferten ECC (Error Correction Code) behoben wird. Das ist also "nur" eine Warnung. Allerdings können diese die kompletten Logs fluten und die Fehlerkorrektur kann je nach Häufigkeit auch zu spürbaren Latenzen führen. Du hast nun folgende Optionen: - BIOS aktualisieren - NVMe Firmware-Update aufspielen (muss dazu meistens in einen Windows PC und selten gibt es Updates) - die Kernel Option "nvme_core.default_ps_max_latency_us=XXX" so setzen, dass die höchsten Schlafzustände der NVMe deaktiviert werden - die Kernel Option "pcie_aspm=off" setzen, wodurch alle Energiesparfunktionen aller PCIe Verbindungen deaktiviert werden - die Kernel Option "pci=noaer" setzen, wodurch die Fehlermeldungen unterdrückt werden ASPM PS4 deaktivieren Das oben genannte "XXX" ist ein individueller Schwellwert, der je nach NVMe unterschiedlich sein kann. Welche Schlafzustände/Schwellwerte eine NVMe besitzt, kann man mit diesem Befehl herausfinden: smartctl -a /dev/nvme0 Hier zB von meiner NVMe (die Samsung EVO Plus hat diese Probleme übrigens nicht): Model Number: Samsung SSD 970 EVO Plus 2TB ... Supported Power States St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat 0 + 7.50W - - 0 0 0 0 0 0 1 + 5.90W - - 1 1 1 1 0 0 2 + 3.60W - - 2 2 2 2 0 0 3 - 0.0700W - - 3 3 3 3 210 1200 4 - 0.0050W - - 4 4 4 4 2000 8000 Da sieht man zB, dass der höchste Schlafzustand "4", der "PS4" genannt wird, einen ENT_LAT von 2000 und einen EXT_LAT von 8000 besitzt. Im Linux Kernel steht nun folgende Erklärung (von mir übersetzt): Entsprechend: 50 (2000 + 8000) = 500000 Mikrosekunden = 0.5 Sekunden Der Wechsel zwischen den Schlafzuständen erfolgt also ziemlich schnell. Jedenfalls könnte ich nun bei meiner NVMe PS4 deaktivieren, in dem ich eine maximale Latenz einstelle, die größer gleich 1200 ist (EXT_LAT von PS3) und kleiner als 8000 (EXT_LAT von PS4). Also zb: nvme_core.default_ps_max_latency_us=6000 ASPM der NVMe vollständig deaktivieren Alternativ erlaubt der Linux Kernel auch das Deaktivieren von ASPM, in dem der Wert auf 0 gesetzt wird: Also entsprechend so: nvme_core.default_ps_max_latency_us=0 Weiterführende Informationen https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/nvme/host/core.c?h=v5.9-rc7

Alle Bugs zur RC4 bitte hier melden:

In so einem Fall muss man einen btrfs scrub ausführen. Erst beim scrub werden dann Inkonsistenzen erkannt und korrigiert. In der neuesten Version kann man das übrigens per Zeitplan machen: https://forums.unraid.net/bug-reports/prereleases/unraid-os-version-6100-rc3-available-r1760/

Und was? Command not found bezieht sich immer auf ein Kommando, also eine Zeile Code. Alturismo hat mehrere Zeilen gepostet.

Gerade Kingston ist dafür bekannt in Linux Probleme im Sleep zu haben. Und in einem BTRFS RAID heißt eine kurzzeitig nicht erreichbarer Datenträger, dass dieser defekt ist und dann wird er rausgeworfen.

Die meisten machen das per Kommandozeile mit dem Befehl rclone. Dieser ist in der Lage diverse Clouds als lokalen Ordner zu mounten und auch zu synchronisieren.

WD garantiert zb 50.000 Spin Cycles. Unwahrscheinlich, dass man die erreicht oder gar übersteigt bzw wer sagt überhaupt, dass die dann kaputt gehen. Bei 1 Spinup pro Stunde sind das übrigens 9000 Spin Cycle pro Jahr. Ich habe auf der Parität jetzt nach einem Jahr 4000. Kann ich gut mit leben.

Mehr Input bitte. An vfio gebunden? VM Config sieht wie aus?

Die Anleitungen basieren alle auf Docker Compose. Bei Docker Compose ist der Aufbau der Templates etwas anders als bei einzeln angelegten Containern, wie das bei Unraid gemacht wird. Hier sind aber schon mal alle notwendigen Container und deren Variablen aufgelistet: https://github.com/jitsi/docker-jitsi-meet/blob/master/docker-compose.yml Was man schon mal sieht, dass jitsi ein Custom Network zu benötigen scheint. Das müsstest du von Hand über die Kommandozeile erstellen: docker network create meet.jitsi Und dann müssten alle Container von Hand angelegt werden (während die das neue jitsi Netzwerk auswählst). Ich würde zB mit dem jitsi/web starten. Da siehst du dann schon, dass du die Ports 80 und 443 hinzufügen musst: Dann musst du die Container Pfade /config, /var/spool/cron/crontabs und /usr/share/jitsi-meet/transcripts nach den Host Pfaden /mnt/user/appdata/jitsi/config, /mnt/user/appdata/jitsi/crontabs und /mnt/user/appdata/jitsi/transcripts verlinken: Dann kommen die tausend Variablen: Wie du siehst haben die alle keine Werte. Du musst also nur Add Variable in Unraid machen und das Feld mit dem Wert lässt du einfach leer. Dann würde ich in Unraid noch die erweitere Ansicht aktivieren und bei WebUI das eintragen: Dadurch hast du nach dem Start des Containers den Menü-Eintrag: Ein paar weitere Infos auch in dem Video: Wenn Du damit durch bist, kannst du dich auch als Entwickler bewerben und deine Templates bei Unraid offiziell in den App Store laden lassen. Oder schick die XML-Dateien mir oder ich777 und einer packt sie in seine Sammlung. Danach kann sie jeder Unraid Nutzer verwenden.

Das habe ich noch nicht komplett durchgetestet, aber ich glaube wenn Unraid eine Disk einmal als kaputt erkannt hat, dann akzeptiert Unraid die selbe Disk nicht mehr in dem Slot. Also der erkennt an Hand der Seriennummer, dass das die kaputte Disk ist und bindet sie dann nicht mehr ein, sondern nur eine Disk mit einer anderen Seriennummer. @ich777 darf mich hier gerne korrigieren. Wenn du also eine Disk rausziehst und wieder in Betrieb nehmen willst, musst du über Tools > New Config das Array komplett auflösen, die Disks wieder exakt so zuordnen wie sie vorher waren (also Screenshot nicht vergessen) und beim Start angeben, dass die Parität bereits in Ordnung ist. Allerdings besteht dann immer noch ein Restrisiko, dass die Parität nicht 100%-tig korrekt ist, weshalb man eh einen Parity Check machen sollte. Schlussendlich wird dann also die Parität korrigiert, statt die rausgezogene Disk neu aufgebaut. Ist die Frage wem man mehr glaubt. Dem Verbund der Platten + Parität oder der rausgezogenen Disk. Brauchst du denn jetzt noch Hilfe wegen deinem Datenverlust? Evtl könnte Testdisk ein kaputtes Dateisystem reparieren. Aber wenn du die schon neu formatiert hast, hilft das natürlich nicht mehr.

Hmm ja. Nur was passiert dann mit den Daten, die schon im RAM liegen. Ich vermute die werden von Linux direkt nach Änderung der Einstellung als "Müll" markiert. Das wäre dann ja kontraproduktiv. Ich brauche sowas wie die Option "iflag=direct" bei "dd". Hier wird "nocache" vorgeschlagen: https://askubuntu.com/questions/122857/can-i-copy-large-files-faster-without-using-the-file-cache Aber mir fällt gerade ein. Man könnte das ja über einen Docker lösen. Der läuft ja in seinem eigenen "Universum" (chroot) und wenn man da mit dem --memory flag den RAM auf ein paar MB begrenzt, kann rsync denke ich nicht den kompletten RAM überschreiben. Wobei da wieder die Frage ist ob dadurch wirklich nur ein bestimmter Bereich des RAM für den Container reserviert wird oder ob Linux selbst dann einfach nach und nach einen anderen Teil des RAMs beschreibt. Kann man irgendwie überwachen welche Addressbereiche des RAMs ein Container nutzt?

Mach das in jedem Fall. Ich finde das jedenfalls mega. Hätte am liebsten 1TB RAM und würde einfach alles da reinpacken, weil es ja auch mega effizient ist, wenn gar nicht mehr auf die Datenträger zugegriffen werden muss. Mal sehen ob wir bei DDR5 auch im Privatbereit endlich richtig dicke Module bekommen 😋 Übrigens ist mir aufgefallen, dass rsync den kompletten Schreibcache "verschwendet", während Dateien synchronisiert werden. Ich mein ist ja logisch, weil jede Datei individuell ist und automatisch damit erst mal "frisch" in den RAM geht, aber ich hätte gerne eine Ausnahme explizit für rsync. Weil Backup-Prozesse müssen echt nicht durch den RAM laufen. Falls da einer eine Idee hat, wie man das selektiv abschalten kann, würde ich mich freuen davon zu hören 🤗

Doch sehr wohl. Linux nutzt 20% des freien RAM immer als Schreibcache und kopiert die Daten erst nach 30 Sekunden weg. Siehe auch: Doch, genauso verhält es sich. Vorausgesetzt du hast 200GB freien RAM, da 20% wie gesagt der Standardwert ist. Oder du hast den Standardwert entsprechend korrigiert. Die Dateien bleiben übrigens im RAM. Eine gerade auf den Server hochgeladene Datei kommt daher beim folgenden Download nicht mal mehr vom Datenträger. Kann man testen. Man lädt eine 100MB Datei direkt auf eine HDD, dann dauert es 30 Sekunden bis Linux sie auf die HDD kopiert, dann versetzt man sie in den Spindown und lädt die Datei wieder runter. Die HDD geht dann nicht an (irgendwann schon, weil die Zugriffszeit geschrieben wird, aber das passiert bei Linux irgendwie viel später, ich glaub wenn die page caches durch irgendwas geflusht werden). Natürlich verschwindet die Datei irgendwann wieder aus dem RAM, wenn andere Dateien gecached wurden. Linux überschreibt aber immer nur selten genutzte Dateien. Daher würde zb eine Plex Datenbank immer im RAM verweilen, weil sie ständig genutzt wird. Und ja es sind eigentlich nicht "Dateien", die im RAM gecached werden, sondern deren Datenblöcke. Aus dem Grund funktioniert auch dieses Script, was nur 100MB eines Videos in den RAM lädt:

Ist nicht notwendig, weil beide ja im Gegensatz zu USB Geräten unterschiedliche PCIe IDs haben. In deinem Fall die 02 und 03. Die Alternative zum PCIe passthrough wäre die Karten nicht an VFIO zu binden und die angeschlossenen Datenträger per virtio und ihrer ID durchzuschleifen:

1.) Das Mount Kommando darf innerhalb eines Scripts nicht auf " &" enden, denn sonst erfährt man nichts zu Fehlern. Das einzelne Ampersand sorgt dafür, dass nicht auf das Ergebnis des Kommandos gewartet wird, sondern das Script direkt weiter ausgeführt wird (und da nichts mehr folgt, endet). 2.) Es gilt zu prüfen (nachdem das Ampersand entfernt wurde), ob das Script wiederholt ausgeführt werden kann. Wenn ja, dann habt ihr schlussendlich überlappende mounts, was langfristig zu Problemen führt. Daher bitte mal prüfen und auch mal "mountpoint /mnt/disks/Data" ausführen ob das als klassischer Linux Mount erkannt wird. Dieser Pfad darf nicht gemountet werden. Alles unter /user und /disk gehört Unraid. Externe Ziele gehören unter /mnt/remotes Grund dafür ist, dass unRAID seine eigenen Mounts beim Neustart löst und wenn da welche doppelt vorhanden sind (/mnt/user/gdrive ist ein Mount auf einen Datenträger und nach Google Drive), wird immer nur einer gelöst und der Server hängt. Auch braucht man ein Script für den Unmount, wenn man das Array stoppt.

Wenn der Shutdown nicht klappt, erstellt unRAID automatisch eine Diagnostics auf dem Stick unter logs. Bitte Posten.

Sorry, Denkfehler meinerseits. Geht natürlich nicht.

Dann würde ich auch auf einen defekten Stick tippen. Die Zuordnung ist darauf gespeichert und geht nicht einfach verloren.

Kommentieren ist nie verkehrt. Erhöht die Aufmerksamkeit

Das ist nicht normal. Hast du evtl von Hand irgendwelche Verzeichnisse gemountet oder rsync im Einsatz? Wobei Platten neu zuordnen absolut unnormal ist. Fehlt eine Disk nach einem Reboot oder gar alle?

Hast du auch mal versucht den eigentlichen PCIe Slot und nicht die Adapter durchzuschleifen?

Nutzen die nicht alle einen Realtek Controller? Ich vermute daher, dass die alle gehen.

I'd say you need to add each IP range as a different VLAN and use the different br0.XX for different NPM containers: Of course each NPM container needs a different name and different appdata paths.

NVMe kommen erst bei mehreren parallelen Threads so richtig in Fahrt. Kann gut sein, dass der Test das einfach nicht macht. Bei einer HDD wären parallele Threads zb extrem nachteilig.

Gib das im Terminal ein: lspci -vv Was unter LinkCap steht ist das was der Slot kann und das was unter LinkSta steht, ist das was gerade aktiv ist. Direkt gefiltert: lspci -vv | awk '/Speed/{print $0}' RS= | grep --color -P '(^[a-z0-9:.]+|Speed)'