Inhalt vieler Verzeichnisse in ein Verzeichnis verschieben

Hinweis: In dem Thema Inhalt vieler Verzeichnisse in ein Verzeichnis verschieben gibt es 40 Antworten auf 5 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Ach, Wurzel!!

    Ach Berichtigung .. was spricht dagegen, die einfache Lösung (zunächst an Testdaten .. zur Sicherheit gegen Tipselfehler wg. Datenverlust) zu testen. Wenn es denn tut ist gut .. wenn nicht dann darf man/du gerne an einem komplexen Ansatz arbeiten.


    Die einfache Lösung hat noch einen riesigen Vorteil. Die versteht fast jeder Anfänger und kann sich daran fortentwickeln. Vom einfachen zum komplexen ...


    Wozu der Trecker mit 16scharigem Pflug wenn die Gartenhacke evtl ausreicht? Den Lohnunternehmer kann ich im Bedarfsfall immer noch ordern.

    There's no place like 127.0.0.1

    Für den Inhalt des Beitrages 103334 haftet ausdrücklich der jeweilige Autor: wurzel99

  • Ich lese schon ne Weile mit. Jedoch haben @wurzel99 und @Kuddenberg wohl noch nicht verstanden, was hier für Informationen gefordert werden, um das Problem zu lösen. Beide sollten deshalb noch einmal den Post 13 aufmerksam lesen und verstehen. Notfalls auch mehrmals.

  • @Wurzel Also deine Lösung ist einfach genial.
    Sauber, schnell und ohne bezahlte Hilfbüttel.


    Kriegst hiermit den großen Move- Orden auf laufenden Bande!
    Jetzt wieder alles gut?


    Es spricht dagegen, dass das eigentliche Problem damit noch nicht einmal adressiert ist, geschweige denn gelöst,
    was uns diese Antwort denken lassen könnte:

    ...
    Übrigens ergibt sich bei der Nutzung von mv mit der kleinen Befehlszeile von mir das gleiche Bild. es dauert allerdings länger, bis die Information "Speicher voll" kommt.
    ...

  • Es spricht dagegen, dass das eigentliche Problem damit noch nicht einmal adressiert ist, geschweige denn gelöst,
    was uns diese Antwort denken lassen könnte:

    Es ist durchaus wahrscheinlich u. zumindest erprobenswerte ob dieses Problem bei meinem Lösungsvorschlag überhaupt auftritt.


    Jedoch haben @wurzel99 und @Kuddenberg wohl noch nicht verstanden, was hier für Informationen gefordert werden, um das Problem zu lösen.

    ich für meinen Teil habe sehr genau gelesen und schlagen einen sehr einfachen Lösungsversuch vor.


    Warum ein Riesending drehen, wenn die Lösung ganz einfach sein könnte?

    There's no place like 127.0.0.1

    Für den Inhalt des Beitrages 103338 haftet ausdrücklich der jeweilige Autor: wurzel99

  • Mal zum Sortieren aus meiner Perspektive, also subjektiv und laienhaft(falls der TE nicht bereits ganz verschreckt ist)


    Die Platzverhältnisse sind nicht abschließend geklärt, aber wichtig.
    Das Dateisystem (die Dateisysteme) sind unbekannt, aber vielleicht wichtig.
    Es ist unbekannt, warum der TE den eingesetzten Befehl verwendet, obwohl es simplere Möglichkeiten gibt.



    Generell (Teil der Diskussion)
    Ich würde von einem Befehl wie bspw.

    Code
    mv, cp, ls, ..

    zunächsteinmal keine Limitierung erwarten. *
    Erfahrungswert: Bei sehr vielen Dateien tauchen Probleme auf, z.B. wenn eine (sehr) lange Dateiliste sortiert ausgegeben werden soll oder auch nach Pattern gefiltert. Wenn die Befehle also mit gewissen Parametern versehen sind. Details (Ursachen) hierzu sind mir nicht bekannt.
    Das könnte ein Problem beim TE sein.
    * Demnach besteht für mich bei Ihrer Anwendung auch zunächst keine Erfordernis von tieferen Kenntnissen des Filesystems (Ausnahme, ich müsste bei

    Code
    cp

    wissen, wieviel kopiert wird und wieviel Platz im Zielverzeichnis/-partition verfügbar ist)



    Der angefragte Befehl ist komplexer als

    Code
    mv, cp, ls

    allein

    Code
    xargs

    selbst ist limitiert. Ein limit von xargs kann bspw. mit

    Code
    getconf ARG_MAX

    abgefragt werden.
    Das könnte ein Problem beim TE sein.



    Das

    Code
    find

    leidet evtl. unter ähnlichen Problemen wie mv, cp, ls. Denn es filtert ebenfalls und baut die Ausgabe um.
    Das könnte ein Problem beim TE sein.



    kleine Gemeinheiten:
    Der Aufruf wie er vom TE gepostet wurde, bietet keinen Schutz davor, irrtümlich die Verzeichnisse unsauber anzugeben (Zielverzeichnis Untermenge des aktuellen Directories, also Teil der Move Menge) - die Aktion wird dadurch ggF. rekursiver als gewollt.
    Das Zielverzeichnis kann durch unbekannte Mount Situation viel kleiner sein, als angenommen, sprich eine andere Partition.
    Ggf. besteht ein user quota, das zuschlägt.



    außerdem unklar/offen, besonders vor dem Hintergrund im proffesionellen Bereich:
    was an diesem Verfahren das aufgeführte Backupproblem und die geforderte Traceability sichert.
    was an diesem Verfahren Nachvollziehbarkeit garantiert (Logging fehlt).
    was an diesem Verfahren Datenverlust (bei fehlender Eindeutigkeit der Dateinamen) garantiert.



    Summa summarum spricht das alles dafür, mit einem einfachen Ansatz zu testen, Logging und Sicherheit einzubauen und dann Richtung Skalierbarkeit zu gehen. Damit wäre man m.E. am Ende bei einem Script wie Berichtigung es fordert. Dabei darf man ruhig iterativ vorgehen, also Fragen schrittweise klären, so wie wurzel99 es vorschlägt.

    Für den Inhalt des Beitrages 103339 haftet ausdrücklich der jeweilige Autor: Tar Zahn

  • Nur als Beispiel:
    ca. 9 Millionen Dateien sollen kopiert werden, das sind dann schon mal ca. 18 Millionen.


    Dafür brauch ich dann auch z.B. 9 Millionen freien Inodes im Dateisystem.
    Oder die Frage ist auch, wie viele Dateien kann ich in einem Verzeichnis speichern.


    Hängt alles vom eingesetzten Dateisystem ab, ebenso, wie voll (nicht Speicherplatzmäßig) das Dateisystem schon ist...............

    Für den Inhalt des Beitrages 103340 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Genau was ich meinte und auch Berichtigung schon mehrfach ansprach. wurzel99 versucht stur eine Kopiererei loszutreten in der Hoffnung, das es schon gut gehen wird. Ging es aber nicht. Siehe oben.


    Edit:
    Warum nicht, falls technisch möglich, eine große HDD in das System einfügen, diese als Backup-Platte definieren und den ganzen Kram da drauf spulen? Wäre die einfachste Lösung. Ich nutze für wichtige Datensicherungen immer eine eigene HDD mit ausreichend Platz, die ich nur bei Bedarf einbinde. Damit kann ich sicherstellen das alle Sicherungen da drauf passen und ich die Platte nicht mal versehentlich "exekutiere".

  • Tar Zahn: Tja, und mit dem ersten Test werden ungewollt Dateien überschrieben.


    Das mag man als User gerne tun.
    Auf Produktivsystemen einfach mal schrittweise __irgendwie__ __irgendwas__ zu probieren,
    wäre bei mir fristlose Entlassung, weil Vorsatz.


    Das mag jetzt für den TE eh schon egal sein, da er ja bereits ein paar mal solche nicht durchdachten Versuche unternommen hat und es deshalb wahrscheinlich sowieso schon zu spät ist,
    so etwas aber hier zu raten, ist nicht OK.


    Man sollte dem Ratsuchenden da schon vorher drastisch klarmachen, was er für ein Risiko eingeht, damit er selbst entscheiden kann, ob er wagen will.
    Einfach zu erklären, dass das schon passen würde, ist fahrlässig.


    Es geht dem TE um Daten einer Firma,
    nicht um Versuchspartitionen eines Hobbylinuxers.


    Ich halte es auch für ziemlich leichtfertig, alleine wegen des einen Satzes in Post#12 "Die Vergabe der Dateinamen ist eindeutig." zu schlussfolgern, dass damit sicher wäre, dass keine Überschreibungen stattfinden können.
    Wurde denn von euch gefragt, welches Namensschema verwendet wird?
    Was, wenn das Namensschema für die gleichen Messvorgänge gleiche Namen nimmt und alle Werte mit Zeitstempel in diese Datei dann einträgt?
    Sicher, sicher, ganz eindeutig. Und in jedem Fall ein Datenverlust. Mit dem allerersten mv - Befehl.
    Und wer hat die Frage gestellt?


    Außerdem wird auch ein solch -Entschuldigung- hirnkrankes iteratives Vorgehen von Anfängern dieses Problem nicht lösen.
    DENN DAS HAT MIT DEM PROBLEM NICHTS ZU TUN!!!! ***ZEFIXXX***


    Es ist EBEN NICHT das Problem, dass der TE die Verschiebung nicht bewerkstelligen kann.
    Es wurde auch nicht gefragt, wie man das schnell bewerkstelligen kann.
    Das Problem ist, dass -obwohl genügend Festplattenplatz vorhanden ist, der Kernel -sei das nun copy oder move- mit einer Nicht-genügend-Speicher Meldung weiteres Schreiben unterlässt.


    Ist das wirklich sooo schwer einzusehen?



    Die wichtigen Fragen hier sind:

    • welches Dateisystem ist da im Einsatz?
    • wie ist die derzeitige exakte Belegung?
    • wie sieht es mit den noch verfügbaren Metainformationen des verwendeten Dateisystems aus?
      (Also z.B. nicht df /dev/halligalli sondern df -i /dev/halligalli )

    Und solange da keine verwertbare Info vorliegt, macht keine weitere Antwort Sinn.
    Ende Gelände.


    Die Verwendung von xargs ist zwar auch immer kritisch zu betrachten, und meines Erachtens nach hier auch nicht zwingend, da find sogar ein -execdir kennt,
    aber ganz sicher ist es nicht sooo buggy, dass man damit einen solchen Fehlerzustand erzeugen könnte.
    Einen solch üblen Bug hätte man längst gefunden und gepatched - wird doch xargs eher von Fortgeschrittenen verwendet.


    Das Problem ist längst klar.
    Unabhängig davon, ob ihr iterativ eine optimale move- Lösung finden wollt.
    (Die ich nach wie vor für nicht sinnvoll halte.)

  • wurzel99 versucht stur eine Kopiererei loszutreten in der Hoffnung, das es schon gut gehen wird.

    sag mal .. hast du meinen Befehlsvorschlag nicht gelesen oder nicht verstanden ?? Ich habe NICHTS von kopieren geschrieben .. es geht um MV!! Du mit deiner langjährigen Erfahrung solltest wissen, dass das was anderes ist. Und das Attribut 'stur' ist von einer Qualität, die man sich zunächst einmal verkneifen kann.


    Der TE hat die Situation so weit deutlich beschrieben, dass das mv hier nicht zum cp mutiert. Man kann immer noch weiter fragen.


    Was hat ihr alle Muffe vor einem einfachen Befehl? Eure Fragestellungen sind nicht die des TE? Er will seine Ordnerstruktur verflachen. Es gibt keine doubletten. Dafür ist mv Ideal.
    Das sich das ganze immerhalb eines einziges Dateisystems abspielt (damit mv nicht doch zu cp wird) sollte geklärt werden. Aber dann sind wir sowieso am Anfang.


    Ihr bastelt euch hier eigene Aufgabenstellungen (wer weiß wieso?) und verliert die Fragestellung völlig aus dem Auge.
    wie gesagt .. ihr könnte die tiefenpsychologischen Dateisystembetrachtungen immer noch rausholen, wenn die Niveacreme nicht geholfen hat.


    Summa summarum spricht das alles dafür, mit einem einfachen Ansatz zu testen, Logging und Sicherheit einzubauen und dann Richtung Skalierbarkeit zu gehen. Damit wäre man m.E. am Ende bei einem Script wie Berichtigung es fordert. Dabei darf man ruhig iterativ vorgehen, also Fragen schrittweise klären, so wie wurzel99 es vorschlägt.

    was ich damit sagen wollte ! Danke !

    There's no place like 127.0.0.1

    Für den Inhalt des Beitrages 103344 haftet ausdrücklich der jeweilige Autor: wurzel99

  • diese Information machen natürlich nach wie vor Sinn .. endlich mal irgendwo Einverständnis. Wobei dann immer noch ein mv dabei rauskommen kann ... 8)
    ------------------
    kann es sein dass wir uns nur noch mit uns selbst beschäftigen und der TE längst die Flucht ergriffen hat?
    Das ist wie beim Konsilium am Krankenbett (oder das intensive Lesen des Beipackzettels)... zu viele Ansichten ... :(:(:(

    There's no place like 127.0.0.1

    Für den Inhalt des Beitrages 103345 haftet ausdrücklich der jeweilige Autor: wurzel99