[OMV] Datenkopie - mir fehlt 1,3TB

Die Frage ist sicherlich an alle gerichtet. Ich weiß es nicht. Eine Idee kam mir durch den Kopf - normalerweise wirst du mit den Dateien nicht so viel rumspielen (wie du davon machen etc.). Dabei werden sich access-Time Zeitstempel ändern, vielleicht mehr in der internen Struktur des FS. Von rsync erwarte ich, dass es nicht nur Größe, sondern auch Zeitstempel berücksichtigt. Wenn ein Byte in einem GB geändert wird, muss das ja trotzdem konsistent sein. Allerdings würde ich jetzt bei den hier diskutierten Befehlen immer nur Read/Access Stempel geändert erwarten - und da würde ich erwarten, dass rsync das versteht.

Sind die Shares noch freigegeben? Ich würde jetzt (in privatem Umfeld, wo ich praktisch alleine werkle) für die ganzen Aktionen die ganzen Sharing-Services in OMV abschalten. Sonst kann daher auch noch "Rauschen" kommen.

Hatte mal vor hmm.. 15..20 Jahren echte matschprobleme beim kopieren. So von meinen Vorurteilen her wuerde ich sagen WD HDD - wo in grosssen Mediendateien dann irgendwelche Blocke nicht richtig kopiert wurden. Weiss gar nicht mehr genau, ob das selbst beim Abspielen so richtig aufgefallen ist. Aber fiel halt auf, weil ich von allen Dateien eine md5sum hatte. Kann seinerzeit auch gut Problem mit Stromversorgung ueber USB beim kopieren gewesen sein.

Inzwischen soll ja angeblich die fehlerrate bei HDD bei 10^15..15 sein, also ein bit falsch pro 12.5 TByte oder weniger. Wer's glaubt. Das bezieht ja eben solche elektrischen Probleme nicht mit ein.

Wenn man ISOs als filesystemstruktur rumliegen laesst, dann hat man natuerlich nervig viele dateien auf der Platte. Deswegen mag ich ja ISO als einzelne datei. Kann man bei Bedarf ja immer noch mounten. Kodi kann da ja auch reinsehen.

So'n md5sum fuer alle dateien zu machen ist auf jeden Fall sinnvoll, wenn mans nicht im FS hat (ZFS oder so). Ich finds ja als separate Datei eigentlich besser. Wobei man leider wohl einen script schreiben sollte, weil man eigentlich den dateinamen, die md5sum UND das change-date haben will um spaeter mal zu vergleichen. Und wenn man wirklich mal Unterschiede hat, weiss welche kopie aelter und damit hoffentlich besser ist...

Komisch. Stimmt natürlich schon, dass 1 TiB nicht durch Verzeichnis-Einträge erklärbar sind.

Die Summe der du -sk Ergebnisse aus #5 macht für mergefs 5,543115932 TiB und für 12 TiB HDD 5,543616228 TiB. Das passt eigentlich für die 12 TiB Disk zu dem ersten df aus #1 und bei mir ist das ähnlich. Daher zweifle ich an

Zitat von noob_at_pc

Hm aber seltsam, die Datei lag also vorher schon da aber scheinbar ohne Dateigröße

Das diff hätte es gezeigt, weil ohne Dateigröße verbraucht kann auch nix dahinter liegen ... Geht bei mir übrigens aus dem Gedächtnis schon mit gut 100 MB/s bei großen Dateien (die auch gleich binär erkannt werden).

Normalerweise würde ich natürlich die Services auch nicht disablen - aber wenn es spooky wird, würde ich vermutlich machen (Zeit und Muse vorausgesetzt). Du hast nach der Diskussion schon getestet, dass nicht oben ein .Verzeichnis ist?

Ich teste nochmals bei mir mit meinem Tool (von dem ich exakt weiß, welche verschiedenen Größen es anzeigt - was auf Disk benötigt wird, wie groß die Datei ist, ...) und vergleiche mit du-Ausgabe und df-Ausgabe und ls -l Ausgabe, wie da welcher Wert exakt zu stande kommt (bei mir). Grade mit Größe der Metadaten bei sehr vielen Verzeichnissen/Dateien kann es schon Überraschungen geben. Aber wie gesagt, bei mir sind du und df Daten ganz nah beieinander, und das war bei dir auch der Fall mit den Zahlen aus #1 und #5, wenn du jetzt 1 TiB mehr brauchst und auf mergerfs auch, dann ist das das komische. (Oder du hast doch oben ein .Verzeichnis). Kannst übrigens auch du -sk eine Ebene höher machen, natürlich. Das geht ja sehr schnell. Müssten die 5,54 TiB rauskommen, plus das was auf oberster Ebene nicht in Unterverzeichnissen liegt. (Klar, die df kiB in TiB umrechnen durch /(1024*1024*1024)
EDIT: deinen Beitrag mit rsync Fehler hatte ich nicht gesehen, als ich das schrieb (den rsync Fehler nun schon, denke ich. Ich notier mir die Befehle immer, wenn ich es ein Mal sorgfältig getestet hab, wo man aufpassen muss mit letztem Pfadbestandteil in Quelle und Ziel und auch dem Slash). Meine Ausführung zur Größe sollte dennoch stimmen und sinnvoll sein.

Hast Du Dich gruendlich gewaschen nachdem Du das letzte Mal Windows angefasst hast ? Da koennte das Linux sonst alergisch reagieren

Diese Ausgaben hier:

< 113504 ./300/300a.avi

> 649264 ./300/300a.avi

Sind jetzt aber nicht von dem printf, sondern von dem von mir vorgeschlagenen 'du' ?? Das Printf wuerde ja in der Zeile erst den Pfadnamen und dann die Groesse drucken...

Du hast nicht gesagt, welches der beiden das Original ist...

Ich wuerde erst mal ein "cmp" machen um die beiden zu vergleichen. Wenn die unterschiedlich sind, dann guckset Dir nochmal genau Dein Kopierprogramm an.

Aber dadurch, das das eine per "ls -l" viel groesser ist als bei "du" hat das auf jeden Fall loecher. Wenn dieses lochfile das vom mergerfs ist musste erstmal ein "du -s -k" auf das Original unterhalb des mergerfs machen. Und hoffen, das es keine Loecher hat. Ansonsten isses ja wohl kaputt. Mediendateien habe nicht soviel loecher/null-bloecke.

Wenn dem so ist - also die mergerfs variante hat loecher, das original dadrunter nicht... Naja, dann haste einen grund, warum man nicht mergerfs nehmen will

Kleinere Unterschiede im "du" wie bei den anderen dateien koennen immer von filesystemdetails kommen. Da ist dann das printf == groesse vom "ls -l" besser. Das du ist nur gut um so grosse probleme festzustellen.

hehe, solange das mergerfs wirklich fehlerfrei ist...

Aber wenn die 300a.avi wirklich so viel kleiner ist, dann ist da noch ein Problem...

Kapier ich nicht!

664842240 / 1024 = 649260 KByte. Also ziemlich genau was bei einer Kopie angezeigt wurde im Diff. Prima.

Aber: Jetzt erklaer mir mal, wie die andere Kopie derselben Datei nur 113504 KByte gross ist im du, obwohl sie im ls -l als 664842240 gross angegeben ist - und trotzdem soll die Deiner Meinung nach nicht kaputt sein.

Wie gross ist denn nu 300a.avi in "ls -l" und in "du -s -k" ???

Ja ok. Aber Deine Erkaerungen bisher erklaeen fuer mich nicht, warum die eine Kopie von 300a.avi am Anfang so viel kleiner war 113504 KByte.

Aeh... dann ist mergerfs schrott, wenn man duplicates da drin hat ??