[Gelöst] Kopieren von Daten auf neue SSD ist nicht zuverlässig

[spiralnebelverdreher]

Hallo zusammen,
ich habe hier ein reproduzierbares Verhalten einer neuen SSD, das ich nicht verstehe und das mir Sorgen bereitet.

In meinem Lenovo X260 Notebook tat 1,5 Jahre lange eine 2 TB große SSD (MX500 von Crucial) brav ihren Dienst, bevor sie diesen abrupt aufgab und vom Händler durch ein Modell des gleichen Typs ersetzt wurde. Ich habe dann also diese Austausch-SSD über einen SATA-Adapter komplett mit Zufallszahlen vollgeschrieben und dann in das Notebook eingebaut und darauf Debian Bookworm neu mit Verschlüsselung der gesamten Platte und LVM installiert, so wie es der Installer mir als Option angeboten hat. Hat alles funktioniert, Debian bootet; XFCE sieht so aus wie vorher, Updates wurden gemacht und Software installiert. Bis dahin alles fein und problemlos.

Dann habe ich meine externe Backup-Platte hergenommen und an den USB3-Anschluss angesteckt und habe einen Teil meines Fotoverzeichnis mittels Thunar auf die SSD kopiert. Es handelt sich dabei um gut 41.000 Dateien in 142 Ordnern mit einer Gesamtgröße von 217 GiB. Das dauerte eine gute Stunde und verlief ohne Probleme.

Um sicher zu gehen, dass wirklich alles da ist, habe mit

Code: Alles auswählen

diff -r /home/blablubb/FotoArchiv/  /media/blablubb/Tosh-4TB-BU-luks/backup_rdiff/usw/usw/  

die eingespielten Dateien mit denen auf der externen Platte verglichen.
Bei gut 80 Dateien gab es Unterschiede! Ich habe mir die ersten Dateien mit den Unterschieden angesehen: optisch zeigen beide jpg Dateien auf den ersten Blick genau das gleiche Bild, aber wenn ich den Hashwert über die Dateien bilde ist dieser unterschiedlich.
Dann habe ich das ganze Verzeichnis /home/blablubb/FotoArchiv/ gelöscht und das ganze Zeugs nochmal rüberkopiert, diesmal mit

Code: Alles auswählen

rsync -iaH  /media/blablubb/Tosh-4TB-BU-luks/backup_rdiff/usw/usw/  /home/blablubb/FotoArchiv/  

und wieder mit

Code: Alles auswählen

diff -r /home/blablubb/FotoArchiv/  /media/blablubb/Tosh-4TB-BU-luks/backup_rdiff/usw/usw/  

und

Code: Alles auswählen

rsync -niaHc  /media/blablubb/Tosh-4TB-BU-luks/backup_rdiff/usw/usw/  /home/blablubb/FotoArchiv/  

auf Unterschiede geprüft.
Auch hier waren wieder etwa 80 bis 90 Dateien unterschiedlich. Auch wiederholte Prüfungen mit diff und rsync bringen Unterschiede. Die auffälligen Dateien sind halbwegs gleichmäßig über die Ordner verteilt, aber nicht komplett zufällig verteilt. Manche Dateinamen tauchen immer wieder auf.

Diese Prüfungen auf Unterschiede mit diff und rsync habe ich mehrfach wiederholt und das Ergebnis ist in folgenden Parametern reproduzierbar: etwa 80 - 90 Dateien werden verändert beim Kopieren; es sind aber nicht immer identische Listen mit den unterschiedlichen Dateien. Es ist von den Dateitypen (und damit auch den Dateigrößen) her etwa so verteilt zwischen jpg, Video und Fotodaten im Raw-Format wie es ganz grob meiner Mediensammlung entspricht. Einen Zusammenhang mit der Dateigröße kann ich nicht erkennen.
Weiterhin habe ich mir die S.M.A.R.T Daten der Laufwerke angesehen und Selbsttests laufen lassen ohne irgendwas Auffälliges zu finden.

Die permanenten Unterschiede beim Kopieren sind erstaunlich, denn insbesondere bei rsync ist ja die Zusicherung, dass rsync prüft, ob die Dateien korrekt geschrieben wurden. Zitat aus der man-page von rsync:

Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option's before-the-transfer "Does this file need to be updated?" check.

Hat jemand von euch eine Idee, was die Ursache für diese seltsame Verhalten sein könnte? Auch wenn die übertragenen Dateien auf den ersten Blick immer noch wie korrekte Mediendateien aussehen, will ich diese Ergebnisse der Unterschiedsprüfung nicht vernachlässigen.

[niemand]

Hast du denn mal geschaut, inwiefern sich die Dateien unterscheiden? Also diff über ’nen Hexdump? Gegebenenfalls auch mal Differenzbild erstellen lassen und begutachten.

insbesondere bei rsync ist ja die Zusicherung, dass rsync prüft, ob die Dateien korrekt geschrieben wurden.

Glaube, das bezieht sich auf den Übertragungsweg, wenn am anderen Ende ein rsyncd arbeitet.

[spiralnebelverdreher]

Hast du denn mal geschaut, inwiefern sich die Dateien unterscheiden? Also diff über ’nen Hexdump? Gegebenenfalls auch mal Differenzbild erstellen lassen und begutachten.

insbesondere bei rsync ist ja die Zusicherung, dass rsync prüft, ob die Dateien korrekt geschrieben wurden.

Glaube, das bezieht sich auf den Übertragungsweg, wenn am anderen Ende ein rsyncd arbeitet.

diff über nen Hexdump hab ich noch nicht gemacht, aber werde das mal tun. Ist bei einigen MByte jpg sicher kleine Sache Ob ich damit was anfangen kann, weiß ich nicht. Auf was soll ich da schauen?

[niemand]

Auf was soll ich da schauen?

Aus Stelle und Ausmaß der Abweichungen lässt sich möglicherweise eine Ursache ableiten. Wenn’s keine besonders schützenswerten Bilder sind (etwa welche mit Personen drauf, oder so), könntest du vielleicht ein Bild in beiden Versionen irgendwo zur Verfügung stellen – das würd’s für einfacher für jeden machen, der da auch mal schauen will.

[spiralnebelverdreher]

Auf was soll ich da schauen?

Aus Stelle und Ausmaß der Abweichungen lässt sich möglicherweise eine Ursache ableiten. Wenn’s keine besonders schützenswerten Bilder sind (etwa welche mit Personen drauf, oder so), könntest du vielleicht ein Bild in beiden Versionen irgendwo zur Verfügung stellen – das würd’s für einfacher für jeden machen, der da auch mal schauen will.

Weiß nicht, ob das zielführend ist.
Ich bin da einfach gestrickt: ich kopiere 41.000 Dateien und es gut bei fast allen gut, bis auf etwa 80. Ich will aber, dass es bei allen gut geht und mich interessiert nicht, ob die Differenz klein oder groß ist.

[spiralnebelverdreher]

Hast du denn mal geschaut, inwiefern sich die Dateien unterscheiden? Also diff über ’nen Hexdump?

Hier ist die Differenz. Wie mir scheint, hat sich genau ein Bit geändert.

Code: Alles auswählen

diff /EXT_20070711_LX_103_0040_ORIG.jpg.hex SSD_20070711_LX_103_0040_ORIG.jpg.hex 

141532c141532
< 0229df0 6ebf 1d4f f04f f6e3 f86e e3d3 192b ea58
---
> 0229df0 6ebf 1d4f f00f f6e3 f86e e3d3 192b ea58

[niemand]

Wie mir scheint, hat sich genau ein Bit geändert.

Ja (0b01001111 → 0b00001111). Die interessante Frage ist, an welcher Stelle das nun geschehen sein mag. Hast du mal memtest86+ durchlaufen lassen? RAM ist ’ne beliebte Stelle für solche Sachen …

[spiralnebelverdreher]

Wie mir scheint, hat sich genau ein Bit geändert.

Ja (0b01001111 → 0b00001111). Die interessante Frage ist, an welcher Stelle das nun geschehen sein mag. Hast du mal memtest86+ durchlaufen lassen? RAM ist ’ne beliebte Stelle für solche Sachen …

Ich hab's mir gerade runter geladen und werde es mal eine Weile laufen lassen vor dem Neustart. Bericht dauert etwas länger als bei diff hexdump

[spiralnebelverdreher]

Wie mir scheint, hat sich genau ein Bit geändert.

Ja (0b01001111 → 0b00001111). Die interessante Frage ist, an welcher Stelle das nun geschehen sein mag. Hast du mal memtest86+ durchlaufen lassen? RAM ist ’ne beliebte Stelle für solche Sachen …

Treffer!
Memtest zeigt im ersten Durchlauf 64 Fehler.

[spiralnebelverdreher]

Ich sehe die Fehler im RAM als plausible Ursache für das gezeigte Fehlerbild und setze den Faden hier erst mal auf "Vorläufig gelöst"

[spiralnebelverdreher]

Wie mir scheint, hat sich genau ein Bit geändert.

... Hast du mal memtest86+ durchlaufen lassen? RAM ist ’ne beliebte Stelle für solche Sachen …

Herzlichen Dank für den hilfreichen Hinweis!

[letzter3]

Code: Alles auswählen

rsync -iaH  /media/blablubb/Tosh-4TB-BU-luks/backup_rdiff/usw/usw/  /home/blablubb/FotoArchiv/ 

... denn insbesondere bei rsync ist ja die Zusicherung, dass rsync prüft, ob die Dateien korrekt geschrieben wurden. Zitat aus der man-page von rsync:

Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option's before-the-transfer "Does this file need to be updated?" check.

M.E. wird das Prüfen mittels Prüfsumme mit der Option c aktiviert. c ist nicht in a enthalten. Ich denke, Ihr Zitat aus der manpage ist unvollständig

--checksum, -c
This changes the way rsync checks if the files have been changed and are in need of a transfer. Without this option, rsync uses a "quick check" that (by default) checks if each file's size and time of last modification match between the sender and re‐
ceiver. This option changes this to compare a 128-bit checksum for each file that has a matching size. Generating the checksums means that both sides will expend a lot of disk I/O reading all the data in the files in the transfer, so this can slow things
down significantly (and this is prior to any reading that will be done to transfer changed files)

The sending side generates its checksums while it is doing the file-system scan that builds the list of the available files. The receiver generates its checksums when it is scanning for changed files, and will checksum any file that has the same size as
the corresponding sender's file: files with either a changed size or a changed checksum are selected for transfer.

Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do
with this option's before-the-transfer "Does this file need to be updated?" check.

The checksum used is auto-negotiated between the client and the server, but can be overridden using either the --checksum-choice (--cc) option or an environment variable that is discussed in that option's section.

[spiralnebelverdreher]

Ich sehe die Fehler im RAM als plausible Ursache für das gezeigte Fehlerbild und setze den Faden hier erst mal auf "Vorläufig gelöst"

Mit Einbau des neuen RAM Riegels tritt der Fehler nicht mehr auf.
Problem gelöst! Vielen Dank für eure Mithilfe.