Hallo,

 

ich muss in meinem Array eine Platte austauschen und habe auch schon ein RMA angemeldet. Parity ist zwar vorhanden, aber ich möchte die vorhandenen Daten (ein Share mit Filmen) auf eine andere disk verschieben. Gibt es dazu ein Plugin oder mache ich das Problemlos über die shell? mittels mv?

 

 

 

Edited January 11, 20224 yr by blinddark
Als gelöst markiert

Ich habe aus dem Nerdpack den Midnight Commander mc. Dann logge ich mich via ssh ein starte den MC und verschiebe die Daten einfach.

23 minutes ago, MPC561 said:

Ich habe aus dem Nerdpack den Midnight Commander mc

 

MC ist standardmäßig installiert. Das Nerd Plugin ist keine Notwendigkeit für den Midnight Commander.

 

37 minutes ago, blinddark said:

Gibt es dazu ein Plugin oder mache ich das Problemlos über die shell? mittels mv?

 

Wenn Du mit mv oder mc vertraut bist, ok. Ich verwende ausschließlich den mc (Midnight Commander). Wichtig ist nur, dass Du nicht Disk-Shares (/mnt/diskx) und User-Shares (/mnt/user/x) mixt. Kopieren von diskx nach disky ist die beste Variante.

 

Nicht verschweigen will ich das Unbalance Plugin. Das kann das auch. Ich habe es aber noch nie genutzt.

 

Nachtrag: Bei längeren Kopier- oder Verschiebe-Operationen muss bei Verwendung der Shell die Session offen bleiben. Ich nutze dazu screen.

 

 

Edited January 9, 20224 yr by hawihoney

Aber aufpassen das man auch wirklich von /mnt/diskX auf /mnt/DiskY verschiebt und nicht mit /mnt/User rumhantiert.

Alternativ wäre "unbalance" als App genau für diesen Zweck gedacht

 

Edit: da war @hawihoney schneller

Edited January 9, 20224 yr by jj1987

Verschieben würde ich auf jeden Fall von Diskx zu Disky. Vielen Dank für die Antworten.

1 hour ago, blinddark said:

Gibt es dazu ein Plugin oder mache ich das Problemlos über die shell? mittels mv?

Unbalance kann das, schöne GUI und perfektes Plugin.

Mit Unbalance hat es perfekt funktioniert.

Als bei mir hat unbalance nicht funktioniert. Ich habe alles verschoben. Die Quelldisk war dann aber noch voll, sprich er hat nichts gelöscht. Und dann habe ich den Prozess noch mal gestartet und er kopierte dann die Daten natürlich auf eine andere Disk.

 

Jetzt habe ich auf mehrere Disks die gleichen Daten. Die Frage ist nun, wie ich die Dubletten bereinigen kann?

39 minutes ago, Cannon said:

Als bei mir hat unbalance nicht funktioniert. Ich habe alles verschoben. Die Quelldisk war dann aber noch voll, sprich er hat nichts gelöscht. Und dann habe ich den Prozess noch mal gestartet und er kopierte dann die Daten natürlich auf eine andere Disk.

warum auchimmer und anhand der Infos auch nichts nachvollziehbar ...

 

40 minutes ago, Cannon said:

Jetzt habe ich auf mehrere Disks die gleichen Daten. Die Frage ist nun, wie ich die Dubletten bereinigen kann?

löschen ... ?

 

zum Auffinden, Beispiel

 

11 hours ago, alturismo said:

löschen ... ?

 

 

Ja aber es schwingt schon die Angst mit, dass man was falsches löscht. Die Frage ist ja, warum UnRaid das nicht irgendwie selbst konsolidieren kann? Denn wenn ich im gleichen Ordner nur auf einer anderen Disk die gleiche Datei habe, dann müssten doch spätestens an der Stelle irgendwas nicht konsistent sein oder ich hätte im user-Share die Datei 2x drin. Mir leuchtet nicht so richtig ein, warum Unraid das eigentlich gar nicht merkt und welche Datei er auf einer Disk er überhaupt dem Share zuordnet.

Just now, Cannon said:

Ja aber es schwingt schon die Angst mit, dass man was falsches löscht. Die Frage ist ja, warum UnRaid das nicht irgendwie selbst konsolidieren kann?

 

Weil unraid selber solche Fehler eigentlich nicht macht.

 

 

Auch stellt sich die Frage, was unraid da denn hätte selber machen sollen.

a) 2 Dateien mit gleichem Namen in selber Vrzeichnisstruktur nur auf unterschiedlichen Disks? 

Soll er einfach dann eine von beiden Löschen? Das wäre Riskant, wenn gerade ein mover oder Verschiebeprozeß läuft, welcher ja eigentlich nur ein kopieren und anschließendes Löschen ist.

 

b) 2 Dateien mit gleichem Namen in selber Verzeichnisstruktur nur auf unterschiedlichen Disks mit gleichem Inhalt?

Somit müßte unraid also ständig die Namen und den Inhalt aller Dateien lesen und vergleichen? Wann soll das Array dann schlafen und wievbiel CPU Power (=Strom) frißt das 24/7?

 

Just now, Cannon said:

Denn wenn ich im gleichen Ordner nur auf einer anderen Disk die gleiche Datei habe, dann müssten doch spätestens an der Stelle irgendwas nicht konsistent sein

 

unraid macht es sich da einfach: es zeigt einfach eine Datei an und schaut gar nicht, ob irgendwo noch eine ist.

Als ich mal beim Umsortieren auf den Disks sowas verursacht hatte habe ich diese Verhalten bemerkt.

 

8 hours ago, DataCollector said:

a) 2 Dateien mit gleichem Namen in selber Vrzeichnisstruktur nur auf unterschiedlichen Disks? 

Soll er einfach dann eine von beiden Löschen? Das wäre Riskant, wenn gerade ein mover oder Verschiebeprozeß läuft, welcher ja eigentlich nur ein kopieren und anschließendes Löschen ist.

 

Naja man müsste überlegen, wie sowas passieren kann. Evtl. durch eine fehlerhafte Mover-Aktion, dass eine Datei gar nicht gelöscht wurde. Der Mover schiebt ja auch nur zwischen Pool und Array und nicht innerhalb der Arrays. Deshalb sollte da gar kein Risiko sein.

 

8 hours ago, DataCollector said:

b) 2 Dateien mit gleichem Namen in selber Verzeichnisstruktur nur auf unterschiedlichen Disks mit gleichem Inhalt?

Somit müßte unraid also ständig die Namen und den Inhalt aller Dateien lesen und vergleichen? Wann soll das Array dann schlafen und wievbiel CPU Power (=Strom) frißt das 24/7?

Das sollte nicht wirklich notwendig sein. Der Inhalt sollte ja immer gleich sein, wenn ich nur über das user-Verzeichnis kopiere. Außer wie gesagt der Umstand, dass das System abstürzt. Aber auch das ließe sich ja in einer "Datenbank" nachvollziehen, welche Datei die richtige ist. Aber hashen halte ich persönlich für unnötig.

 

Was aber evtl. Sinn macht ist wirklich eine Bereinigung der Daten (siehe Punkt a). Also im Scheduler eingestellt, wann das geprüft werden soll. Ich stelle mir das so vor, dass alle Shares auf Diskebene einmal geprüft und auf den Dateinamen verglichen werden. Gibt es doppelte Dateien, werden die entweder sofort gelöscht, man wird gewarnt oder die werden in einen temporären Unterordner mit selbiger Struktur verschoben. Also z.B. /mnt/user/cleanup/meinefreigabe/unterordner1/Datei1.

38 minutes ago, Cannon said:

Naja man müsste überlegen, wie sowas passieren kann. Evtl. durch eine fehlerhafte Mover-Aktion, dass eine Datei gar nicht gelöscht wurde. Der Mover schiebt ja auch nur zwischen Pool und Array und nicht innerhalb der Arrays. Deshalb sollte da gar kein Risiko sein.

 

Es ist keine fehlerhafte Moveraktion, wenn der Mover eben mitten dabei ist eine Datei zu verschieben (die ja auch gerne mal einige dutzende oder gar hunderte GB groß sein kann) und dann urnaid merkt, daß da eben 2 namensgleiche Dateien in der selben Verzeichnisstruktur eines shares sind.

Und dem Share ist es egal ob eine Datei im Pool oder im Array ist, weil dahinter eigentlich alles nur Datenträger sind, die per Fuse eben zusammengefasst werden.

 

38 minutes ago, Cannon said:

Das sollte nicht wirklich notwendig sein. Der Inhalt sollte ja immer gleich sein, wenn ich nur über das user-Verzeichnis kopiere.

Genau das ist ja nicht unbedingt der Fall.

Gerade, wenn 2 gleichnamige Dateien auf unterschiedlichen Datenträgern liegen und man beispielsweise per share darauf zugreift, wird einem eben eine angeboten. wenn jemand/programm die nun editiert und speichert hat man 2 unterschiedliche Stände innerhalb des share.

 

Du betrachtest nur den Moment Deines eigenen kopierens.

Aber unraid ist ein Netzwerksystem auch mit direktem Zugriff für mehrere User/Programme.

Eine gleichnamige Datei, kann beispielsweise durch User Error, Programm Error oder vielleicht sogar mehrer User, die gleichzeitig vielleuicht auf Diskshares zugreifen und blöderweise ihrer Datei gerade den gleichen Namen geben entstehen.

Stell Dir vor User1 hat Zugriff auf den Disk share von Disk1 und legt dort in einem Verzeichnis "Für das Team" den Kantinenplan der 1.KW 2025 ab. Name Futter.pdf

Stell Dir vor User2 hat Zugriff auf den Disk share von Disk2 und legt dort in einem Verzeichnis "Für das Team" den Kantinenplan der 2.KW 2025 ab. Name Futter.pdf

Nun greift ein User auf das normale SMB share "Für das Team" zu, welches eben per Fuse plattenübergreifend alles sieht.

Und nun?

 

unraid müsste permanent jede Platte und jedes Verzeichnis in Pool, wie auch Array im Blick haben um da schon beim Schreiben alles zu sehen und ggf. zu verweigern/meckern.

Da unraid aber dem fernzugreifenden SMB User direkt keine Nachricht schicken kann "Hallo, Du baust da gerade Mist" würden nur standartisierte Aktionen möglich sein "Write Error".

Und dann würden die User dem zuständigen Admin die Bude einrennen "Blödes System", "ständig bekomme ich Write Error", "kannste nicht mal was richtiges anschaffen"....

 

38 minutes ago, Cannon said:

Was aber evtl. Sinn macht ist wirklich eine Bereinigung der Daten (siehe Punkt a). Also im Scheduler eingestellt, wann das geprüft werden soll. Ich stelle mir das so vor, dass alle Shares auf Diskebene einmal geprüft und auf den Dateinamen verglichen werden.

 

Ich hatte vor 2 Tagen den Mover abgeworfen, der dann rund 11 Stunden am Stück gearbeitet hat (er hatte einige TB zu moven; dabei auch 300GB große Dateien).

Dann grätscht auf einmal der Scheduler rein und löscht alles, was der Mover gerade namensgleich kopiert um es im Anschluß an Quelle zu klöschen.

Und futsch ist das 300GB Image.

 

38 minutes ago, Cannon said:

man wird gewarnt

 

Wie soll unraid die User warnen?

Gibt es eine Meldung "Hey, ich habe hier ein Doppel gefunden" welches beispielsweise per SMB/NFS Protokoll den User (oder seinen PC) nachts aufweckt und informiert?

Es ist ja so, daß der Scheduler sinnvollerweise etwas startet, wenn das System gerade nicht unter Last steht.

 

38 minutes ago, Cannon said:

oder die werden in einen temporären Unterordner mit selbiger Struktur verschoben. Also z.B. /mnt/user/cleanup/meinefreigabe/unterordner1/Datei1.

 

Wie es mit leeren Unterordnern ist, weiß ich nicht, aber soweit ich es beobachtet habe werden Dateien (in Unterordnern) nie wirklich in einem Schritt verschoben. Sie werden erst kopiert und wenn sie angekommen sind, werden sie an Quelle gelöscht.

Aber hier ist dann schon das nächste Problem: Wenn der mc beispielsweise ein paar Verzeichnisse "verschiebt", wird erst der gesamte Inhalt des Unterordners kopiert (das können sehr viele Dateien/große Mengen sein) und erst, wenn der ganze Ordner abgearbeitet ist, wird er an der Quelle gelöscht.

Wenn hier so eine Aufräumaktion reingrätscht hat man aber mal ganz tief ins Klo gegriffen.

 

Da unraid sehr universell ist und eben auch mehr als nur einen User bedient, kann das eigenständige Löschen durch unraid ein Problem werden.

Das müßte leider eher umständlich und jede Situation bedenkend implementiert werden.

 

Das sehe ich nicht, weil unraid eben viel zu flexibel ist und dabei dennoch stromsparend sein sollte.

 

On 1/12/2025 at 10:32 AM, DataCollector said:

Es ist keine fehlerhafte Moveraktion, wenn der Mover eben mitten dabei ist eine Datei zu verschieben

Gemeint war mit fehlerhafter Mover-Aktion, dass die nicht beendet wurde, weil er möglicherweise die Datei nach dem schieben nicht löschen konnte. Es ist ja nur fiktiv. Ob das wirklich auftreten kann, sei mal dahin gestellt.

 

On 1/12/2025 at 10:32 AM, DataCollector said:

Stell Dir vor User1 hat Zugriff auf den Disk share von Disk1 und legt dort in einem Verzeichnis "Für das Team" den Kantinenplan der 1.KW 2025 ab. Name Futter.pdf

Stell Dir vor User2 hat Zugriff auf den Disk share von Disk2 und legt dort in einem Verzeichnis "Für das Team" den Kantinenplan der 2.KW 2025 ab. Name Futter.pdf

Nun greift ein User auf das normale SMB share "Für das Team" zu, welches eben per Fuse plattenübergreifend alles sieht.

Und nun?

Das ein Fall, den ich nicht beachten würde und auch in der Realität gar nicht so umsetzen würde. Ich sehe da wenig Sinn drin mit User-Shares zu arbeiten und dann wieder auf Disk-Ebene zu arbeiten. Das widerspricht, zumindest für mich, dem ganzen System als solches. Ich verstehe zwar das Problem mit den Rechten, weil UnRaid keine Möglichkeit bietet Shares in bereits vorhandene Shares anzulegen, aber so richtig toll ist das nicht auf Diskebene zu arbeiten, wenn man die User-Shares nutzt.

 

On 1/12/2025 at 10:32 AM, DataCollector said:

Ich hatte vor 2 Tagen den Mover abgeworfen, der dann rund 11 Stunden am Stück gearbeitet hat (er hatte einige TB zu moven; dabei auch 300GB große Dateien).

Dann grätscht auf einmal der Scheduler rein und löscht alles, was der Mover gerade namensgleich kopiert um es im Anschluß an Quelle zu klöschen.

Und futsch ist das 300GB Image.

 

Kann ich nicht nachvollziehen. Der Mover schiebt doch nur von Pool<->Array und nicht von Array<->Array. Dann sollte es auch keine Dubletten auf dem Array geben.

 

On 1/12/2025 at 10:32 AM, DataCollector said:

Wie soll unraid die User warnen?

In den Notifications von UnRaid. Nicht der User, sondern der Admin/root sollen informiert werden.

3 hours ago, Cannon said:

Gemeint war mit fehlerhafter Mover-Aktion, dass die nicht beendet wurde, weil er möglicherweise die Datei nach dem schieben nicht löschen konnte. Es ist ja nur fiktiv. Ob das wirklich auftreten kann, sei mal dahin gestellt.

 

Wenn unraid automatisiert doppelte Dateien löschen würde würde das Problem auftreten, sofern eben große Dateien kopiert werden, die nicht zwischenzeitlich komplett im Ramcahe gelagert werden können, da der Kopiervorgang einer solchen Aktion eben längern dauern kann.

 

3 hours ago, Cannon said:

Das ein Fall, den ich nicht beachten würde und auch in der Realität gar nicht so umsetzen würde.

 

Tja unraid ist aber leider erheblich flexibler als nur das, was ich oder Du umsetzen würden.

 

3 hours ago, Cannon said:

Ich sehe da wenig Sinn drin mit User-Shares zu arbeiten und dann wieder auf Disk-Ebene zu arbeiten.

 

Für ein und dieselbe Person/Nutzer: stimmt.

Aber wenn man unraid nicht nur im kleinen privathaushalt einsetzt sind weitergehnde Szenarien möglich.

Und wie man an Deinem Fall sehen konnte reicht es ja sogar, wenn jemand alleine arbeitet, daß auf einmal doppelte Dateien im System auftreten können.

 

3 hours ago, Cannon said:

Kann ich nicht nachvollziehen. Der Mover schiebt doch nur von Pool<->Array und nicht von Array<->Array. Dann sollte es auch keine Dubletten auf dem Array geben.

 

Für Fuse ist alles ein und dasselbe. Unraid fasst per fuse Array und Pool zusammen. Dadurch sind dann eben in der Zeit des Kopierens für unraid Dateien doppelt vorhanden.

 

3 hours ago, Cannon said:

In den Notifications von UnRaid. Nicht der User, sondern der Admin/root sollen informiert werden.

 

Aber was passiert dann zwischenzeitlich während der User gerade arbeitet udn das System diese Arbeit wegen doppeltem Namen ablehnt?

Soll User dann 5 Stunden warten. bis Admin in seiner Arbeitszeit aktiv werden kann?

 

 

35 minutes ago, DataCollector said:

Für Fuse ist alles ein und dasselbe. Unraid fasst per fuse Array und Pool zusammen. Dadurch sind dann eben in der Zeit des Kopierens für unraid Dateien doppelt vorhanden.

Aber das kann doch Unraid durchaus unterscheiden. Im WebInterface sehe ich das Array und den Pool. Das Array besteht aus einzelnen Disks. Wenn alle Unterordner der einzelnen Disks verglichen würden, dann habe ich doch das Problem gar nicht. Beispiel:

 

Ich habe ein Share namens Daten. Das Share liegt auf Disk1 und Disk2. Jetzt ist es doch easy zu prüfen, ob unter mnt/disk1/Daten und mnt/Disk2/Daten Dubletten liegen. Der Pool hat doch damit nichts zu tun. Wie gesagt aber nur unter der Voraussetzung, dass ich das Share Daten verwende und nicht direkt auf mnt/disk1/Daten und /mnt/disk2/Daten schreibe.

 

Selbst, wenn ich die Dubletten nun nicht lösche, habe ich da aus meiner Sicht irgendwie eine Inkonsistenz. Denn wenn 2 Dateien mit gleichem Namen aber unterschiedlichen Inhalts im Share liegen, zeigt mir Unraid nur eine der Dateien im Share Daten an. In diesem Fall stellt sich wiederum durchaus die Frage, warum er die Datei dann eben auch nicht 2x anzeigt, wenn das Ganze durchaus erlaubt werden soll.

 

Mein Ansatz geht eigentlich nicht mehr darum die Dateien einfach zu löschen, sondern klar zu entscheiden: Möchte ich Dubletten durchgehend erlauben oder nicht. Und wenn ja, dann sollten doppelte Dateien auch im Share angezeigt werden.

 

45 minutes ago, DataCollector said:

wie man an Deinem Fall sehen konnte reicht es ja sogar, wenn jemand alleine arbeitet, daß auf einmal doppelte Dateien im System auftreten können.

Ja durch einen Fehlerfall ... leider. Was auch erst zu diesem Thema führte.

 

46 minutes ago, DataCollector said:

Aber was passiert dann zwischenzeitlich während der User gerade arbeitet udn das System diese Arbeit wegen doppeltem Namen ablehnt?

Soll User dann 5 Stunden warten. bis Admin in seiner Arbeitszeit aktiv werden kann?

Warum sollte das System das ablehnen? Das war nie mein Ansatz. Der Ansatz ist, entweder:

• Variante 1: per Notification/Log warnen, dass Dubletten gefunden wurden
• Variante 2: doppelte Dateien in einen Unterordner schieben + Notification/Log
• Variante 3: doppelte Dateien gnadenlos löschen + Notification/Log

4 minutes ago, Cannon said:

Der Ansatz ist, entweder:

oder ...

 

- Variante 4: nicht am System vorbei arbeiten, dann passiert das nicht oder nicht Dinge machen wo das produzieren können ...

 

jetzt mal ernsthaft, wenn das ein ernstes Thema wäre ... wie oft würdest du das hier sehen ... da ist was schief gelaufen, war, weßhalb, wieso, ... auch immer, aber bei normaler Nutzung passiert das nicht ... und du hast bereits die Lösung gehört, lösch deine Dubletten und fertig bist du ...

On 1/11/2025 at 1:59 PM, alturismo said:

 

Auch wenn das Problem gelöst ist möchte ich noch folgendes Deduplizierungs-Tool empfehlen. Läuft bei mir wesentlich performanter als "dupeGuru", welches ich selbst lange verwendet habe.

Gibt es für Windows und eben auch als Docker-Container
GitHub - jlesage/docker-czkawka: Docker container for Czkawka

ich fand das mit dem Verschieben ungünstig.

Man sollte hier lieber kopieren und dann die Quelle löschen...

Verschieben macht ja nur auf einem Datenträger Sinn und das Risiko bei Fehlschlägen während des Verschiebens von disk 1 zu 2 ist schon nicht unerheblich, erst recht wenn eine Platte schon zickt...

2 minutes ago, cottec said:

Verschieben macht ja nur auf einem Datenträger Sinn und das Risiko bei Fehlschlägen während des Verschiebens von disk 1 zu 2 ist schon nicht unerheblich, erst recht wenn eine Platte schon zickt...

Aber es wird doch erst dann gelöscht, wenn es erfolgreich verschoben ist.

 

Ich finde das sogar besser mit dem sofortigen Verschieben. Denn, wenn was kaputt ist, bleiben nur noch die Dateien übrig, die Probleme machen und ich muss nicht erst suchen. Der Abgleich macht sich damit deutlich leichter.

Bin ein gebranntes Windows Kind, da finde ich das teilweise richtig schlecht und unkontrollierbar

1 minute ago, cottec said:

gebranntes Windows Kind

Auch in Windows ist "Verschieben" in die beiden Schritte "Kopieren" & "Löschen" aufgeteilt.

Wobei auch hier erst gelöscht wird, wenn erfolgreich kopiert wurde.

Und was ist mit dem Fall, dass ne Festplatte mitten beim Kopieren abschmiert? Also wirklich mittendrin, weil irgendwas in der Platte beim Schreiben versagt

Dann ist das bereits Verschobene weg.

Andernfalls hat man noch die Quelldaten

2 minutes ago, cottec said:

Und was ist mit dem Fall, dass ne Festplatte mitten beim Kopieren abschmiert? Also wirklich mittendrin, weil irgendwas in der Platte beim Schreiben versagt

Dann ist das bereits Verschobene weg

Wenn du auf eine kaputte Platte rauf kopierst (mit verschieben), dann ist das natürlich nicht gerade optimal. Aber selbst wenn die Platte an der Stelle abschmiert, dann wird ja die Datei auf der Quellplatte auch nicht gelöscht.

 

Und wenn deine Zielplatte abschmiert, wenn du die Quellplatte gerade gelöscht hast, dann hast du die Quelldaten auch nicht mehr.  

Für eine Datei passt das, aber bei einem Ordner mit vielen Dateien ist es problematisch, wenn auf einmal die Hälfte fehlt.

 

Ich denke nur an den Ausfallzeitpunkt der Disk, vermutlich eher beim Schreiben als beim Nichts-Tun.
 

Ich würde auch vorher ein Backup machen (falls die Daten noch geändert wurden seit dem letzten Backup) und wenn alles glatt gegangen ist, noch eins hinterherschieben.