mgutt

SMB auch. Ich tippe darauf, dass rsync viel mehr kleine Dateien verarbeitet als beim Test mit SMB? Das ist nämlich meist die Hauptursache für die Überlastung durch SSHFS. Wenn du in den Unraid Server eine ausreichend große SSD packst, könntest du auch nach /mnt/cache/backups sichern und der Mover übernimmt anschließend die Verteilung nach den Regeln, die der backups Share besitzt. Allerdings sieht rsync dann nicht die bereits übertragenen Dateien, die ins Array verschoben wurden. Ist also nur was für Vollbackups und keine sich wiederholenden rsync Kommandos, wo nur neue Dateien transferiert werden sollen. Evtl ginge dann aber "rsync -a --compare-dest=/mnt/user/backups /quelle /mnt/cache/backups". Muss man testen. EDIT: Ne dann würde er geänderte Dateien auf dem Cache erstellen und der Mover würde sie nicht ins Array verschieben, da sie dort bereits vorhanden sind (der Mover überschreibt grundsätzlich keine Dateien).

Remove the Container, then go to Apps > Previuos Apps and delete the MariaDB Official result. This deletes the template file from your USB flash drive. Now search for MariaDB Official again and install it with the default settings (set only a random password for testing). Or are you using an outdated unRAID Version?

Bei BIOS F20 steht das:

War das nicht so, dass auf den W480 mit dem aktuellen BIOS gar keine Celeron und Pentium mehr liefen?!

Poste mal deine Diagnostics hier: https://forums.unraid.net/topic/100540-logs-flooded-with-pme-spurious-native-interrupt-since-upgrading-to-690-rc2/ Scheint jedenfalls thematisch passend zu sein.

SMB und SSHFS sind Single Threaded. Du hast ein Leistungsproblem. Das kannst du aber in den Griff bekommen, in dem du nicht auf/von /mnt/user transferierst, sondern /mnt/diskX nutzt. Dann fallen alle SSHFs Prozesse weg.

Das hat nur Vorteile. Kein Limit und bessere Performance. Probier es doch einfach aus. Ich nehme an, dass dein Image irgendwann vollgelaufen ist und dieser eine Container dadurch kaputt gegangen ist. Kann aber auch andere betreffen. Genau kann das keiner sagen, aber wenn die anderen laufen, scheint es wohl zu passen. Vorher einfach Backups machen. Erhöht das Selbstbewusstsein. 😉

USB 2.0 ist ausreichend und auch empfohlen

Yes, had similar experiences. Reduce it to 100 MB as mentioned here: https://forums.unraid.net/topic/97165-smb-performance-tuning/?do=findComment&comment=898772

Du solltest aufhören dich auf die Lanes zu versteifen. Es ist völlig Wumpe wie viele das nun sind. PCIe ist voll abwärtskompatibel. Dh jede Karte würde auch mit X1 laufen. Und da die Karten beim nativen Booten in Windows laufen, ist ja technisch alles in Ordnung. Der nichtsagende Fehler 127 sagt bekanntlich aus, dass Qemu nicht auf die Karte zugreifen kann, weil sie eine unerwartete Antwort von sich gibt. Also sie ist zb in einem Status, wo sie bereits "hochgefahren" ist. Es gibt diverse Lösungen in so einem Fall. Zb eine eigene GPU ROM verwenden oder einen Reset Befehl über die Kommandozeile oder BIOS Update oder Firmware Update der Karte. Und natürlich darf die Karte nicht von Unraid in Verwendung sein (was ja mit VFIO verhindert wird). Was ich machen würde: - BIOS Reset - vfio Datei vom Stick löschen - UEFI booten - alle VMs abschalten - nur eine Karte einbauen - diese eine Karte an VFIO binden - komplett neue Ubuntu VM erstellen. Alles eingestellt lassen wie es ist und Karte durchschleifen. Ergebnis prüfen. Das ganze mit der nächsten Karte wiederholen (also auch neue VM erstellen). Durch das wilde herumstecken, bezweifle ich nämlich, dass deine Windows XML und das virtuelle BIOS überhaupt noch kompatibel zu der verbauten Hardware sind (das virtuelle BIOS steckt im libvirt.img und kann nicht geändert, sondern nur gelöscht werden, wenn man die VM löscht). Du musst also immer eine neue VM erstellen, um dies als weitere Fehlerquelle auszuschließen.

Die 20GB sind voll gelaufen? Dann läuft bei einem deiner Container bereits was falsch. Das docker.img enthält zwar alle Images und die virtuellen Docker Umgebungen, aber der Speicherplatzverbrauch sollte nach der Installation ziemlich konstant bleiben. Du kannst übrigens auf Verzeichnis umstellen. Dann gibt es kein docker.img mehr und er schreibt direkt die Dateien auf den Cache = das Limit entspricht der SSD Größe. Ich kenne keinen anderen Fall. Die Container Templates liegen auf dem USB Stick und die Container Daten in appdata. Jedesmal wenn du einen Container aktualisiert, wird dieser aus docker.img gelöscht und neu installiert. Also mach dir da keinen Kopf. Du kannst es auch "üben". Beim Container auf Remove und dann unten auf add Container und aus dem Dropdown wieder auswählen und Go. Add Container/Dropdown ist das selbe wie Apps/Previuos Apps.

Wenn es bei unterschiedlicher Hardware passiert, kann es ja eigentlich nur der USB Stick sein.

Sobald der Pfad der Datenbank auf /mnt/cache umgestellt ist, wird Nextcloud 10x schneller. Setzt aber voraus, dass du dir 100% sicher bist, dass alle appdata Dateien auf dem Cache liegen und da auch permanent drauf bleiben.

Denk dran, dass Bonding und SMB Multichannel nicht das selbe ist. Multichannel geht ohne Bonding.

Oha. Ich nehme auch 10. Bei Vorkasse hätte ich allerdings Schiss in der Buchs ^^

Was heißt das? Die fahren dann nicht mehr hoch?!

Gerade bei SSDs lohnt sich RSS zu aktivieren: https://forums.unraid.net/topic/97165-smb-performance-tuning/

Mehrere VMs? Liegen auf HDDs? Verschlüsselung?

Bei dir ist was nicht in Ordnung. Es darf gar keine Fehler geben. Check alle deine Platten. Die Parität solltest du natürlich korrigieren lassen, aber vertrauen würde ich ihr aktuell nicht. Auch nur 1 Fehler ist nicht normal.

Hast du einen Cache konfiguriert? Dann lass dort eine Vdisk erstellen. Also keine komplette Platte an die VM durchschleifen. Das ist schlicht unnötig. Lies dich hier ein: https://forums.unraid.net/topic/112374-windows-1011-vm-installationsanleitung/

Die ist ok, du brauchst aber als Parität eine andere. Leider ist nicht klar welche exakt so groß ist wie die QVO. Ein Bit weniger und sie kann nicht als Parität zugewiesen werden. Was kosten dich die QVO?

Dann geht dein Board im Leerlauf schön tief schlafen. Hast du mal den Verbrauch gemessen?

Leider bei fast allen neuen Motherboards so Seid froh, dass es so ist. Hatte auch der Intel Dummfug (CNVi) durchgesetzt, hätte wir jetzt den gleichen Unsinn wie mit Thunderbolt. Offene Standards sind immer noch am besten.

Deswegen zahle ich gerne per PayPal: https://www.paypal.com/de/webapps/mpp/refunded-returns

Hat Mindfactory auch nicht anders verdient. Die sollen gefälligst klar kommunizieren was Sache ist. Auch bei den Toshiba HDDs.