mgutt

Das ist nicht möglich, wenn scheinbar nur mit SRV-IO kompatiblen Adaptern und selbst da nicht trivial, weil man sie nachträglich dorthin "linkt": https://stackoverflow.com/questions/60189587/how-to-pass-through-physical-nic-to-docker-container Selbst wenn das ginge, wird der ausgehende Traffic immer über eth0 gehen, weil der als Route konfiguriert ist und es kann immer nur eine Route geben (außer vielleicht bei Load Balancern). Man könnte das nur verhindern, wenn man die Adapter in verschiedenen IP Ranges nutzt also zb 192.168.178.10 und 192.168.179.10. wenn dann ein Container über macvlan die 192.168.179.11 hat, würde dessen ausgehender Traffic über die 179.10 rausgehen. Aber @Ford Prefect ist da der bessere Ansprechpartner ^^

Im Gegenteil. Da beide im selben Unterordner liegen, weist du gar nicht ob der die von Disk6 oder Disk10 siehst. Bzw wenn du die nun über Windows löschst, dann zb von Disk6 und sie sind trotzdem noch da. Also unRAID kann dir die selbe Datei auf zwei verschiedenen Disks nicht parallel anzeigen. Daher entweder löschen oder du den Unterordner auf Disk6 umbenennen. Das ist dann auch automatisch ein neuer Share.

Einfach den kompletten config Ordner vom alten Stick übernehmen. unRAID erkennt, dass die vorhandene Lizenz nicht zum Stick passt und bietet dir nach dem Booten an die Lizenz auf den neuen Stick zu ändern. Damit erweiterst du das Array ohne die Parität zu aktualisieren. Damit das möglich ist, geht unRAID hin und schreibt die neue Platte komplett mit Nullen voll. Also sie wird wirklich gelöscht. Du musst also stattdessen folgendes machen: - Screenshot von der Disk Übersicht, damit du weißt welche Disk in welchem Slot war - dann Tools > New Config und bei Pools den Haken rein, dass du diese behalten willst - jetzt das Array exakt wieder so mit den Disks befüllen wie es vorher war, nur eben zusätzlich mit den neuen Disks - Array starten und die Parität wird neu aufgebaut

Nö. Die ist nun in Ordnung. Parity Check und Dateien löschen kannst du ganz normal. Zb so über die Kommandozeile: rm -r /mnt/disk6/*

Ja sieht jetzt wieder normal aus. Jetzt lösch mal die überflüssigen appdata Ordner von den Disks, damit das auch wieder sauber ist: rm -r /mnt/disk*/appdata Dann müssen wir mal über die Cache Einstellung von system sprechen. Die steht auf "Ja". Dh das docker.img und alle VM Disks, werden vom Cache auf das Array verschoben. Willst du das? Wenn nein, würde ich den Cache auf "Bevorzugt" umstellen und dann den Mover starten. Dafür muss aber Docker und VM jeweils deaktiviert sein. Hinweis: Du darfst auf keinen Fall "Nur" nehmen, weil sonst zerlegst du dir alles,

Andere Optionen hast du jetzt eh keine mehr außer ein komplettes Backup von disk12 machen. Versuch noch mal eine Reparatur ohne Optionen, aber ich denke die ist jetzt repariert. Vermutlich gibt es jetzt einen löst+found Ordner. Irgendwas von Interesse da drin? EDIT: ich bin für heute raus..

-n hattest du entfernt? Falls ja, Versuch es mit -L, wenn eh keine Dateien drauf sind.

Das ist schon sehr warm für eine HDD, aber gerade noch ok.

Ja geht nicht anders, da das Dateisystem nicht mehr reagiert. Am besten mal komplett ausschalten. Also dass der Strom mal aus war. Dann ist die SATA Karte auch wieder normal da, falls die ausgestiegen sein sollte.

Reparatur: - Array stoppen - Array im Wartungsmodus starten - auf "Disk1" klicken - nun im Abschnitt mit xfs repair das -n entfernen und die Reparatur starten (-n simuliert nur und macht nichts) - das bei jeder Disk wiederholen Der zeigt nun einen Bericht an. Den kannst du bei Bedarf kopieren und später als ZIP hier alles Posten. Aber normalerweise ist die Reparatur erfolgreich. Falls bei der Reparatur Dateien wiederhergestellt werden, landen die in einem Lost+Found Ordner auf der jeweiligen HDD. Bei BTRFS ist es ähnlich. Nur dafür muss man das Array normal starten und auf "cache" klicken. Da dann scrub starten.

Nein, aber durch powertop hat es dir bestimmt das Dateisystem von den HDDs zerlegt, die an der zusätzlichen SATA Karte dran waren. Die müssen jetzt erstmal alle repariert werden. Das selbe gilt, falls du den Server hart abschaltest oder dieser abstürzt. Dann immer vorsichtshalber eine XFS und BTRFS Reparatur durchführen. Du hast aber sonst keine Stromsparkommandos zb in der Go Datei? Weil das sollte am besten alles entfernt werden.

SSD oder HDD? Für eine SSD ist das gar nichts. Die können problemlos 70 Grad erreichen.

Du solltest übrigens Docker und VM komplett deaktivieren bis alles repariert ist. Das bringt in der aktuellen Situation eh nichts und wurde immer wieder crashen. Vom Prinzip kannst du die Parity Korrektur auch erstmal stoppen. Die kann eh nichts mehr reparieren. Dann würde ich: - Array Autostart deaktivieren - Docker + VM deaktivieren - das Array stoppen - das Array im Wartungsmodus starten - alle Disks reparieren - Array normal starten - Pool reparieren - Server neu starten und Logs sichten, ob da noch Kernel Fehler auftauchen - wenn nein Array starten - Logs wieder sichten - keine Fehler, dann Parity korrigieren - jetzt mal alle Disks per SMART und erweitertem Test durchtesten - und auch jetzt immer wieder Logs checken

Nutzt du powertop oder andere Stromspar-Mechanismen? Deine Platten zeigen beim Zugriff quasi alle Fehler. Auch der Pool. Dazu diverse Kernel Fehler. Ich denke aber dadurch, weil das Dateissystem repariert werden muss. Jul 4 17:27:16 Tower kernel: blk_update_request: I/O error, dev loop2, sector 18424224 op 0x0:(READ) flags 0x1000 phys_seg 4 prio class 0 Jul 4 17:27:16 Tower kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 2, rd 9, flush 0, corrupt 0, gen 0 Jul 4 17:27:16 Tower kernel: blk_update_request: I/O error, dev loop2, sector 18948512 op 0x0:(READ) flags 0x1000 phys_seg 4 prio class 0 Jul 4 17:27:16 Tower kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 2, rd 10, flush 0, corrupt 0, gen 0 Jul 4 17:27:16 Tower kernel: BTRFS: error (device loop2) in btrfs_run_delayed_refs:2150: errno=-5 IO failure Jul 4 17:27:16 Tower kernel: BTRFS info (device loop2): forced readonly Jul 4 17:27:01 Tower kernel: XFS (md9): metadata I/O error in "xfs_imap_to_bp+0x4e/0x6a [xfs]" at daddr 0x100003b10 len 32 error 5 Jul 4 20:18:51 Tower kernel: XFS (md8): Log I/O Error (0x2) detected at xlog_ioend_work+0x50/0x6e [xfs] (fs/xfs/xfs_log.c:1377). Shutting down filesystem. Jul 4 20:18:51 Tower kernel: XFS (md8): Please unmount the filesystem and rectify the problem(s) Jul 4 20:18:51 Tower kernel: XFS (md9): metadata I/O error in "xfs_imap_to_bp+0x4e/0x6a [xfs]" at daddr 0x1000039f0 len 32 error 5 Jul 4 20:18:51 Tower kernel: XFS (md9): metadata I/O error in "xfs_da_read_buf+0xa3/0x103 [xfs]" at daddr 0x5082f83c0 len 8 error 5 ### [PREVIOUS LINE REPEATED 1 TIMES] ### Jul 4 20:19:09 Tower kernel: XFS (md9): log I/O error -5 Jul 4 20:19:09 Tower kernel: XFS (md9): Log I/O Error (0x2) detected at xlog_ioend_work+0x50/0x6e [xfs] (fs/xfs/xfs_log.c:1377). Shutting down filesystem. Jul 4 20:19:09 Tower kernel: XFS (md9): Please unmount the filesystem and rectify the problem(s)

Poste bitte jetzt mal deine syslogs / Diagnostics. Hast du syslog Server Mirror auf USB schon aktiv? Bitte aktivieren falls nicht. Ich vermute, dass die Disks sporadisch ihre Verbindung verlieren. Wird sich dann aber in den Logs zeigen.

Im Screenshot steht "nur". Wann wurde das so eingestellt? Das Problem an "nur" ist, dass dadurch ausschließlich die Dateien auf dem Cache gefunden werden. Also alles was aktuell auf den Disks im Ordner appdata liegt, und das sind ja ja mehrere, ist faktisch Müll, wenn du diese Einstellung schon länger nutzen solltest. Wenn du also wirklich schon sehr lange "nur" benutzt, kannst du folgendes ausführen, um diese Ordner zu löschen: rm -r /mnt/disk*/appdata Viele Fehler heißt, dass die Parität nicht dem Stand der Daten auf den Disks entspricht. Ein Neustart ändert nichts daran. Warte den Check ab, dann stoppst du das Array und startest im Wartungsmodus. Dann klickst du auf Disk1 und startest die xfs Reparatur (ohne -n). Danach mit jeder weiteren Disk wiederholen. Führe aktuell mal bitte das aus um die Rechte der Disk Ordner anzuzeigen: ls -la /mnt/*

Braucht er nicht. Der Parity Check ändert keine Daten auf den Disks. Nur der Parity. Mich wundert, dass du keine Dateien über die GUI sehen kannst. Da ist nichts ungewöhnliches zu sehen. Allerdings ist es nicht normal, dass du appdata und System auf Disk11 hast. Welche Cache Einstellung haben diese Shares und hast du sie im laufenden Betrieb mal geändert?

Brauchst du LA? Ich nutze lieber zwei verschiedene IP Ranges auf meinen Clients und load balance quasi auf die Art. Jedenfalls hat dein Server ganz simpel einfach kein Internet. Also das wird nicht gehen: ping google.com Oder geht das? ping 8.8.8.8 Dann stimmt nur was mit deinem DNS nicht.

Was zeigt das an: ls -la /mnt/disk*/

So ist auch die Idee, aber nur wenn man wirklich Probleme hat. Ansonsten hat man massig unnötige Log-Einträge. Der generiert die ja dann für jede Dateibewegung.

Unwahrscheinlich, denn nur das neu zuordnen von Disks, zerstört nicht das docker.img auf dem Cache. Daher auch meine Frage was im Cache bzw der Share system bzw appdata anzeigt. Das ist böse. Bei allen HDDs?

Um genau zu sein hat man insgesamt einfach nur 16 Lanes. Eine Karte kann also 16 Lanes nutzen. Verbaut man zwei, hat man nur noch 8 Lanes pro Slot. Also falls du denkst, dass man 16+8 hätte. So ist es nicht. Laut der Nvidia Website ragt der Kühler über den 1. Slot drüber. Also mit dem NH-D15 hat man dann angeblich gar keinen 1. Slot mehr. Das wäre ja schön doof, wenn man doch mal eine Karte verbauen will.

Ist denn SMB aktiviert? Rechts der Pfeil zeigt den Inhalt vom Cache. Außerdem kann man sich über Shares und dem Pfeil anzeigen lassen, wo alles die Dateien von appdata liegen (LOCATION).

Ja Und deren Daten liegen wo? Nein. Jetzt oder nie. Der Parity Check ändert nichts an den Daten.

Unter Zeitplan gibt es die Option.