Kleine Warnung an alle, die auf ihrer SSD noch mit HFS+ arbeiten wollen:

So, wie es aussieht, hat das letzte Sicherheitsupdate meine SSD umformatiert. Ich dachte, das passiert nur bei größeren Updates und hatte zunächst nicht darauf geachtet sondern weitergearbeitet.

Long Story:
Zumindest bei mir ist die Adobe CS6 nicht mit APFS kompatibel. Ich hatte nun in den letzten Tagen auf einmal in InDesign das Problem, dass nach dem Programmstart die Farbeinstellungen nicht gelesen wurden – da habe ich noch gedacht "oh, jetzt passiert das auch auf HFS+. War wohl voreilig von mir, es auf APFS zu schieben!" Habe zuviel zu tun und erstmal nicht weiter nachgeforscht.

Gestern kam ein neues Problem hinzu: Bild in Photoshop bearbeitet, dann Fehlermeldung beim speichern: Konnte nicht speichern, weil ein Programmfehler aufgetreten ist. Ok, hatte ich irgendwann schon einmal. Ist ärgerlich, aber Photoshop neustarten und im schlimmsten Fall das Foto in ein neues Foto kopieren hilft – nur gestern nicht.

Das zu bearbeitende Foto war weg. Verschwunden. Nicht zu finden!

Also Foto aus Backup wiedergeholt, bearbeitet, Fehler beim speichern. Foto weg. Erstmal mit einem anderen Bild weitergemacht, alles in Ordnung. Noch ein anderes, Fehler, Foto weg.

So etwas hatte ich noch nie zuvor am Mac erlebt.

Also erstmal die Platte checken, Festplattendienstprogramm aufrufen – oh! Wie nett! Mein System hat jetzt APFS. Erste Hilfe sagt natürlich das alles in Ordnung ist. Nö, ist es nicht – denn das neue FS macht bei mir Probleme.

Erst dann habe ich mich daran erinnert, vor ein paar Tagen das Sicherheitsupdate installiert zu haben. Ich habe keine andere Erklärung, als dass dabei heimlich auf APFS umformatiert wurde.

Ich habe noch High Sierra am Start, die ursprüngliche Installation hatte ich mit dem Terminalbefehl auf HFS+ gezwungen, bei allen weiteren Updates war es anscheinden nicht notwendig – bis jetzt.

Jetzt darf ich einen Clone des Systems auf Festplatte machen, zur Sicherheit noch einen zweiten Clone anlegen, diesen testen, dann ein Stoßgebet sprechen und die SSD neu formatieren, und dann das System zurück clonen. Dauert ja nur mehrere Stunden, in denen ich nicht arbeiten kann. Nur weil ihr euer neues FS so geil findet, dass ihr heimlich immer wieder versucht eure User damit zu beglücken, und keinen Rückweg zu HFS+ vorseht.

Danke Apple. FÜR NICHTS!

Danke für den Hinweis. Aber ich dachte eher daran, daß man die Software für die TM auch umstellen könnte. Dann tritt aber auch bei Apple selbst das leidige Problem der Rückwärtskompatibilität auf. Also, entweder man braucht dann zwei Programme für die TM, oder man hat auf ewig zwei verschiedene Dateisysteme im OS. (Unter "ewig" ist hier ein Zeitraum von etwa 10 Jahren zu verstehen.)

Time Machine wird noch umgebaut. Hard links auf Verzeichnisse unterstützt außer HFS+ so ziemlich kein System (sie wurden in Leopard auf HFS+ draufgebolzt, um Time Machine zu ermöglichen), und da eines von APFS' Hauptaugenmerk auf Daten-Integrität liegt (Copy on Write, Snapshots, checksums, etc.), werden sie auch nicht kommen, da sie Potenzial für Datenverlust bieten.

Dafür bietet APFS jetzt schon lokale Snapshots an — also Time Machine auf dem Systemlaufwerk selbst, in einer Form, die vorher kaum möglich war.

Dazu braucht es soweit ich weiß kein neues Dateisystem. Load balancing ist Sache des SSD-Controllers; das hat auch vorher funktioniert.

Die Lebensdauer von SSD-Laufwerken war auch vor APFS schon deutlich höher angesetzt als die durchschnittliche Nutzungsdauer eines Macs.

Aber dass sie da optimieren, vor allem wenn Laufwerke fest verlötet sind, liegt auf der Hand, ja.
Grundfunktionen waren fertig und bereits ein halbes Jahr vor OS X in iOS implementiert.

APFS führt durch seine Fähigkeit, bei verschiedenen Versionen nur die kleinen veränderten Teile der Dateien neu zu schreiben (und nicht die ganze Datei), zu extremer Fragmentierung. Dies ist für mechanische Festplatten schwierig.

Dass sie zunächst für die Laufwerke entwickeln, die sie fast ausschließlich verbauen (bis auf wenige Fusion-Laufwerke), liegt schon nahe, oder?

Die Trennung von Metadaten und Nutzerdaten habe ich mit keiner Silbe erwähnt — ich bin nicht sicher, was du damit meinst? Ist das eine Anspielung auf die Aufspaltung des Systemlaufwerks in Catalina in eine vollkommen abgekapselte Systempartition und eine nutzerbeschreibbare Datenpartition? Denn die Fähigkeit, zwei logische Partitionen im gleichen physischen Raum leben zu haben und sie jederzeit dynamisch freizugeben, ist ebenfalls erst seit APFS überhaupt möglich.

spheric
Meta-Daten sind Angaben über die Nutzdaten. Z.B. Länge der Datei, Zugriffsrechte, Speicherort, Verknüpfungen, Erstellung- und Änderungsdatum etc. Diese Daten waren bisher zum Teil mit den Nutzdaten vermischt und sind nun fein säuberlich getrennt untergebracht. Bei einem Snapshot werden nur die aktuell veränderten Meta-Daten, nicht aber die Daten selbst gesichert.

Ah. Das Verzeichnis.

Ägypten? Wenn ich am Dateiinhalt (den meinst Du ja wohl mit den „Daten selbst“) etwas verändere, muss das natürlich ebenso in dem Snapshot protokolliert werden wie Änderungen der Metadaten.

Weia
Umgekehrt wird ein Schuh daraus. Wenn am Dateiinhalt etwas seit dem letzten Snapshot verändert wurde, wird das in den Metadaten vermerkt (z.B. neues Änderungsdatum.) Bei einem neuen Snapshot werden alle veränderten Meta-Daten gesichert. Die zugehörigen Nutzdaten sind gegen Löschen geschützt, und beim (erneuten) Schreiben wird eine Kopie angelegt. Erst bei dem zum Snapshot gehörenden Backup werden die Nutzdaten zusammen mit den Metadaten gesichert. Dann wird beides als "löschbar" gekennzeichnet. Der Snapshot selbst gilt damit auch als gelöscht. Das tatsächliche Löschen erfolgt aber erst wenn freier Platz gebraucht wird. (Oder -- bei SSDs -- beim nächsten Trimm.)

Im Prinzip ja. Etwas korrekter: Alles, was keine Nutzdaten sind.

Gut und schön, aber diese Kopie wird doch eben mit dem neuen Inhalt gesichert, alles andere wäre ja sinnbefreit.

Ich glaube, wir reden hier nur aneinander vorbei. Vermutlich hast Du es einfach nicht wörtlich gemeint, dass die veränderten Daten selbst (im Gegensatz zu den Metadaten) überhaupt nicht gesichert werden.

Weia
Vor jeder Datensicherung wird erst ein Snapshot gemacht. Erst Danach erfolgt die eigentliche Sicherung der betreffenden Meta- und Nutzdaten. Alle nach dem Snapshot veränderten Daten werden nicht gesichert. Deren Sicherung erfolgt erst nach dem nächsten Snapshot.

Ich vergaß zu schreiben, daß nach der Datensicherung nur die Originale der seit dem SS veränderten Daten als löschbar gekennzeichnet werden. Der Löschschutz der übrigen Daten wird aufgehoben.

Neben der Datensicherung dient der SS der Wiederherstellung des Datenbestandes auf den Zeitpunkt des SS. Es ist klar, daß der SS nach der Wiederherstellung gelöscht werden kann und muß.

Wenn der SS direkt gelöscht wird, sind nur dessen Meta-Daten zu löschen und die Originale der zwischenzeitlich veränderten Nutzdaten.

Der erste SS einer neu beschrieben Partition umfasst logischer Weise deren gesamten Inhalt.

Lokale Sicherungen für unterwegs gab es bei TM schon lange. Echte Sicherungen sind das natürlich genausowenig wie diese Snapshots, sie nützen vor allem Leuten, die wild rumspielen und rumlöschen oder bei wichtigen Arbeiten nicht regelmäßig zwischensichern (auch unterwegs auf einem Stick o.ä.), und auch da nützen sie nur beschränkt. Platte futsch oder MacBook geklaut, und dann?
Die Snapshots sind sicher nicht negativ zu beurteilen, man sollte nur bei unbedarften Benutzern nicht den Eindruck erwecken, sie wären echte Sicherungen oder man könne jetzt blind darauf vertrauen, daß jeder Layer-9-Fehler korrigierbar wäre.

Du meinst mit eigentlicher Sicherung das Backup, ja?

Ich meinte damit, dass der Nutzer sein Dokument (nach einer Modifikation) sichert …

Das stimmt doch nur bedingt. Würde das Hauptaugenmerk auf Daten-Integrität liegen, dann wären die Checksums bei APFS nicht nur auf Metadaten beschränkt.
"APFS checksums its own metadata but not user data. "
"as noted though there’s no data redundancy and no checksums for user data, so scrub would only help to find problems and likely wouldn’t help to correct them."
http://dtrace.org/blogs/ahl/2016/06/19/apfs-part5/

Aber nicht in Nullzeit. Das ist ein Unterschied ums Ganze.
Snapshots sollen doch gar keine Sicherungen sein, sondern sind eingefrorene, konsistente Momentaufnahmen des Systems, von denen aus man dann „richtige“ Backups machen kann, während der Betrieb weiterläuft.

Natürlich sind Snapshots Backups. Bei ZFS und Btrfs gibt es dafür extra Befehle (ZFS send) und entsprechende Helferlein, wie ZnapZend:

"ZnapZend is a ZFS centric backup tool to create snapshots and send them to backup locations."
https://github.com/oetiker/znapzend#packages

Sind sie natürlich nicht.
Das rot Hervorgehobene passiert bei den macOS-Snapshots nicht. Ud deshalb sind es keine Backups. Sie sind die Vorbereitung zum Backup, der erste der beiden oben zitierten Schritte.

Den zweiten Schritt erledigt auf macOS Time Machine, das den Snapshot auf die Time Machine-Festplatte überträgt. Oder wahlweise Drittanbieter-Software wie z.B. SuperDuper!.

Das rot markierte habe ich natürlich als Selbstverständlichkeit angenommen (unabhängig davon, wie der Snapshot auf das Backup gelangt). Du hattest von Snapshots allgemein gesprochen.

Na gut, wenn Du das, was aus einem Snapshot ein Backup macht, als selbstverständlich voraussetzt, dann hast Du natürlich trivialerweise recht.
Richtig, und die sind allgemein, für sich genommen, eben keine Backups.

Konkret hatte ich mich auf almdudi bezogen, der ja eben gerade explizit beklagte, manche macOS-Nutzer meinten, sie hätten in Form eines Snaphots bereits ein Backup, auch wenn der Snapshot eben nicht an anderer Stelle abgespeichert wird.

Ich möchte nun das Sicherheitsupdate auf meinem MacBook Pro mit interner SSD installieren, ohne dass auf APFS umformatiert wird.

Kann mir jemand mit mehr Erfahrung im Terminal bitte bestätigen oder korrigieren, ob folgende Syntax korrekt ist (SecUpd2020-001HighSierra.pkg liegt im Programmordner):

Gibt es einen Weg zu checken, ob installer den Schalter "--converttoapfs NO" überhaupt kennt? "man installer" sagt nichts dazu.

Falls der Schalter "--converttoapfs NO" nicht berücksichtigt wird, läuft dann die Installation trotzdem weiter, oder wird sie mit einer Fehlermeldung abgebrochen?