Seltsamer Effekt beim Verschieben. Hat jemand ne Erklärung?

[kalli82]

Hallo,

In meiner DS218+ laufen 2 WD Red 12TB mit Dateisystem Btrfs als SHR Raid.

Ich war heute etwas am "Umräumen" und habe einen neuen Share erstellt, in den 5+6 Unterordner aus einem bestehenden Share verschoben werden sollten (was auch grundsätzlich geklappt hat).

Wie ich richtig vermutet hatte, hätte es zu lange gedauert, wenn ich von meinem Win10-Rechner aus die Ordner in dem einen Share ausgeschnitten und dann in den anderen eingefügt hätte. Habe das trotzdem kurz angetestet, aber als er tatsächlich begonnen hat, die 100e GB zu kopieren, hab ich es direkt abgebrochen.
Stattdessen hab ich mich per SSH eingeloggt und die Ordner mit "mv Quellordner Zielordner" verschoben. Das ging natürlich super flott und (laut Konsolenausgabe) ohne jegliche Meldungen. War alles sofort im Zielshare sichtbar und zugreifbar.

Was ich mir nicht so recht erklären kann:
Nach dem Verschieben stellte ich fest, dass 2 der 5-6 Unterordner im Ursprungsshare weiter existierten, auch mit den enthaltenen Dateien. Die waren nicht bloß nur noch im Cache des Windows Explorer - ich habe mehrere Videos angespielt und durchgescrollt, das funktionierte. Auch über SSH zeigte mir ls die Ordner und files im Quellshare weiter an.
Trotzdem waren beide betreffenden Ordner (wie die restlichen auch) normal im Zielshare gelandet, mit denselben enthaltenen Dateien. Auch hier ließen sich die Videos abspielen.
Ich konnte einzelne Dateien in den betreffenden Ordnern des Quellshares auch löschen, ohne dass sie im Zielshare ebenfalls verschwanden (wäre ja noch schöner gewesen). Letztendlich habe ich die beiden Ordner im Quellshare komplett gelöscht. Der belegte und freie Speicher hat sich durch die Löschaktion nicht verändert (was ich auch nicht erwartet hätte. Das Verschieben von 100en GB hat <1 Sekunde gedauert, da wird im filesystem keine redundante Kopie erstellt).

Was ich mir nicht so recht erklären kann: Wie kann es sein, dass nach einem fehlerfreien Verschieben mittels mv dieselben Dateien zweimal existieren? Ich könnte mir das ansatzweise nur erklären wenn ich A) zwischen 2 verschiedenen Dateisystemen verschoben hätte und ein Abbruch auftgetreten wäre (ersteres hier nicht der Fall und hätte auch länger gedauert) oder B) beide Dateien - warum auch immer - per Hardlinks gekoppelt sind (die nutze ich selbst intensiv auf meiner Backupplatte). Aber laut ls -la war der Verwendungszähler bei jeweils beiden Dateien auf 1 - offenbar kein Hardlink.
Allerdings habe ich mit Btrfs noch nie gearbeitet, evtl. arbeitet das ja ganz anders als Ext2/3...

Zwar läuft nun wieder (bzw. weiter) alles rund. Aber hat jemand ne Idee, wodurch so ein Effekt zustande kommen kann?

 

[AndiHeitzer]

Was ich mir nicht so recht erklären kann: Wie kann es sein, dass nach einem fehlerfreien Verschieben mittels mv dieselben Dateien zweimal existieren?

Mein erster Gedanke war auch, dass sich WIN da etwas verheddert hat.
Aber Du hast ja explizit mit einem 'mv source destination' nachgeholfen.

Mit Linux kenn ich mich nicht wirklich tief aus, aber ich meine, dass es u.U. mit den Nodes im Filesystem zusammenhängen könnte?
Ich hoffe, dass einer nun antwortet, der sich mit den Tiefen des Filesystems mehr auskennt, als ich. Wäre auch nicht schwierig

 

[framp]

Diesen Effekt habe ich noch nicht gesehen. Hast Du vielleicht mehrere mv Anlaeufe gestartet? Siehe dazu What happens if mv is interrupted?

 

[kalli82]

Ja, ich auch nicht. Nein, ich habe mv für jeden dieser paar Ordner genau einmal ausgeführt und es lief jeweils ohne irgendwelche Fehlerausgaben durch. Sobald die nächste Eingabe akzeptiert wurde (was quasi sofort nach "Enter" war), habe ich den nächsten mv abgesetzt.
Am Ende der Aktion waren alle Ordner im Ziel angekommen, zwei lagen jedoch zusätzlich noch komplett im Quellshare.

 

[Fusion]

Wenn von dem Verschiebetest noch Dateien/Ordner am Ziel vorhanden gewesen wären hätte mv diese nicht überschrieben, aber normal auch einen Fehler gemeldet.
Da ist zudem was im Argen, weil da eigentlich mit SMBv3 server side copy funktionieren, wo nicht über den Client kopiert/verschoben wird.
Klappt selbst unter Linux. Ausnahme dürfte sein, wenn man zwischen Volumes verschiebt.

 

[synfor]

SMB ist hier doch gar nicht involviert. Würde da im konkreten Fall auch mit Server Side Copy Move zu Copy & Delete werden wie beim Verschieben zwischen Volumen.

 

[Fusion]

Bei mv nicht, aber

wenn ich von meinem Win10-Rechner aus die Ordner in dem einen Share ausgeschnitten und dann in den anderen eingefügt hätte. Habe das trotzdem kurz angetestet,

Und mit SHR und DS218+ gehe ich auch von einem Volume aus.
Aber ja, es fehlen die letzten Details um es endgültig zu beurteilen was greifen würde (bsp. mehrere Laufwerke in Windows eingebunden und dazwischen verschieben, oder via UNC-Pfade, und was weiß ich noch).

 

[kalli82]

Ja, ganz normal ein Volume. Der eine Share ist mein home share unter /var/services/homes/Username. Der andere Share war über die Gui erstellt und von der Syno unter /volume1/sharename angelegt worden.
Wieso liegen die Standard-Shares der Syno (also auch music, photo, video...) nicht ebenfalls unter /volume1/? kann das damit zusammenhängen?

Der Effekt über SMB ist übrigens reproduzierbar. Wenn ich Dateien verschiebe zwischen beiden Shares, werden sie inhaltlich kopiert und die Quelldatei nach Abschluss gelöscht. Egal, ob ich die Shares über \\IP\sharename öffne oder ihnen vorher je einen Laufwerksbuchstaben zuordne.


Aber wir rätseln hier gerade nur über das Verschieben über SMB. Bzgl. des Effekts mit mv dürfte uns das vermutlich auch nicht weiterbringen...

 

[synfor]

Ob bei diesem abgebrochenem Vorgang Server Side Copy benutzt wurde oder hätte benutzt werden können, spielt doch für mv keine Rolle. Da ist nur wichtig, ob deswegen bereits Dateien oder Ordner im Ziel existieren. Was allerdings wie bereits angeführt, zu entsprechenden Meldungen hätte führen müssen.

 

[kalli82]

Nein, der Zielordner war komplett leer. Anschließend lagen dann die 5 reingeschobenen Verzeichnisse drin.
Den Fall, dass darin einzelne Dateien oder Ordner bereits existierten, können wir ausschließen (bzw. wie Du korrekt sagst, wäre dann ja auch ein Hinweis gekommen)

 

[Fusion]

Ja, ist halt nicht alles eine Insel und kann miteinander zusammen hängen.
Mit mv selbst habe ich das so noch nie gesehen, besonders wenn er ohne Fehlermeldung durchläuft. Bei Abbrüchen mal, dass am Ziel ein unvollständiges Objekt liegt (an der Quelle noch komplett), aber so wie du es schreibst mit komplett doppelten Ordnern mit vielen Objekten, noch nie.

/var/services beinhaltet nur Links.
Sowohl homes wie auch die Systemordner von Audio/Video/Photo Station liegen alle unter /volume1 normal (Werkszustand / frische Installation der Stations).
Unter /var/services sind nur links auf volume1 gesetzt.
Und nein, dies ist kein Grund für das "mv mit teilweiser Duplizierung" Symptom.

Auch gesperrte Daten in der Quelle, die er während des mv Vorgangs nicht hätte löschen können, hätten eine Ausgabe zur Folge gehabt.

Aber vielleicht hast du wirklich nur irgendwo links verschoben und deshalb erscheinen Daten doppelt vorhanden die es gar nicht sind, je nachdem, ob du via Konsole oder File Station drauf schaust.

 

[framp]

...Aber vielleicht hast du wirklich nur irgendwo links verschoben und deshalb erscheinen Daten doppelt vorhanden die es gar nicht sind, je nachdem, ob du via Konsole oder File Station drauf schaust...

Ist auch meine Vermutung. Sofern die doppelten Verzeichnisse noch da sind kannst Du ja mal prüfen of Dateien darin Links haben mit

find /oldDir -samefile /oldDir/someFile

 

[kalli82]

Die doppelten Verzeichnisse und Dateien sind nicht mehr da, ich habe sie wie gesagt am Ende komplett gelöscht.

Dementsprechend kann ich nicht nochmal mit find nach Links suchen.

Ich hatte aber wie gesagt mit "ls -a" geprüft, ob die betroffenen Dateien über Hardlinks gekoppelt sind. Die 2. Spalte in der Ausgabe zeigt ja die Anzahl der Hardlinks an. Das war allerdings nicht der Fall, in beiden Ordnern stand bei den Dateien jeweils eine 1.
Gibt es noch andere Arten von Links, die hier eine Rolle hätten spielen können, so dass "find" evtl. einen Mehrwert gegenüber ls gehabt hätte?

So oder so kann ich mir aber kein Szenario vorstellen, in dem ein mv Links erstellt anstatt richtig zu verschieben. Das ganze war auch meinerseits eher ein Versuch, das Symptom zu ergründen, als die Ursache. Die kann ich mir weiterhin nicht erklären.
Ich hoffe nur, dass das Dateisystem von dem "Phänomen" keinen Schlag weg hat.

 

[kalli82]

Ich habe gerade was interessantes gefunden:

Eines der Zusatzfeatures von btrfs z.B. im Vergleich zu EXT* sind reflinks. Kann man z.B. beim Kopieren von Dateien benutzen, indem man "cp --reflink=always ... angibt.

Das, was dann entsteht, scheint exakt so auszusehen wie in meinem Fall von letztens:

Zitat von stackexchange.com:

Note that this isn't anything like a hardlink. When you cp --reflink=always, the result from the user perspective will be two completely independent files in every way.

Auch hier wird ohne zusätzlichen Speicherplatz eine zweite "Kopie" der Datei angelegt, die aber für ihre Inhalte denselben physikalischen Speicher nutzt.

Dann wäre noch die Frage, inwiefern beim Verschieben innerhalb eines Dateisystems mittels mv intern evtl. eine Kombination von cp mit reflinking und rm zum Einsatz kommt. Bzw. durch was in diesem Prozess das Löschen der Quelle evtl. verhindert worden sein kann (und wieso kein Fehler angezeigt wird)...
Ich habe wieder mehr Hoffnung, dass das Dateisystem wirklich keinen Schlag weg hat ;-)


Edit: Falsches Zitat ausgetauscht ;-)

 

[Fusion]

Hatte weiter oben von normalen Links, also Soft-Links, gesprochen. Die werden dir halt nicht angezeigt als Zähler im Gegensatz zu Hard-Links, lassen aber ebenso die Daten mehrfach erscheinen.

 

[tproko]

Denke nicht das es an btrfs liegt, und auch die Theorie mit den reflinks halte ich für unwahrscheinlich. Nachdem du auch nur 2 Unterordner hattest, und nicht alle 6 Unterordner da waren nach dem mv, kann es eher "nichts allgemeines" sein.

Habe selber btrfs und gerade mal bei mir getestet: mit Linux und Files via SMB aufs NAS, und dann 2 Unterverzeichnisse gemacht, ein paar Files erzeugt, und diese mit mv und ssh verschoben.
Ad mv: im gleichen Volume Group ist mv ein rename, ansonsten ist es ein cp -a & rm.

Entweder er konnte ein paar Dateien nicht renamen, da es zu einem Problem kam. Aber ich hätte noch eine andere Vermutung.

Kannst du das nochmals testen?
Wie hast du kontrolliert, ob deine Dateien da sind? Am NAS Dateiexplorer oder SSH oder per SMB/win10?
Ich habe gerade kein Windows zur Hand, aber hat dir evt. unter Win10 und smb der Dateiexplorer ein Ei gelegt, dass er hier durch einen Openfile Handle die bereits "umbenannte" Datei noch angezeigt hat? Unter Linux bleibt der Filehandle offen, aber mit ls sollte nichts mehr sichtbar sein. Aber ob sich win10+smb hier auch verhält...? Wäre meine Vermutung.

 

[kalli82]

Hatte weiter oben von normalen Links, also Soft-Links, gesprochen. Die werden dir halt nicht angezeigt als Zähler im Gegensatz zu Hard-Links, lassen aber ebenso die Daten mehrfach erscheinen.

Ich hatte aber die Quell- und Zielverzeichnisse mit "ls -l" überprüft. Bei Softlinks wären die Dateien nicht einfach mit ihren Dateinamen gelistet worden, sondern mit dateiname->zieldatei. Das wäre mir aufgefallen.
Außerdem wäre da genauso noch zu ergründen, warum mv auf die Idee kommen sollte, die Zieldateien als Softlinks anzulegen.

 

[kalli82]

Entweder er konnte ein paar Dateien nicht renamen, da es zu einem Problem kam.

Ich habe Quell- und Zielverzeichnis vor dem Löschen des Quellverzeichnisses mit TotalCommander synchronisiert. Beide enthielten exakt dieselbe Menge Dateien mit identischen Eigenschaften. Das spricht gegen ein Problem beim Umbenennen, zumal da eine Fehlermeldung zu erwarten gewesen wäre.

Aber ich hätte noch eine andere Vermutung.
Kannst du das nochmals testen?
Wie hast du kontrolliert, ob deine Dateien da sind? Am NAS Dateiexplorer oder SSH oder per SMB/win10?
Ich habe gerade kein Windows zur Hand, aber hat dir evt. unter Win10 und smb der Dateiexplorer ein Ei gelegt, dass er hier durch einen Openfile Handle die bereits "umbenannte" Datei noch angezeigt hat? Unter Linux bleibt der Filehandle offen, aber mit ls sollte nichts mehr sichtbar sein. Aber ob sich win10+smb hier auch verhält...? Wäre meine Vermutung.

Das hatte ich fast als erstes überprüft. Nachdem der eigentlich verschobene Ordner nach Neuladen des Shares mit F5 immer noch sichtbar war, habe ich enthaltene Videos gestartet, sowohl am Quell- als auch am Zielort. Die Videos waren seit Rechnerstart nie geöffnet worden. Ich konnte sowohl identische als auch unterschiedliche Videos sowohl im Quell- als auch im Zielordner abspielen. Spricht gegen offene Handles oder Datencache.
Danach habe ich die Ordner über SSH geprüft mittlels ls -la. Auch ls listete die Dateien in beiden Ordnern. Ohne Hardlink-Zähler > 1 und ohne Pfeile wie bei Softlinks.

Die einzige Linkart, die dazu passt scheinen reflinks zu sein. Wie auch immer die hier zustande gekommen sein sollten bei 2 von 5 mv Aufrufen...

 

[tproko]

Das ist wirklich seltsam.
Danke fürs ausführliche Feedback.

 

[Fusion]

@kalli82 - ich meinte nicht, dass MV soft-links anlegt, sondern, da du /var/services erwähnt hattest (anstatt /volume1/homes z.b.) und dort hauptsächlich soft-links residieren, dass beim MV Befehl schon ein / mehr oder weniger dafür sorgt, ob ein link oder dessen Ziel/Inhalt verschoben wird.

Aber sieht wohl so aus, als ob wir es nicht mehr zusammen gepuzzelt bekommen