Mit Disk Utility erstelltes Image ließ sich nicht zurückspielen

[mj]

Ich hatte heute ein sehr seltsames Problem mit dem Festplattendienstprogramm (Disk Utility) von High Sierra, einer externen 60GB SSD und APFS.

Die SSD ist mit der Zeit aufgrund fehlenden TRIMs ziemlich langsam geworden. Da es sich um eine etwas betagtere SSD ohne garbage collection handelt (Corsair Force F60), wollte ich die volle Performance durch Überschreiben mit Nullen wiederherstellen. Auf der SSD selber war eine erst wenige Tage alte frische Installation von 10.14.6 auf APFS drauf, mit der ich immer wieder verschiedene Dinge teste.

In Vorbereitung habe ich also mit dem Festplattendienstprogramm ein Image sowohl von der Platte selber (also oberste Ebene, der Einfachheit ab jetzt image1 genannt) als auch vom Disk Container, in dem das APFS-Volume liegt (ab sofort image2 genannt), erstellt. Beide Images wurden korrekt angelegt und auf der internen HDD abgelegt. Beide Images konnte ich per Doppelklick mounten und durchsuchen. Nachdem das sichergestellt war, habe ich die SSD mittels diskutil zeroDisk /dev/disk3 mit Nullen überschrieben und wollte das Image wieder zurückspielen - und genau da fingen dann die Probleme an.

• Ein Zurückspielen vom image1 auf die nackte Platte ist mit einem obskuren Fehler, dass das Image erst gemounted werden muss, fehlgeschlagen. Das Image war anschließend gemounted und auf der SSD waren ein APFS Disk Container samt APFS Volume angelegt.
• Ein Zurückspielen des gemounteten image1 auf die nackte Platte war nicht möglich.
• Ein Zurückspielen des gemounteten image1 auf den automatisch im ersten Schritt angelegten Container oder das Volume wurde zunächst das vorhandene APFS-Volume gelöscht, ein neues angelegt und ist dann sofort mit der Fehlermeldung, dass auf dem neu angelegten APFS-Volume nicht genügend Speicherplatz vorhanden sei (not enough space), fehlgeschlagen.
• Ein Zurückspielen des gemounteten image1 auf einen händisch angelegten Container samt Volume ist mit demselben Fehler fehlgeschlagen.
  
  
• Ein Zurückspielen von image2 auf die nackte Platte ist mit demselben Fehler wie schon bei image1 fehlgeschlagen. Auch hier war das Image anschließend gemounted und auf der SSD waren ein APFS Disk Container samt APFS Volume angelegt.
• Ein Zurückspielen von image2 auf den automatisch im ersten Schritt angelegten Container oder das Volume ist mit der nichtssagenden Fehlermeldung, dass beim Wiedererstellen ein Fehler aufgetreten sei, fehlgeschlagen.
• Ein Zurückspielen des gemounteten image2 auf die nackte Platte hat einen Disk Container und ein APFS-Volume angelegt, ist dann allerdings mit der Fehlermeldung, dass nicht genügend Speicherplatz vorhanden sei (not enough space), fehlgeschlagen.
  
  
• Das Verkleineren des APFS Disk Containers von image1 ist mit einer Fehlermeldung, dass das Volume nicht verkleinert werden konnte, fehlgeschlagen.
• Das Verkleineren des APFS Disk Containers von image2 war gar nicht erst möglich, da mir mit diskutil kein passender Container angezeigt wurde.

Dass nicht genug Platz vorhanden war ist ausgeschlossen, die SSD war schließlich exakt dieselbe und das APFS-Volume war in beiden Fällen 58,2GB groß. Die Fehlermeldung soll angeblich darauf zurückzuführen zu sein, dass lokale Snapshots vorhanden sind. Diese konnte ich mittels tmutil listlocalsnapshots /Volumes/Mojave auch sehen nachdem ich image1 oder image2 gemounted habe, es gab genau einen lokalen Snapshots. Löschen konnte ich ihn allerdings wiederum nicht weil deletelocalsnapshots nicht mit Mountpoints arbeitet und ausschließlich auf / arbeitet. Auch thinlocalsnapshots hat nichts gebracht.

Nach über einer Stunde herumexperimentieren habe ich aufgegeben, die SSD händisch mit APFS formatiert und mittels CCC das Image zurückgespielt. Das hat dann funktioniert und mein frisch installiertes Mojave ist jetzt wieder bootfähig. Trotzdem würde mich interessieren was genau hier schiefgelaufen ist und wie ich sowas zukünftig vermeiden bzw. lösen kann. Schließlich scheint APFS laut Apple ja der heiße Scheiß zu sein - ab 10.14 werden alle ob gewollt oder nicht zwangsbeglückt und 10.15 lässt sich auch mit viel Aufwand nicht mehr auf HFS+ betreiben, somit werde ich also künftig sicherlich öfters mal in ähnliche Situationen gelangen.

 

[lisanet]

Du kannst (zur Zeit noch nicht?) eine APFS-Disk nicht mit dem FPDP "klonen".

Der Grund liegt im wesentlichen in der Struktur von APFS mit Preboot, Recovery und VM. Dort wird u.a. die UUID der physischen Disk gespeichert. Die UUID einer Disk wird aber beim Partitionieren jeweils neu erzeugt. Ein "Klon" des APFS-Containers oder der VM hat also immer noch die UUID der originalen Version der Platte (HDD oder SSD) vermerkt, die dann natürlich nicht mit der nach Partitionierung (meines Wissens auch nach Formatierung) neuen UUID übereinstimmt.

CCC löst das meines Wissens so, dass es die Preboot nicht kopiert, sondern beim Restore zusammen bastelt.

Ob das FPDP irgendwann auch das beim "Klonen" macht, weiß ich nicht, glaub ich aber nicht sonderlich.

Warum soll das so sein und warum schriebe ich klonen in Anführungszeichen?

Das was Tools wie CCC unter "Klonen" verstehen, ist nichts anderes als einfaches Dateikopieren. Ein blockweises Kopieren der Festplattensektoren ist das schon seit einigen Jahren nicht mehr. Lediglich das FPDP machte das noch bis vor kurzem mit HFS+-Systemen.

Da es bei SSD faktisch keine reproduzierbaren, physikalisch zuordenbaren Sektoren mehr gibt (wegen des wear levelings) und APFS für SSD entwickelt und optimiert wurde, wird es meines Erachtens (und mit meinem bescheidenem Wissen) einen echten Klon, also ein blockweises und bitgenaues, physikalische exaktes Abbild eines APFS-Systems nicht geben.

Mittel der Wahl für eine Sicherung und ein anschließendes Restore ist Timemachine. Insoweit ist also "klonen" Technik von gestern und war im Grunde unter Tools wie CCC eh nie richtiges klonen, sondern banales Datei kopieren.

Nimm Timemachine für derartige Aktionen, auch wenn hier bei macusers Timemachine eher schlecht geredet und CCC über den grünen Klee gelobt wird. (was beides in meinen Augen aus überkommenem Wissen und von alten System wie Snow Leopard her rührt). Es ist das von Apple vorgesehene System und ich vertraue einer großen Anzahl von Entwicklern des OS-Herstellers und eines der größten Softwareunternehmens mehr, als den Fertigkeiten eines einzelnen Tool-Entwicklers, so begabt er auch sei.

 

[lisanet]

Ach ja, was soll den ein Überschreiben mit Nullen bewirken? Das wir auf die Performance einer SSD keine positiven Auswirkungen haben, eher das Gegenteil (ganz abgesehen davon, dass das Überschreiben mit Nullen bei SSD wegen des wear levelings eh sinnlos ist)
TRIM und Garbage Collection sind Systeme um vom OS gelöschte Dateien / Sektoren dem SSD-Copntroller wieder zum Beschrieben zugänglich zu machen. Bei TRIM übernimmt diese Aufgabe des Bekanntgebens / Veranlassen, welche Daten das sind, das OS, bei Gargage Collection der SSD-Controller, indem er die SSD quasi durchsucht nach nicht mehr in Verzeichniseinträgen verwendeten Sektoren. Wie soll das nun mit "Nullen-überschreiben" optimiert werden?

 

[mj]

Bei der SSD handelt es sich um eine Corsair Force F60 mit Sandforce Controller von 2010, also aus der Frühzeit der SSDs. Der Controller unterstützt zwar bereits TRIM, hat aber keinerlei automatische Garbage Collection, wodurch die Performance bei Verwendung in einem externen USB-Gehäuse oder einem alten Betriebssystem wie Windows XP drastisch einbricht wenn sie eine Weile aktiv genutzt und beschrieben wurde. Aufgrund der Art und Weise wie Flash-Zellen überschrieben und gelöscht werden, nämlich immer nur blockweise, war das Nullen früher eine gute Art und Weise die Performance der SSD wiederherzustellen. Anand Lal Shimpi hat dazu vor mittlerweile über 10 Jahre einen recht guten Artikel verfasst: https://www.anandtech.com/show/2738/8. Bei modernen SSDs ist das alles nicht mehr nötig, da es sich hier aber um eine 9 Jahre alte SSD handelt bringt das Nullen noch immer Vorteile.

Was das Thema FPDP und APFS angeht vielen Dank für die Infos. Der Unterschied zwischen blockweisem Kopieren und Kopieren auf Ebene des Dateisystems ist mir durchaus bekannt und auch, dass CCC auf Dateiebene arbeitet. Mir war aber nicht bewusst, dass das Klonen von APFS mittels FPDP nicht möglich ist und vor allem nicht warum, danke dafür. Ein weiterer wenn auch peripherer Grund für mich meine Produktivsysteme so lange wie möglich so weit wie nur irgend möglich von APFS fernzuhalten und bei HFS+ zu bleiben.

 

[lisanet]

Hhmm, im Artikel ist aber von Secure Erase die Rede und das hat nichts mit „mit Nullen überschreiben“ zu tun. Das ist soweit ich weiß ein ATA Kommando, vergleichbar mit dem Low-Level-Formatieren. So werden die Zellen gelöscht und als nicht belegt gekennzeichnet. Mit Nullen überschreiben löscht zwar auch den vorherigen Inhalt, aber es ist immer noch ein Inhalt, nämlich Nullen, vorhanden.

 

[lisanet]

So ganz logisch kann ich deine Folgerung nicht nachvollziehen. Da ein blockweises Kopieren von APFS nicht geht, verwendest du lieber ein dateiweises Kopieren mit einer Dritt-Anbieter-Software (CCC) auf einem alten, anfälligem Dateisystem (HFS+) anstatt ein ebenso dateiweises Kopieren des OS-Herstellers (Timemachine) auf einem neuen, stabileren Dateisystem (APFS).
Naja, wenn es dich beruhigt, ok, aber so richtig nachvollziehbar finde ich es nicht.

 

[mj]

Stimmt, da ist nur von Secure Erase die Rede. Irgendwie hatte ich im Hinterkopf, dass mit Nullen überschreiben denselben Effekt auf die Zellen hat. Da werde ich wohl nochmal ran müssen.

Und warum ich in diesem speziellen Fall kein Time Machine verwende: viel zu aufwendig und vor im Vergleich elendig langsam. Time Machine hat seine Daseinsberechtigung und ich setze es auch für ein Backup meiner Systeme ein, in dem Fall halte ich es aber für den falschen Ansatz. Das initiale Time Machine Backup dauert immer Ewigkeiten, außerdem müsste ich den Rechner von der SSD booten und währenddessen laufen lassen und noch dazu eine weitere externe Platte für das Backup bereitstellen. Bisher hab ich solche Spiele immer mit dem FPDP nebenbei im Hintergrund erledigen können und damit noch nie Probleme gehabt. Das war jetzt das erste Mal, dass ich statt einer HFS+ eine APFS-partitionierte Platte versucht habe zu sichern und es ist prompt schiefgegangen und dank dir weiß ich jetzt auch warum Gelten deine Aussagen eigentlich noch genauso für 10.14 und 10.15? Ich arbeite aus diversen Gründen noch mit 10.13 und kann mir durchaus vorstellen, dass dies eine Rolle spielt.

Und was die Diskussion angeht ob APFS oder HFS+ jetzt das stabilere System sind: Ich habe meine Gründe warum ich HFS+ bevorzuge und APFS auf Produktivsystemen bis dato strikt ablehne. Once bitten, twice shy

 

[lisanet]

Unter 10.14 ist es noch genauso. 10.15 habe ich noch nicht getestet.