Samsung 860 Evo nach CCC Clonen unterschiedlicher Speicherverbrauch

[marcozingel]

Ich sichere die interne HDD auf 4 externe SSD (2 x Samsung 860 Evo 250GB und 2 Samsung 860 Evo 500 GB).

Bei den zwei Samsung 860 Evo mit 500 GB werden nach der Spiegelung ein unterschiedlicher Speicherverbrauch angezeigt.

Die Differenz beträgt etwa 30 GB.

Die Daten sind aber exakt die gleichen.

Alle SSD sind im APFS Format formatiert.

Festplattendienstprogramm gibt folgendes aus:

Erste Hilfe auf „Samsung 860 Evo (003)“ (disk9s1) ausführen

Dateisystem reparieren.
Volume wurde erfolgreich deaktiviert.
fsck_apfs -y -x /dev/rdisk9s1 ausführen
Checking the container superblock.
Checking the EFI jumpstart record.
Checking the space manager.
Checking the space manager free queue trees.
Checking the object map.
Checking volume.
Checking the APFS volume superblock.
The volume Samsung 860 Evo (003) was formatted by diskmanagementd (945.241.4) and last modified by apfs_kext (945.250.134).
Checking the object map.
Checking the snapshot metadata tree.
Checking the snapshot metadata.
Checking snapshot 1 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 2 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 3 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 4 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 5 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 6 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 7 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 8 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 9 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 10 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 11 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 12 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 13 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 14 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking snapshot 15 of 15.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Checking the extent ref tree.
Checking the fsroot tree.
warning: inode_val: object (oid 0x11acca): invalid bsd_flags (0x10)
Verifying allocated space.
The volume /dev/rdisk9s1 appears to be OK.
Exit-Code für Dateisystemprüfung lautet 0.
Der ursprüngliche Zustand (aktiviert) wird wiederhergestellt.

Vorgang erfolgreich.

 

[Wuchtbrumme]

Geht es Dir jetzt nur um die in den Bildern angezeigten Datenträger? Wenn ich das mal unterstelle, dann hat die mutmaßliche Source auf dem Mac Mini ca. 129GB in zu klonenden Daten. Datenträger "Samsung 860 EVO (004)" hat circa diese Menge, also kein Problem, weil CCC sowieso die eine oder andere Sache, die gerätespezifisch ist bzw. sowieso neu gebaut wird (Caches) weglässt. Bleibt also "Samsung 860 EVO (003)". Wenn Du noch genauer hinschaust, dann siehst Du "benutzt" und darüber in Klammern "löschbar" - subtrahiere mal den löschbaren Speicher vom belegten Speicher und Du kommst bei beiden externen SSDs auf ca. 127GB. Passt also.
Ich vermute mal, dass Du die 003 vorher schon einmal benutzt hattest. MacOS kümmert sich selbst um die Freigabe von löschbarem (Fest-)Speicher, wie Marcel das schon thematisiert hatte und wie man z.B. bei DaisyDisk nachlesen kann.

Unabhängig davon würde ich die SSD, von der der Report des Festplattendienstprogramm-Checks ist, löschen, da es offensichtliche Fehler im Dateisystem gibt, die entgegen des Ersteindrucks auch nicht behoben wurden. Wirft fleißig Warnings und meint dann Exit-Code 0 und danach stellt es noch den alten Zustand wieder her. Ich dachte, dieses Verhalten wäre schon seit 10.13.6 behoben, offensichtlich ist es wieder da (oder ich verstehe was falsch, aber ich habe ein reines Gewissen...).

 

[marcozingel]

Danke für die ausführliche Diagnose.

Mit den Fehlern kann man ja nicht viel anfangen, aber da es offensichtlich Fehler zu sein scheinen, werde ich die funktionierende SSD löschen und neu einspielen.

Allerdings stimmt mich das nicht sonderlich sicher mit den SSD Fehlern, auf 4 WD Black WD10JPLX funktioniert alles reibungslos seit Jahren im 7/24 Stunden Dauerbetrieb ohne jegliche Fehler.

Lieben Dank.

 

[Wuchtbrumme]

ach, das kann auch Zufall sein. Passiert vielleicht einmal warum auch immer und nach dem Löschen tritt es nie wieder auf. Einfach ein Auge drauf haben.

 

[marcozingel]

Irgendwie hat diese Samsung 860 Evo von Anfang an gezickt.

Spiele grad neu auf aber werde sie dann wohl über Samsung tauschen.

Es scheint ebenso immer noch unter MacOS Mojave 10.14.4 mit USB Probleme zu geben,da sie direkt am Mac angeschlossen mal erkannt wird und mal nicht.

An einem USB Hub mit eigener Stromversorgung werden beide als RAID (JBOD) erkannt.


Ich gehe mal Brötchen holen

 

[Marcel Bresink]

Bei den zwei Samsung 860 Evo mit 500 GB werden nach der Spiegelung ein unterschiedlicher Speicherverbrauch angezeigt.

Die Differenz beträgt etwa 30 GB.

Wenn Du APFS verwendest, ist das völlig normal, denn dort lässt sich gar nicht so einfach definieren, was "Speicherverbrauch" überhaupt sein soll. Mit Spiegelung meinst Du wahrscheinlich, dass Du die Volumes kopierst und nicht die physische Platte.

Bei APFS wird der Speicher, den die Volumes verwenden, nicht von den Volumes selbst verwaltet. Er wird in Wirklichkeit einem Pool von Speicher entnommen, dem APFS-Container. Eine macOS-Installation liegt in einem Container, der mindestens 4 Volumes enthält. Die Volumes teilen sich den Speicher, d.h. es gibt keine klare Zuordnung, für wen Speicher "frei" ist. Auf jedem Volume können zudem virtuelle Schnappschuss-Volumes liegen, die im Normalbetrieb völlig unsichtbar sind, aber ebenso geteilten Speicher verwenden. Dadurch, dass der Speicher aus dem Pool potenziell jedem Volume und Schnappschuss zur freien Verfügung steht, wird der scheinbar freie Speicher aus deren Sicht mehrfach gezählt.

Wenn Du genauer hinschaust, siehst Du übrigens sogar, dass der Speicherverbrauch von den aktiven, "sichtbaren" Daten exakt gleich ist: Bei der linken Evo werden aber im Moment 34,6 GB für löschbaren Speicher, bei der rechten nur 2,5 GB für löschbaren Speicher verbucht. Da diese Inhalte beim Spiegeln des Volumes nicht mitkopiert wurden, dürfte es sich um gelöschte Daten handeln, die noch auf unsichtbaren Schnappschuss-Volumes gehalten werden.

Die obigen Meldungen sind außerdem keine Fehler. Es handelt sich nur um einen Hinweis, dass für eine Datei ein "No-Unlink"-Attribut gesetzt ist. Dieses Attribut wird von einigen anderen Unix-Systemen als Umbenennungs- und Lösch-Schutz verwendet, wird von macOS aber nicht beachtet, weil es hierfür traditionell ein anderes Attribut nutzt.

Irgendetwas zu verändern oder gar die Hardware zu tauschen, ist komplett sinnlos.

 

[marcozingel]

Danke Wuchtbrumme & Marcel Bresink

Nun wird nach erneutem Aufspielen die Größe korrekt angezeigt aber dennoch wieder mit "Pseudofehlern" die ich dann ignorieren kann und ich mich daran zu gewöhnen habe ?

Erste Hilfe auf „Samsung 860 Evo (003)“ (disk12s1) ausführen

Dateisystem reparieren.
Volume wurde erfolgreich deaktiviert.
fsck_apfs -y -x /dev/rdisk12s1 ausführen
Checking the container superblock.
Checking the EFI jumpstart record.
Checking the space manager.
Checking the space manager free queue trees.
Checking the object map.
Checking volume.
Checking the APFS volume superblock.
The volume Samsung 860 Evo (003) was formatted by diskmanagementd (945.250.134) and last modified by apfs_kext (945.250.134).
Checking the object map.
Checking the snapshot metadata tree.
Checking the snapshot metadata.
Checking snapshot 1 of 1.
warning: inode_val: object (oid 0x120e3c): invalid bsd_flags (0x10)
Checking the extent ref tree.
Checking the fsroot tree.
warning: inode_val: object (oid 0x120e3c): invalid bsd_flags (0x10)
Verifying allocated space.
The volume /dev/rdisk12s1 appears to be OK.

Vorgang erfolgreich.