strohann

Oke, sorry, Missverständnis: hab das Array gestoppt, dann im Maintenance Mode gestartet, xfs repair ausgeführt, Array stop, Array start im normalen Modus - Array jetzt im Normalzustand. xfs repair über die GUI gestartet. Wollte direkt einen Parity Check laufen lassen, der braucht aber schonmal ewig und hat "Sync Errors corrected": Der Check wurde ohne den Haken Write Corrections to Parity (oder wie es genau heißt) gestartet.

Ich hab mal spaßeshalber den Check noch auf der disk2 laufen lassen und bekomme da auch filesystem errors. Sollte ich den repair bei allen Platten laufen lassen?

Erledigt.... Muss gestehen, ich hab nicht so arg viel gelesen was mir die Kiste gesagt hat - da stand mach also hab ich gemacht. Es kam zwar die Meldung mit possible corruption aber naaaja, wieviel wird schon verloren gehen.... :D DISK1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 5 - agno = 7 - agno = 2 - agno = 4 - agno = 6 - agno = 1 - agno = 3 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 7303323858, would move to lost+found disconnected inode 7303323859, would move to lost+found disconnected inode 7303323860, would move to lost+found disconnected inode 7303323861, would move to lost+found disconnected dir inode 10737436072, would move to lost+found disconnected dir inode 12906776129, would move to lost+found Phase 7 - verify link counts... would have reset inode 8594264209 nlinks from 11 to 9 Maximum metadata LSN (16:121370) is ahead of log (16:118034). Would format log to cycle 19. No modify flag set, skipping filesystem flush and exiting. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If the filesystem is a snapshot of a mounted filesystem, you may need to give mount the nouuid option. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Dirty Log detected - Zero Log Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 4 - agno = 9 - agno = 1 - agno = 6 - agno = 7 - agno = 5 - agno = 8 - agno = 3 - agno = 10 - agno = 11 - agno = 2 - agno = 12 clearing reflink flag on inodes when possible Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 7303323858, moving to lost+found disconnected inode 7303323859, moving to lost+found disconnected inode 7303323860, moving to lost+found disconnected inode 7303323861, moving to lost+found disconnected dir inode 10737436072, moving to lost+found disconnected dir inode 12906776129, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 8594264209 nlinks from 11 to 9 resetting inode 23625492 nlinks from 2 to 4 Maximum metadata LSN (16:121437) is ahead of log (1:2). Format log to cycle 19. done

Wo kommen die Infos/Anweisungen her? Auf der liegen schon ca. 10TB an Daten also doch, wurde in dem System benutzt

Hallo zusammen, ich hab wie oben geschrieben ohne für mich ersichtlichen Grund plötzlich bei einer neuen Festplatte den Zustand Unmountable: wrong or no file system. Ich war aktuell dabei sehr viel mit kometa zu arbeiten und die Plex Mediathek zu überarbeiten, dann wurde die ganze Kiste sehr langsam mit nahezu 100% Prozessor Auslastung. Plex und kometa Container neu gestartet, soweit wieder gut und dabei ist mir die ausgefallene Festplatte ausgefallen. Server wurde nicht bewegt. Jemand ne Ahnung? Gruß tower-diagnostics-20250826-0321.zip

Liegt tatsächlich auf nem btrfs Pool. Der wird in den kommenden Tagen aber ohnehin gegen zfs getauscht. Danke für den Einwand.

Ah okey, danke. Aber kann es kann doch eigentlich nicht sein, das ich das bei jedem Update von jD machen muss und jetzt auch mal so random mittendrin weil ich mich erdreistet hab den container aus- und wieder einzuschalten?

Danke dir. Das versteh ich nicht

Hallo, habe vorhin meinen jD vontainer versehentlich gestoppt und dann wieder gestartet. Seitdem komme ich nicht mehr per VNC drauf. Die Logs sagen "Invalid or corrupt jarfile /jDownloader2/jDownloader.jar". jd log.txt tower-diagnostics-20250414-1555.zip

Bist der Beste, vielen Dank

Dann muss es JF sein, was die Probleme verursacht. Den hab ich tatsächlich in den letzten Tagen mal getestet (und werde es vermutlich auch nicht weiter nutzen :D). Sehe jetzt auch gerade, dass der cache-Pfad gar nicht konfiguriert ist. Reicht es, den Pfad zu konfigurieren und der Rest geht automatisch oder muss in JF noch was iengestellt werden?

Transcode hat seinen eigenen Ordner.

Danke schonmal. Hab jetzt noch nen unbenutzten Container gelöscht, was mir ca. 3,5GB gegeben hat. Aber bin trotzdem noch bei 15GB, obwohl nur 10 laut Container Size. Hab mir auch die Container Configs jeweils angeschaut, kann aber nichts sehen, was Daten im Image ablegt. Ich nehm ja an, dass das Image in irgendeiner der Configs als Speicherort angegeben sein müsste, richtig?

Unraid v7 Moin, mein Docker Image ist voll gelaufen auf 94%. Das muss aber ein Fehler sein. Wie kann ich das prüfen und vor allem wie kann ich das beheben Danke schonmal tower-diagnostics-20250222-2038.zip

Es wird Lösung b Danke dir Es läuft ein tägliches Backup. Rate wohin Bin gerade dabei meine gesamte Server/Storage-Landschaft umzustellen mit externen Backups etc. Danke dir vielmals für die Hilfe, ich werde berichten falls was nicht klappt

Das hab ich tatsächlich sogar erstellt. Ich hab nciht dran gedacht. Neuen Stick genommen, Unraid Installer laufen lassen und dann alle sachen vom alten Stick neu drauf kopiert. Dann Lizenz für den neuen Stick aktiviert. Jetzt wo ich es so schreibe merke ich selbst wie dumm das war. Okey, also wie is das Vorgehen jetzt? Weiterhin wie du beschrieben hast, nackte Installation und testen oder ergibt sich jetzt ein neues Vorgehen?

Hab sogar anderen PC benutzt.

Hi, mir ist heute mein Stick abgeraucht. Konnte ihn dann noch unter Windows sichern und hab alles runter kopiert. Neuen Stick erstellt, alles an Daten wieder drauf kopiert, Lizenz aktiviert. Seitdem sind alle Docker Container Pools weg. Dashboard geht ebenso nicht mehr (leere Seite). Was kann ich tun um alles wieder zu bekommen?

Mir kommt da grad so ne Idee: angenommen dem LSI wirds zu warm, könnte das Fehlerbild dann damit übereinstimmen? Nur ne Theorie, bisher lief alles immer gut ohne extra Lüfter.

Danke für deine Nachricht. Heißt für mich jetzt abwarten bis der neue Sata-HBA da is und dann meld ich mich nochmal. Wenn der da ist muss ich ja die Platten alle wieder anschließen. Wie stell ich fest welcher logische Port zu den physischen passt? Oder denkst du einfach mal probieren und parity in Port 1, data1 in 2 usw.? Oder hast du noch Ideen zum troubleshooting?

So, ich bin jetzt dabei die 4TB Platte wieder einzubauen aber ich weiß trotzdem nicht so ganz genau was das bringen soll. Das System kennt ja schon die 12TB (da war vorher die 4er drin) und hat die auch schon mit ins System eingebunden, somit is die Platte schon in Benutzung. Sie ist, wie ich vorher geschrieben hab, aber deaktiviert weil es beim Rebuild zu Fehlern gekommen ist. Ich hab die 12er jetzt aus dem Array genommen und hab die 4er an die Stelle eingesetzt aber logischerweise sagt mir das System das ich die nicht wieder einsetzen kann, weil sie zu klein ist. Wie gehts jetzt weiter?

Ja das is soweit korrekt. Jede Platte die jemals getauscht wurde, ist immer wieder an die gleiche Stelle gekommen. Anders gehts ja auch gar nicht ohne dein Array zu shreddern. Das mit der Parität wird nicht funktionieren, da die alte ne 4TB is und die neue ne 12er

Neue Platten lass ich immer in nem anderen Server durch das preclear laufen. Ich will eigentlich auf dem "Prod" Server nichts "rumprobieren", was ich nich auch auf dem anderen Server machen kann. Die neue Platte hab ich dann hier eingebaut und wie im Wiki ausgetauscht. Was genau meinst du damit? Meinst du so wie es im Wiki steht wie eine Platte ausgetuascht wird? Die alte Platte kann ich schon nochmal umbauen, ich bin halt echt nicht scharf drauf weil ich glaube, dass mein System aktuell eh schon in einem Naja-Status ist. Bitte jetzt keinen Vortrag über kein Backup blabla.

sind exakt gleich groß Damit meinst du Disk 1?

Hab eine neue Festplatte eingebaut und ins System eingebunden (Disk 4), das ist irgendwie schief gelaufen und die Platte wird als disabled angezeigt. Habe hier versucht etwas zu unternehmen mit Google und Forum aber nicht wirklich weit gekommen. Im Zuge dessen habe ich unter anderem einen Check gemcaht und der hat dann sehr viele Fehler an zwei Platten angezeigt (die vorher gar keine Probleme hatten). Vor 4 Wochen habe ich Platte 5 neu eingesetzt und es gabe keine Probleme, zwischendurch ist auc ein weiterer Parity Check gelaufen, ebenfalls ohne Probleme. Da der Kommentar kommen wird: Server runtergefahren und alle Sata Kabel neu gesteckt und weiterhin Fehler. Da wäre auch mal die Frage warum Unraid so anfällig für das Problem ist und welche Kabel man verwenden kann, dass das nicht mehr passiert? Der Server steht in der Ecke und wird in Ruhe gelassesn. Mittlerweile geht im System übrigens nicht mehr wirklich was - kein Docker, keine Shares. tower-diagnostics-20241013-1134.zip