Share ist amok gelaufen - Wie Dateisystem prüfen, korrigieren oder Disk neu formatieren?

[DataCollector]

Hallo.

 

Lange Vorrede (Kann man überspringen, Zu meinen Fragen geht es bei dem Symbol👀) :

 

Unraid mit inzwischen 11 Disks ohne Parity im Array mit XFS.
Während dem Befüllen eines Share mit 2 included Disks (Disk 6+7 mit jeweils nun rund 700GB Daten) im Array ist Disk 6 verstorben.
Also habe ich das Array gestoppt, die defekte Disk 6 entfernt, eine andere dort eingesetzt, das Array über new config gelöscht und wieder neu zusammengestellt (alle Disks an der gleichen Stelle wie vorher, ausser die neue eben an dem Platz der defekten Disk 6) und gestartet.
Dann von anderem PC das Share per LAN versucht wieder zu befüllen. Alles was vorhanden ist, sollte übersprungen werden, somit hat der externe Win10 PC mit TotalCommnander ja nur die verloren gegangenen Daten übertragen und geschrieben.
Später schaute ich in den Tab MAIN und sah, dass sich der Füllstand einer ganz anderen Disk 11 erhöhte.
Ich habe den Kopiervorgang am Windows PC gestoppt und mir die Sharekonfiguration auf unraid angesehen, aber dort steht weiterhin included Disks 6+7 eingestellt.
Ich habe dann im Tab Main rechts auf die Inhaltsanzeige von Disk 6 geklickt: leer (=kein Unterverzeichnis zu sehen).
Inhaltsanzeige von Disk 11 geklickt: wirklich, dort sind die fehlenden Dateien aufgetaucht.
Nochmal die Sharekonfiguration angesehen, aber dort steht immer noch included Disks 6+7.

Docker angeworfen und den ich777/krusader gestartet.
Mit krusader den Inhalt von Disk 7 und 11 versucht auf die neue Disk 6 zu verschieben und dabei auch zu konsolidieren.

 

 👀  Ab hier komme ich zur Frage im Betreff 👀:
krusader behauptet alles verschoben zu haben, beschwert sich aber, daß er auf Quell Disk 11 ein Verzeichnis nicht löschen kann.
Ich habe nachgesehen auf Disk 11 ist immer noch der Name des Share, dass dort nicht hin gehört mit absteigenden Unterverzeichnissen und in dem tiefsten Unterverzeichnis sind 2 Dateien mit 0 Byte Länge, die Namen tragen, die meiner Erinnerung nach eigentlich Verzeichnisnamen sein sollten.
Alles andere ist von Disk 11 weg.

Mit krusader bekomme ich die Dateien nicht weg, auch nicht wenn ich die darüber legenden Verzeichnisse zu löschen versuche.

Mir geht es nicht um die Daten. Die sind an der Quelle im anderen PC noch vorhanden.

 

Ich habe in unaid herumgesucht finde aber nicht was ich suche:
- Wie kann ich ein Dateisystem eoiner XFS formatieren Disk ueberpruefen und ggf. reparieren lassen? (unter Windows würde ich sowas wie chkdsk suchen).

 

- Sollte sich danach das Share (auch nach neuem Booten) weiterhin falsch verhalten: Wie kann ich ein Share in unraid löschen? Unraid behauptet da sind noch Daten drin (und bezieht sich wohl auch auf Disk 6, welche als einziges auftaucht, wenn ich mit compute versuche rauszufinden auf welchen Disks das Share wirklich liegt. Wegen sehr vieler kleiner Dateien dauert Compute fast 30 Minuten). Ich dachte schon es sei abgestürzt.

- Sollte sich auch weiterhin etwas falsch verhalten wäre es das einfachste die beiden Disks einfach neu zu formatieren. Aber wie formatiere ich in unraid Disks, wenn sie schon XFS formatiert sind und Daten enthalten? (Array stoppen, new config, preclear, wieder zusammenstellen und Array neu starten? Geht das nicht gezielter?).

 

Irgendwie bemerke ich nun, dass mir Kenntnisse über grundlegende Diskoperationen in unraid zu fehlen scheinen um das Problem zu lösen.

P.S.: Im schlimmsten Falle werde ich die gesamte unraid-maschine wieder komplett löschen (auch Disks überschreiben) und wieder komplett neu aufsetzen und auch komplett neu befüllen müssen. Aber damit sind dann wieder ein paar Tage Zeit futsch und ich würde gerne erst einmal sehen wo ich die vermissten Datei- & Diskoperationen übersehe.

 

[hawihoney]

Hast Du disk11 in den Share Settings rausgenommen? Also entweder bei Included Disks entfernen oder bei Excluded Disks hinzufügen.

 

Wenn Du Dir sicher bist, dann würde ich den Share unterhalb von /mnt/disk11 mit mc auf der Konsole löschen. So aus der Ferne kann ich mir nicht vorstellen, dass eine FS Überprüfung notwendig ist. Sollte das mit mc nicht gehen, erst dann wäre eine Überprüfung angesagt.

 

[DataCollector]

Hallo.

 

38 minutes ago, hawihoney said:

Hast Du disk11 in den Share Settings rausgenommen? Also entweder bei Included Disks entfernen oder bei Excluded Disks hinzufügen.

Disk 11 war mal kurz in einem anderen Share (Nummer 3) includiert.

Aber nicht in dem Share (Nummer 2 enthält nur Disk 6 +7 includiert) von dem es dann überraschenderweise Daten gespeichert hat.

 

38 minutes ago, hawihoney said:

Wenn Du Dir sicher bist, dann würde ich den Share unterhalb von /mnt/disk11 mit mc auf der Konsole löschen.

 

MC? MidnightCommander?

Bisher fummele ich auf unraid direkt nur mit krusader im ich777 Dokker herum und der konnte die überflüssigen Verzeichnisse nicht löschen.

Nachdem ich im Maintenance Modus mehrere CHECK-Abläufen auf Disk11 durchgeführt habe, die alle so schnell beendet waren, daß ich vermutete, daß xfs_repair gar nichts getan habe (trotz entfernen von -n), konnte zwar krusader weiter dort nichts entfernen, aber ich konnte das Verzeichniss mit seinen Unterverzeichnissen über die externe Windowsmaschine auf der Netzwerkfreigabe umbenennen und dann löschen. Danach waren die Verzeichnisse auch auf Disk11 verschwunden.

 

 

38 minutes ago, hawihoney said:

So aus der Ferne kann ich mir nicht vorstellen, dass eine FS Überprüfung notwendig ist. Sollte das mit mc nicht gehen, erst dann wäre eine Überprüfung angesagt.

 

Ich muss mal schauen, wie man den MidnightCommander in unraid einbindet.

 

Danke für die Antwort!

[mgutt]

11 hours ago, DataCollector said:

Ich habe dann im Tab Main rechts auf die Inhaltsanzeige von Disk 6 geklickt: leer (=kein Unterverzeichnis zu sehen).
Inhaltsanzeige von Disk 11 geklickt: wirklich, dort sind die fehlenden Dateien aufgetaucht.

Das ist nur eine Mutmaßung, aber Unraid wird ja intern irgendwo festhalten welche Platte als nächstes mit Befüllen dran ist und wenn Disk6 zu dem Zeitpunkt bereits voll war, hatte er ja schon bis 11 gezählt. Ich vermute daher, dass er 6 erst befüllt, wenn 11 voll ist. Aber wie gesagt nur eine Vermutung. Du könntest ja mit New Codnig 11 und 6 später tauschen, wenn dir die Position der Daten wichtig ist 😉

 

11 hours ago, DataCollector said:

Wie kann ich ein Share in unraid löschen? Unraid behauptet da sind noch Daten drin

 

1.) Siehst du auf der Share Seite rechts über das Ordnersymbol auf welchen Disks noch Dateien von einem Share liegen

 

2.) Kannst du einen Share mit diesem Kommando löschen:

rm -rI /mnt/user/sharename

 

Wenn du nur den Share-Ordner auf Disk 11 löschen möchtest, dann so:

rm -rI /mnt/disk11/sharename

 

11 hours ago, DataCollector said:

krusader behauptet alles verschoben zu haben, beschwert sich aber, daß er auf Quell Disk 11 ein Verzeichnis nicht löschen kann.

Ungewöhnlich, wird aber an den Rechten dieser Dateien liegen. Du könntest über das Terminal mit "ls -la /mnt/user/usw..." die Rechte der Dateien anzeigen lassen.

 

11 hours ago, DataCollector said:

Wie kann ich ein Dateisystem eoiner XFS formatieren Disk ueberpruefen und ggf. reparieren lassen?

Array im Wartungsmodus starten, auf "Disk 11" in der Disk Übersicht klicken und Check Filesystem ausführen. Mehr dazu in der Hilfe:

https://wiki.unraid.net/Check_Disk_Filesystems#Drives_formatted_with_XFS

 

11 hours ago, DataCollector said:

das einfachste die beiden Disks einfach neu zu formatieren

Brauchst du nicht. Das ändert nichts.

 

Normaler Weg wäre aber aus dem Array entfernen und über das UD Plugin formatieren.

 

11 hours ago, DataCollector said:

Im schlimmsten Falle werde ich die gesamte unraid-maschine wieder komplett löschen (auch Disks überschreiben) und wieder komplett neu aufsetzen und auch komplett neu befüllen müssen

Auch das brauchst du nicht. Unraid installiert sich bei jedem Booten neu in den RAM und welche Daten auf den Platten sind, ist Unraid absolut egal. Für Unraid ist zb ein Ordner im Root einer Festplatte ein Share. Wenn du also das hier ausführst um einen Ordner auf Disk 11 zu erstellen, dann hast du einen neuen Share:

mkdir /mnt/disk11/testshare

So simpel funktioniert Unraid. Da laufen keine besonderen Installationen im Hintergrund. Und was in einem Share liegt, interessiert Unraid schon mal gar nicht. Also mach dir nicht unnötig Arbeit. Es ist alles gut so wie es ist. Das liegt einfach nur an der aktuellen Verteilungsregel. Ich vermute, wenn der Shareordner auf Disk6 und Disk11 weg ist und du die Verteilungsregel kurz hin und her änderst, dass der dann auch wieder Disk6 verwendet. Kannst du ja leicht testen, in dem du manuell eine Datei hochlädst.

 

[hawihoney]

23 minutes ago, mgutt said:

rm -rI /mnt/user/sharename

 

Vorsicht: Der OP spricht explizit von disk11. /mnt/user/ würde den Share auf allen Platten löschen.

 

Edited July 7, 2021 by hawihoney

[DataCollector]

Hallo

 

6 minutes ago, mgutt said:

Das ist nur eine Mutmaßung, aber Unraid wird ja intern irgendwo festhalten welche Platte als nächstes mit Befüllen dran ist und wenn Disk6 zu dem Zeitpunkt bereits voll war, hatte er ja schon bis 11 gezählt.

Zur Vollständigkeit: Keine Disks im Array war oder ist voll.

Alles sind 8TB grosse Disks.

Share Nummer 1 hat die Disks 1-5 mit aktuell 10 TB Gesamtfuellung auf die 5 Disks verteilt.

 

Der Füllstand des Share2 (included Disks 6+7) lag bei rund 700 GB auf jeder dieser beiden Disks (also zusammen rund 1,4TB auf 2 Disks).

Disk 11+12 hingegen waren vorher als unmounted Device Precleared worden und somit leer.

Disk 12 wurde dann dort eingesetzt wo Disk 6 ausgefallen ist und im Array (nach New config) auch dort als Disk 6 angemeldet.

Share Nummer 2 hatte vorher, wie auch nachher die Einstellung include Disk 6+7. (Diese neue Disk6 war ja leer und wurde frisch xfs formatiert, die alte Disk7 war da ja weiter mit rund 700GB aufkopierten daten gefuellt, also noch mehr als 7TB frei.)

 

Disk 11 wurde als zusätzliches Laufwerk im Array angemeldet und dort einem anderen Share (dem 3. Share) als include Disk 8-11) zugeschlagen, weil die bisherigen Disks 8-10 einen Füllstand von je ca. 86% erreicht hatten.

 

Ich kann also ausschliessen, daß irgendeine der Disks zu voll geschrieben war um weitere Daten aufzunehmen.

 

Aber Deine Mutmassung bringt mich auf die Idee, daß Unraid evtl. nicht vollständig mitbekommen hat, daß Disk6 ersetzt wurde (trotz neu zusammengestelltem Array) und deshalb dachte die Disk sei weiterhin ausgefallen/unnutzbar und dann ausgwichen ist.

Das wäre zumindest eien Erklärung, die aber darauf fußt, dass unraid sowas irgendwie nicht ganz verarbeitet.

Um dies zukuenftig auszuschließen, werde ich nach Arrayänderungen wohl zukuenftig einmal neu booten.

 

 

6 minutes ago, mgutt said:

Ich vermute daher, dass er 6 erst befüllt, wenn 11 voll ist. Aber wie gesagt nur eine Vermutung. Du könntest ja mit New Codnig 11 und 6 später tauschen, wenn dir die Position der Daten wichtig ist 😉

 

Die Position meiner Daten ist mir wichtig. Wie in anderem Beitrag schon angedeutet, befülle ich erst einmal mit maximaler Geschwindigkeit (deswegen auch noch kein Parity und mit Share 'most free'), werde dann aber so sortieren, daß die Dateien/Verzeichnisse alphabetisch aufsteigend zusammen sind. Danach wird alles binaer mit der Quelle verglichen. Sollte dann alles okay sein erzeuge ich die Parität(en).

Ich bin noch unschjlüig ob ich 1 oder 2 Disks dafür nehme. Aufgrund des Einsatzes alter gebrauchter Disks wohl eher 2 Parity, da Ausfälle bei alten Disks unter Belastung doch passieren (wie ich auch hiermit wieder sehe).

Ist es eigentlich schneller die 2 Paritätsdisks gleichzeitig erstellen zu lassen oder sequentiell nacheinander (erst P1  und danach P2)?

 

6 minutes ago, mgutt said:

1.) Siehst du auf der Share Seite rechts über das Ordnersymbol auf welchen Disks noch Dateien von einem Share liegen

Das war ja das Problem.

View Disk 6 hatte keine Daten bekommen oder dort angezeigt.

View Disk 11 hatte hingegen die neu ueberspielten Daten bekommen udn die waren dort auch zu sehen.

Als ich diese dann von Disk 11 und 7 auf der leeren Disk 6 zusammengeführt habe, kam das fragliche Verzeichnis auf Disk 11 zum Vorschein, welches durch 2 Stück Null Byte Dateien blockiert war und sich nicht löschen ließ.

Das Problem wurde nun mit mehrfachem Check im Maintenancemodus auf Disk 11 und Zugriff von FremdPC (Win10 TotalCommander) gelöst.

 

6 minutes ago, mgutt said:

2.) Kannst du einen Share mit diesem Kommando löschen:

rm -rI /mnt/user/sharename

 

Das werde ich mir für zukünftige Probleme vermerken.

Danke Dir!

 

6 minutes ago, mgutt said:

Ungewöhnlich, wird aber an den Rechten dieser Dateien liegen. Du könntest über das Terminal mit "ls -la /mnt/user/usw..." die Rechte der Dateien anzeigen lassen.

 

Zum Glück ist das Problem auf Disk11 nun durch die oben beschriebene CHECK+WIn10PC Aktion weg.

 

 

6 minutes ago, mgutt said:

Array im Wartungsmodus starten, auf "Disk 11" in der Disk Übersicht klicken und Check Filesystem ausführen. Mehr dazu in der Hilfe:

https://wiki.unraid.net/Check_Disk_Filesystems#Drives_formatted_with_XFS

 

Danke Dir. Die haben ich dann heute morgen auch gefunden und danach gehandelt.

Es war heute Nacht wohl doch zu spät als dass ich diese Info gefunden habe, bzw. ich war wohl zu fahrig bei meiner nächtlichen Suche.

 

 

6 minutes ago, mgutt said:

Brauchst du nicht. Das ändert nichts.

Normaler Weg wäre aber aus dem Array entfernen und über das UD Plugin formatieren.

 

Da dieser Weg (unmounted Devices + Preclear) weitaus länger dauert als eine schnelle Formatierung hatte ich gehofft es mit einer Formatierung eben flotter hin zu bekommen, wenn vorherige Maßnahmen keinen Erfolg gezeigt hätten.

 

6 minutes ago, mgutt said:

Auch das brauchst du nicht. Unraid installiert sich bei jedem Booten neu in den RAM und welche Daten auf den Platten sind, ist Unraid absolut egal. Für Unraid ist zb ein Ordner im Root einer Festplatte ein Share. Wenn du also das hier ausführst um einen Ordner auf Disk 11 zu erstellen, dann hast du einen neuen Share:

mkdir /mnt/disk11/testshare

So simpel funktioniert Unraid.

 

Ja, das hatte ich im Rahmen meiner Lektuere der krusaderanleitungen für unraid gelesen. So würde man ein neues Share erstellen und das wäre dann sichtbar. Deshalb sollte man damit aufpassen im Hauptverzeichnis etwas zu erstellen, weil man dann sich noch manuell um die Rechte/Freigaben kümmern sollte.

 

 

6 minutes ago, mgutt said:

Da laufen keine besonderen Installationen im Hintergrund. Und was in einem Share liegt, interessiert Unraid schon mal gar nicht.

Ja, so habe ich es auch bisher festgestellt.

Wobei ich bei den beiden 9 Byte Dateien nun festgestellt habe, es waren wirklich mal Unterverzeichnisse mit noch weiteren Unterverzeichnissen und darin je eine Exe Datei (installationsdateien für PC).

Das einzig auffaellige war, durch die Baumstruktur war es ein sehr langer Pfad und er enthielt leerzeichen und deutsche Umlaute.

Da sowas aber bei benachbarten Verzeichnissen auch bisher kein Problem war, kann ich mir weiterhin nicht erklaeren, warum diese Verzeichnisse am Ende als 0 Byte Dateien auftauchen und alles blockiert haben.

Aber dann war es eben ein Schluckauf des Systemes. Kann passieren. Dafür hat man ja mindestens ein Backup,

 

Wie schon mehrfach geschrieben: Danke sehr!!

[hawihoney]

1 hour ago, DataCollector said:

Ich muss mal schauen, wie man den MidnightCommander in unraid einbindet.

 

Der ist standardmäßig installiert. Du öffnest die Konsole und gibst "mc" ein. Voila.

 

MC ist ein Norton Clone. Die gleichen Befehle, etc. So hat man schon vor über 30 Jahren mit Dateien gearbeitet.

 

Es gibt nur eine Besonderheit. Die Linux Konsole läuft in einer Session. Und wenn diese Session endet, stirbt auch mc. Für kurze Dateioperationen wie in Deinem disk11 Share Fall ist das kein Problem. Für länger laufende Dateioperationen benötigt man also eine Vorkehrung. Das erldigen Tools wie "screen", o.ä. Aber das soll Dich im Moment nicht stören. Für Deinen kleinen disk11/Share Eingriff reicht mc ohne Vorkehrung.

 

 

### Nur weiter lesen wenn wirklich notwendig

 

screen ist Bestandteil des Plugins NERD Pack - zu finden über die Unraid Community Applications. Wenn das Nerd Pack Plugin installiert ist, dann gibt es in den Unraid Settings hierzu ein neues Icon. Klickt man da drauf, dann erscheinen alle Tools die zusätzlich installiert werden könnten. Klick in der Zeile mit screen rechts außen auf den Radiobutton --> On.

 

Anschließend ist screen installiert.

 

Unraid Konsole auf dem Server öffnen

screen <Enter>       # Aufruf von screen

<Enter>                  # Entfernt die screen Logo Anzeige

CTRL-a c                # Jetzt steht Dein Cursor in einer neuen Session

mc <Enter>            # Midnight Commander startet in einer eigenen nicht unterbrechbaren Session

 

Sollte die ursprüngliche Session mal abbrechen (Stromsparmodus, etc.) Dann bekommst Du die Session mit dem laufenden mc wie folgt wieder:

 

Unraid Konsole auf dem Server öffnen

screen -r <Enter>    # Holt die aktuelle Session in den Vordergrund - nur wenn es genau eine Session ist

 

screen -list <Enter> # Wenn -r nicht funktionieren sollte, dann erhält man auf diese Weise alle laufenden Sessions

screen -r <sessionBezeichnung> <Enter>

 

Edited July 7, 2021 by hawihoney

[DataCollector]

Hallo.

 

1 minute ago, hawihoney said:

Der ist standardmäßig installiert. Du öffnest die Konsole und gibst "mc" ein. Voila.

 

Na das ist ja einfach. Wusste ich noch nicht. Danke sehr!!

Da sehe ich wieder, daß ich auch nach nun rund 3 Monaten bei Unraid und dem darunter liegenden OS noch gaaaaanz am Anfang stehe.

 

1 minute ago, hawihoney said:

MC ist ein Norton Clone. Die gleichen Befehle, etc. So hat man schon vor über 30 Jahren mit Dateien gearbeitet.

 

Ja, ich habe nach Commodore VIC20 und C64 dann sehr früh mit MS-DOS 4.x gestartet und zu DOS Zeiten war der NC schon wirklich ein Durchbruch und ein sehr wichtiges udn schlankes Tool.

 

1 minute ago, hawihoney said:

Es gibt nur eine Besonderheit. Die Linux Konsole läuft in einer Session. Und wenn diese Session endet, stirbt auch mc. Für kurze Dateioperationen wie in Deinem disk11 Share Fall ist das kein Problem. Für länger laufende Dateioperationen benötigt man also eine Vorkehrung. Und Tools wie "screen", o.ä. Aber das soll Dich im Moment nicht stören. Für Deinen kleinen disk11/Share Eingriff reicht mc ohne Vorkehrung.

 

Ich werde es im Hinterkopf behalten. Gut zu wissen,d aß da noch mehr Toopls vorhanden sind, die ich noch nicht gefunden habe und helfen können. Danke!

 

1 minute ago, hawihoney said:

### Nur weiter lesen wenn wirklich notwendig

Bin neugierig und ob es evtl. spaeter notwendig wird, weiss ich erst später

 

 

1 minute ago, hawihoney said:

screen ist Bestandteil des Plugins NERD Pack - zu finden über die Unraid Community Applications.

Ja, das habe ich wegen Peral drauf um die Temperaturanzeigen zu ermöglichen (auch wenn och von den Temperaturanzeigen von Dynamix System temp eher enttäuscht bin).

 

1 minute ago, hawihoney said:

Wenn das Nerd Pack Plugin installiert ist, dann gibt es in den nraid Settings hierzu ein neues Icon. Klickt man da drauf, dann erscheinen alle Tools die zusätzlich installiert werden könnten. Klick in der Zeile mit screen rechts außen auf den Radiobutton --> On.

 

Das werde ich mal demnächst ausprobieren.

 

Auch hierfür Danke!

 

[hawihoney]

10 minutes ago, DataCollector said:

Das wäre zumindest eien Erklärung, die aber darauf fußt, dass unraid sowas irgendwie nicht ganz verarbeitet.

Um dies zukuenftig auszuschließen, werde ich nach Arrayänderungen wohl zukuenftig einmal neu booten.

 

Ganz ehrlich, das ist Quatsch. Du hast das Unraid Array gestoppt, eine Ersatzplatte eingebaut, Unraid die Platte rekonstruieren lassen und Unraid soll das nicht mitbekommen haben. Bei allem Respekt - Blödsinn. Du hast Dir eine manuelle Vorgehensweise ausgedacht und ich vermute, wie gesagt ich vermute, dass diese in Teilen nicht ganz Unraid-konform ist. Bei preclear zu langsam, manuell formatieren, bin ich ausgestiegen. Bitte, in Deinem eigenen Interesse, setzt Dich bitte noch mal mit den Aktivitäten rund um das Array und den Shares auseinander.

 

Linux ist nicht Windows.

 

[mgutt]

4 minutes ago, DataCollector said:

Da dieser Weg (unmounted Devices + Preclear)

Ich sagte UD Plugin. Nicht Pre-Clear.

 

6 minutes ago, DataCollector said:

Share2 (included Disks 6+7)

Und da hat er trotzdem auf Disk 11 geschrieben? Das darf eigentlich nicht passieren.

 

7 minutes ago, DataCollector said:

schneller die 2 Paritätsdisks gleichzeitig erstellen zu lassen oder sequentiell nacheinander

Gleichzeitig.

 

9 minutes ago, DataCollector said:

ein sehr langer Pfad und er enthielt leerzeichen und deutsche Umlaute.

Da sowas aber bei benachbarten Verzeichnissen auch bisher kein Problem war, kann ich mir weiterhin nicht erklaeren, warum diese Verzeichnisse am Ende als 0 Byte Dateien auftauchen und alles blockiert haben.

Aber dann war es eben ein Schluckauf des Systemes.

Wenn dann liegt das an Windows. Linux ist deutlich flexibler was Länge, Zeichen, usw anbelangt.

 

 

[DataCollector]

14 minutes ago, mgutt said:

Ich sagte UD Plugin. Nicht Pre-Clear.

 

Die Formatoption in UD selber war bei mir noch nie orange (= benutzbar) ist bei allen unmounted Devices bisher ausgegraut gewesen.

Siehe auch beil. Bildschirmausschnitt (da ist eine precleared 8TB und eine 12TB mit Daten zu sehen).

 

Quote

Und da hat er trotzdem auf Disk 11 geschrieben? Das darf eigentlich nicht passieren.

 

Deshalb ja meine Verwunderung und meine Vermutung, zu einem Schluckauf des Systemes..

 

Edited July 7, 2021 by DataCollector
Screenshot hinzugefügt

[DataCollector]

Hallo

 

25 minutes ago, hawihoney said:

Ganz ehrlich, das ist Quatsch. Du hast das Unraid Array gestoppt, eine Ersatzplatte eingebaut, Unraid die Platte rekonstruieren lassen

Bevor es falsch rüber kommt präzisiere ich: Ich habe die Platte nicht rekonstruieren lassen, weil das aufgrund von fehlener Parity ja nicht geht.

Ich habe eine leere Platte dort eingesetzt, das Array mit den verbliebenen Platten und der Ersatzplatte in korrekter Reihenfolge wieder neu konfiguriert und dann das Array gestartet. Als nächstes die neu hinzui gekomme Platte formatieren lassen. Und dann versucht neu über LAN zu befüllen.

Dabei kam es eben zu dem beschriebenen Verhalten.

 

25 minutes ago, hawihoney said:

und Unraid soll das nicht mitbekommen haben. Bei allem Respekt - Blödsinn.

Ich würde mich über eine bessere Erklärung freuen, warum unraid dann auf eine ganz andere Disk geschrieben hat, die dem beschriebenen Share nie zugeordnet war.

 

25 minutes ago, hawihoney said:

Du hast Dir eine manuelle Vorgehensweise ausgedacht und ich vermute, wie gesagt ich vermute, dass diese in Teilen nicht ganz Unraid-konform ist.

Wie würdest Du in der Situation vorgehen?

Ich würde mich freuen, wenn ich herausfinde, was ich falsch gemacht habe.

 

25 minutes ago, hawihoney said:

Bei preclear zu langsam, manuell formatieren, bin ich ausgestiegen.

 

Das war ein Wunsch. Keine Ausfuehrung.

Du bist anscheinend schon vorher ausgestiegen.

 

 

[hawihoney]

24 minutes ago, DataCollector said:

Ich würde mich über eine bessere Erklärung freuen, warum unraid dann auf eine ganz andere Disk geschrieben hat, die dem beschriebenen Share nie zugeordnet war.

 

Ich will solche Ergebnisse nicht ausschließen, denn ich kenne den Code nicht. Aber: In meinen 13 Jahren mit Unraid, dutzenden Installation, verarbeiteter Plattenplatz im PB Bereich und 100-200 getauschten Festplatten ist das hier noch nie vorgekommen. IMHO, ist Unraid eines der stabilsten NAS Systeme, das mir in meinen über 40 IT Jahren untergekommen ist. Unraid schreibt nicht auf eine disk11 in einen Share wenn diese disk11 weder explizit noch implizit Bestandteil des Shares ist.

 

Zum Punkt: Man steckt ja nicht von außen in Deiner Installation. Ich kann nur vermuten, dass a.) der Kram schon vorher drauf war (e.g. nicht gecleared, nicht formatiert) oder b.) durch eine falsche Position des Pointers im Datei-Explorer/Krusader kopiert wurde oder c.) die Datei/der Share während des Löschvorgangs schon anderweitig im Zugriff war.

 

Was ich in einer solche Situation machen würde? Schritt für Schritt! Heute will jeder alles und zwar sofort. Das geht oft schief. Also: Alles abschalten was für das Verschieben der Daten nicht benötigt wird. Egal ob Plugins, Dockers, etc. Einfach abschalten. Und dann mit einer Instanz des Verschiebens beginnen. Gucken ob es läuft, beobachten wie die Verteilregeln für diesen einen Prozess ziehen. Erst danach, wenn Du zufrieden bist, würde ich mit einem weiteren parallelen Prozess starten. Auf keinen Fall die gleichen Platten/Shares befüllen wenn man sich nicht absolut sicher ist. Das ist meine Meinung. Man muss den Systemen auch Luft geben. Ich kann das nicht besser sagen. Ich sehe viele Leute Klick, klick, klick auf den selben Button klicken, weil es ihnen zu langsam geht. Das geht meistens schief. Einfach mal relaxen und einen Schritt nach dem anderen.

 

Edited July 7, 2021 by hawihoney

[mgutt]

1 minute ago, DataCollector said:

Schluckauf

 

Unwahrscheinlich. Habe ich auch noch nie gehört, dass das passiert. Das einzige was sein kann ist das:

 

Mein TV Share enthält ausschließlich Disk 5:

 

Alle Dateien liegen aktuell auf disk5. Ich erstelle nun auf dem Cache, auf der deutlich leereren disk6 und über SMB Test-Dateien:

 

Wie du siehst, sehen wir die Datei test5, obwohl sie sich auf disk6 befindet, die eigentlich nicht Teil dieses Shares ist. Bei der Ausgabe ignoriert Unraid also die gewählten Disks. Nun werfe ich den Mover an und wir sehen, dass dieser nur die Dateien vom Cache auf disk5 bewegt hat. Die auf disk6 bleibt unangetastet:

 

Warum hält sich Unraid bei der Ausgabe der Dateien nun nicht strikt an die Einstellung? Ich vermute die Entwickler wollten so vermeiden, dass wenn ein User die Disk-Zuordnung wechselt, dass es dann passieren kann, dass der selbe Dateiname 2x auf dem Array vorhanden ist bzw dass er nicht denkt, dass seine Dateien plötzlich gelöscht seien.

 

Was aber nun daran interessant ist: Wenn ich die Datei test5 über SMB überschreibe, dann landet sie nicht auf dem cache (obwohl für diesen Share der Cache aktiv ist), auch nicht auf disk5, sondern sie wird direkt auf disk6 überschrieben:

 

 

Das erklärt nicht warum auf deiner disk11 Dateien erstellt wurden, aber wie du siehst passiert das eigentlich nur, wenn man das erzwingt. Ich hatte jedenfalls noch nie den Fall, dass beim Upload von Dateien eine falsche Disk verwendet wurde.

 

[mgutt]

2 hours ago, mgutt said:

rm -rI /mnt/user/sharename

 

Ok, wegen @hawihoney's Anmerkung dann noch die Variante, wenn man einen Share nur von einer bestimmten Disk löschen möchte 😉

 

rm -rI /mnt/diskX/sharename

 

[hawihoney]

12 hours ago, mgutt said:

Ich vermute die Entwickler wollten so vermeiden, dass wenn ein User die Disk-Zuordnung wechselt, dass es dann passieren kann, dass der selbe Dateiname 2x auf dem Array vorhanden ist

 

Das war in der Anfangszeit von Unraid ein ganz großes Thema. Wird man hier noch in den archivierten Threads finden können.

 

Ein Benutzer legt eine Datei auf /mnt/disk1/Share/bla.txt an (10 Byte Größe). Er vergisst die Datei. Nach Jahren kopiert er eine Datei /mnt/disk2/Share/bla.txt (20 Byte Größe). Jetzt guckt er in /mnt/user/Share und findet seine 10 Byte große Datei nicht mehr. Das gab hier vielleicht Diskussionen. Und dann hat er die neue Datei nach /mnt/disk3/Share2/bla.txt verschoben. Und verdammt, die wurde ja an der Quelle nicht gelöscht. Er hat nur übersehen, dass die alte Datei wieder sichtbar wurde. Das waren Diskussionen.

 

Deshalb: Es schadet nicht sich dem System langsam zu nähern. Unraid macht viele Dinge die andere Systeme nicht machen. Und die macht es sehr gut. Und der Endbenutzer hat einen Benefit dadurch. Dieser zusätzliche Komfort kommt aber mit Eigenheiten, mit denen man sich gedanklich auseinandersetzen muss.

 

Edited July 7, 2021 by hawihoney

[mgutt]

1 hour ago, DataCollector said:

Schluckauf

Ich habe noch einen Test gemacht. Diesmal habe ich Unterordner auf der "falschen" disk6 erstellt:

 

Dann habe ich über SMB eine Datei in diesem Ordner erstellt:

 

Die Datei wurde nun inkl. der Unterordnerstruktur auf dem Cache erstellt:

 

Dann habe ich den Mover angeworfen und zu meiner Überraschung ist die Datei nicht auf disk5 verschoben worden (inkl der Ordner), sondern auf der "falschen" disk6 in den bereits existierenden Ordner:

 

Schlussfolgerung:

Das Split-Level schlägt in dem Fall die Einschränkung auf disk5:

 

Und für deinen Fall heißt das:

Ich vermute du hast versehentlich irgendwie zB mit Krusader den Ordner /mnt/disk11/Sharename/Unterordner erstellt und sobald dieser existiert, werden alle Dateien dieses Unterordners auf disk11 geschrieben, egal ob disk11 Teil von Sharename ist oder nicht.

 

Ich habe es jetzt nicht getestet, aber ich vermute über "exclude disks" könnte man dem nun entgegenwirken, aber so ein Gebastel würde ich sein lassen. Lieber weiter sauber die Dateien dort erstellen lassen, wo sie hin sollen und die Ordner von den anderen Disks runterwerfen.

[DataCollector]

Hallo.

 

39 minutes ago, hawihoney said:

Ich kann nur vermuten, dass

a.) der Kram schon vorher drauf war (e.g. nicht gecleared, nicht formatiert) oder

Da die Disk11 nie mit diesen Daten (=Installationspakete und Backups diverser Windowsmaschinen) befüllt war, spaeter aber genau die Dateien enthielt, die auf der anderen Disk im Share nicht vorhanden waren und diese Daten nur ueber die LAN Kopierung ueber Share bekommen haben kann, schliesse ich a) aus.

 

39 minutes ago, hawihoney said:

b.) durch eine falsche Position des Pointers im Datei-Explorer/Krusader kopiert wurde oder

Da der Krusader zu dem Zeitpunkt damit beschäftigt einige Dutzend TB an Video auf andere Disks zu schreiben und das auch getan hat, schliesse ich das auch aus.

 

39 minutes ago, hawihoney said:

c.) die Datei/der Share während des Löschvorgangs schon anderweitig im Zugriff war.

Welcher Löschvorgang ist gemeint?

Preclear vorher auf Disk11+12? Klar, in der selben zeit wurde auf die Disk6+7 ueber LAN geschrieben, bis eben Disk 6 ausfiel.

 

Der Löschvorgang im Zuge der Verschiebung der Dateien von Disk7 und Disk11 auf die neue Disk6 (ehemals Disk12): Nein, zu dem Zeitpunkt wurde von aussen nicht auf das unraidsystem geschrieben, weil mir die Sache nach den Erlebniss etwas wackelig erschien udn ich unraid nicht zuviel auf einmal zumuten wollte.

 

 

39 minutes ago, hawihoney said:

Was ich in einer solche Situation machen würde? Schritt für Schritt!

Done. Und dabei hat dann nach dem verschieben der Dateien Krusader eben das problem gezeigt, daß es das erwähnte Verzeichnis nicht löschen kann.

 

39 minutes ago, hawihoney said:

Heute will jeder alles und zwar sofort. Das geht oft schief.

 

Aus dem grund habe ich unraid ja erst einmal die Daten nur mit krusader von 7+11 auf 6 kopieren lassen ohne iurgendetwas anderes damit zu machen/fordern. Es liefen keine VM, ich habe nur sehr wenige Plugins laufen, es lief nur 1 Docker (eben der fuer krusader).

 

39 minutes ago, hawihoney said:

Also: Alles abschalten was für das Verschieben der Daten nicht benötigt wird.

Nach dem ich merkte, dass er eben nicht auf 6 sondern 11 schrieb habe ich das und alles andere abgeschaltet und nur noch den Krusader verschieben lassen.

Minimalistischer ging es kaum noch.

 

39 minutes ago, hawihoney said:

Und dann mit einer Instanz des Verschiebens beginnen.

Dann habe ich es ja genau richtig gemacht. Ich habe dann ur noch mit einem Docker von Disk 7+11 auf Disk6 verschoben. Ich habe nichts anderes angestossen.

 

 

39 minutes ago, hawihoney said:

Erst danach, wenn Du zufrieden bist, würde ich mit einem weiteren parallelen Prozess starten.

 

Da nach dem verschieben das Problem mit dem unloeschbaren verzeichnis auftauchte habe ich dann erst einmal gar nichts mehr gemacht und nach einigem erfolglosen Suchen nach entsprechenden CHECK Prozeduren aufgegeben. Heute morgen fand ich dann Anleitung für die Chek-Ablaeufe im Maintenancemodus und konnte das Problem beheben.

Seit dem läuft es wieder so, wie ich es erwarte und habe gegen 10 Uhr erst wieder begonnen Daten aufzukopieren und zu beobachten, wo di hin gehen.

Aktuell ist es so, wie gewuenscht.

 

39 minutes ago, hawihoney said:

Auf keinen Fall die gleichen Platten/Shares befüllen wenn man sich nicht absolut sicher ist. Das ist meine Meinung. Man muss den Systemen auch Luft geben. Ich kann das nicht besser sagen.

Und ich habe es eben mit "Schluckauf" ausgedrückt. Um es in Deine Worte umzuformen: Es hat möglicherweise eben nicht genug Luft bekommen.

 

Danke für Deine Mühe!

[DataCollector]

27 minutes ago, hawihoney said:

Deshalb: Es schadet nicht sich dem System langsam zu nähern. Unraid macht viele Dinge die andere Systeme nicht machen. Und die macht es sehr gut. Und der Endbenutzer hat einen Benefit dadurch. Dieser zusätzliche Komfort kommt aber mit Eigenheiten, mit denen man sich gedanklich auseinandersetzen muss.

 

Und genau deshalb teste ich ja nun schon seit ca. 3 Monaten mit verschiedenen Szenarien und Konstellationen herum.

Das ist mir auch eien Lizenz wert gewesen. Denn das ist nur ein Zwischenschritt.

Wenn ich finde, dass sich unraid für meine Zwecke eignet und ich damit gut genug klar komme, werde ich mir ein grosseres System (300-400TB) aufbauen, dem ich dann die Daten auch zeitweise/temporaer ohne Backup anvertrauen können muss.

Da wäre sowas, wie ich es erlebt habe fatal.

Deshalb ist es zwar nervenaufreibend und verunsichernd, enn ich nun auf probleme stosse und sie mir nicht erklaeren/erforschen/nachlesen kann, aber dadurch lerne ich dazu und kann es besser abschätzen.

 

Und dazu zähle ich sehr wohl auch meine eigenen Fehler, egal ob ich zu fahrig bin, dabei um die falsche Ecke denke, etwas noch nicht weiss oder einfach nur verklicke.

Je eher ich es nachvollziehen oder verstehen kann, desto sicherer werde ich dabei.

 

[DataCollector]

Hallo @mgutt

19 minutes ago, mgutt said:

Ich habe noch einen Test gemacht. Diesmal habe ich Unterordner auf der "falschen" disk6 erstellt:

...

Und für deinen Fall heißt das:

Ich vermute du hast versehentlich irendwie zB mit Krusader den Ordner /mnt/disk11/Sharename/Unterordner erstellt und sobald dieser existiert, werden alle Dateien dieses Unterordners auf disk11 geschrieben, egal ob disk11 Teil von Sharename ist oder nicht.

 

Ich habe es jetzt nicht getestet, aber ich vermute über "exclude disks" könnte man dem nun entgegenwirken, aber so ein Gebastel würde ich sein lassen. Lieber weiter sauber die Dateien dort erstellen lassen, wo sie hin sollen und die Ordner von den anderen Disks runterwerfen.

 

Interessanter Ansatz.

Ich schliesse zwar aus den Cache benutzt zu haben (ist fuer alle manuell erstellten Shares noch immer deaktiviert, da ich immer noch beim Befüllen der Shares bin und den SSD-Cache nicht unnötig verschleißen will), weshalb ich auch davon ausgehe, daß der Mover nicht dazwischen gefunkt hat. Doch ich kann es nicht mehr nachvollziehen, weil das Problem ja nun mit Loeschung des klemmen gebliebenen Verzeichnisses behoben ist.

 

Du hast Dir sehr viel Muehe egeben und ich danke Dir!

[mgutt]

Just now, DataCollector said:

Ich schliesse zwar aus den Cache benutzt zu haben

Das ist im Ergebnis auch irrelevant. Sobald der Mover arbeitet, gelten die selben Regeln als hätte man keinen Cache. Also hätte ich jetzt den Cache deaktiviert, hätte er über SMB ebenfalls auf die falsche Disk geschrieben.

 

Wenn du dir nicht erklären kannst warum der Share-Ordner und der Unterordner auf disk11 erstellt wurde, dann weiß ich tatsächlich auch nicht was da passiert sein kann. Ich mein warum gerade disk11 und nicht zB disk8, wenn es ein "Schluckauf" war. Du sagst ja selbst, dass auf den anderen Disks noch etwas Platz war. Lässt sich jetzt natürlich nicht aufklären. Außer du kopierst noch mal und ziehst den Stecker von disk6 ^^