Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>HS wandelt SSD nicht in apfs?

HS wandelt SSD nicht in apfs?

kay111.01.1813:05
Moin,

kurze Frage: habe hier ein mit dem SierraPatcher "gepimptes" MacBook (Alu, late 2008). Auf diesem befindet sich neben der Mac HD eine Bootcamp-Partition. Nach der Installation von HS ist die Mac HD nach wie vor als HFS-Volume gelistet. Im Rechner werkelt eine 480 GB Crucial vor sich hin. Auf einem späteren Modell (Air, 2011 mit Apple SSD) wurde das System in apfs gewandelt. Liegt´s an der Bootcamp-Partition? Ist nicht wahnsinning wichtig, aber mich würd´s mal interessieren. Die Bootcamp-Partition ist mittlerweile Geschichte, wie ist denn der Weg, die SSD im Alu auf apfs umzustellen?
Danke im voraus!
0

Kommentare

elBohu
elBohu11.01.1813:18
Ich habe das Problem mit einem MacMini, der nachträglich eine SSD bekommen hat.
Die bekomme ich auch nicht auf APFS... klemme mich also mal dahinter.
„wyrd bið ful aræd“
0
rene204
rene20411.01.1813:32
Falls gewünscht von externen Medium booten, ggf. USB-Installationsstick, Festplattendienstprogramm von dort aufrufen, interneSSD-Volumen deaktivieren und über die Menueleiste in afps konvertieren aktivieren, und schon geht es los.
„Gelassenheit und Gesundheit.. ist das wichtigste...“
+1
elBohu
elBohu11.01.1814:04
Aber gehen denn dann die Daten nicht verloren?
Man sollte ja über die Rettungsoption dran kommen, da ist konvertieren aber ausgeblendet.
Versuche es mal mit dem externen Boot Medium.
Danke!
„wyrd bið ful aræd“
0
MikeMuc11.01.1814:42
Ist doch egal wenn die Daten Hops gehen, aus dem Grund hast du doch vorher ein Backup gemacht
+2
elBohu
elBohu11.01.1814:53
Jaja... kostet aber Zeit. Vielleicht ist apfs doch nicht so wie wichtig.
„wyrd bið ful aræd“
-3
kay111.01.1819:42
Danke erstmal. Aaaber: hängt´s denn damit zusammen, dass die BC-Partition vor dem Update angelegt war? Wäre ja logisch, da die ganze SSD nicht als apfs "gewandelt" werden kann?

@rene204: so weit, so klar. Allerdings ist das, wie elBohu wohl richtig bemerkt hat, nicht mit konvertieren alleine getan ...
0
kawi
kawi11.01.1819:47
MikeMuc
Ist doch egal wenn die Daten Hops gehen, aus dem Grund hast du doch vorher ein Backup gemacht


elBohu
Jaja... kostet aber Zeit. Vielleicht ist apfs doch nicht so wie wichtig.

Offenbar sind ja dann auch deine Daten nicht so wichtig.
*scnr
+2
bmonno11.01.1820:35
Das liegt nicht an Bootcamp, sondern ist das Standardverfahren beim HighSierraPatcher, der ja die Installation auf nicht unterstützten Rechnern ermöglicht. Man kann es in einem Extraschritt ändern, ist aber wohl ein ziemliches Verbiegen des Systems und auch nicht problemfrei, z.B. "Please note that if you use APFS, you will not have a bootable Recovery partition".
Ich würde es auch nicht machen, da APFS für mich keine messbaren Performanzvorteile hat (selbst verglichen).
Kannst ja den Thread zu diesem Problem durchstöbern.
kay1
Moin,

kurze Frage: habe hier ein mit dem SierraPatcher "gepimptes" MacBook (Alu, late 2008). Auf diesem befindet sich neben der Mac HD eine Bootcamp-Partition. Nach der Installation von HS ist die Mac HD nach wie vor als HFS-Volume gelistet. Im Rechner werkelt eine 480 GB Crucial vor sich hin. Auf einem späteren Modell (Air, 2011 mit Apple SSD) wurde das System in apfs gewandelt. Liegt´s an der Bootcamp-Partition? Ist nicht wahnsinning wichtig, aber mich würd´s mal interessieren. Die Bootcamp-Partition ist mittlerweile Geschichte, wie ist denn der Weg, die SSD im Alu auf apfs umzustellen?
Danke im voraus!
0
kay111.01.1823:03
Na, dann nochmals danke sehr. Wäre nett gewesen, wenn´s ohne grosse Frickelei funktionieren würde, aber, wie geschrieben, nicht so wichtig. Allerdings bin ich bei dem älteren Air (2011) echt erstaunt, was für ein Tempo z.B. beim kopieren von grossen Dateien (Filme etc.) das apfs an den Tag legt.
0
bmonno12.01.1803:11
Das Duplizieren großer Video-Dateien kommt bei mir sehr selten vor. Da hat APFS sicher Vorteile, das Verschieben auf der Platte schon eher. Aber da ist HFS+ auch nicht langsam. Bei einem 1,3 GB großen Bild mit minimalen Änderungen hatte ich erwartet, dass beim Sichern APFS schneller als HFS+ ist, aber dem war nicht so. Und High Sierra selbst scheint ein flottes System zu sein (unabhängig vom Datei-System).

Und die Frickelei liegt daran, dass es für diese Macs eben kein Firmwareupdate von Apple gibt für den Einsatz von APFS.
0
elBohu
elBohu12.01.1807:24
kawi
Offenbar sind ja dann auch deine Daten nicht so wichtig.
*scnr

Das ist ja mal Quatsch. Natürlich sind mir die Daten wichtig und deshalb habe ich auch ein Backup, aber warum soll ich unnötig Zeit aufwenden und aus ein Backup ohne Not wiederherstellen? Soo wichtig ist APFS vielleicht auch nicht, wie man das hier so liest.
„wyrd bið ful aræd“
0
Lupolino12.01.1807:41
hatte am MBAir auch HS ohne APFS (nach Restore)
habe HS aus dem AppleStore neu geladen und "drüberinstalliert".
Dabei wurde automatisch auf APFS konvertiert.
Gefühlt läuft das MBAir jetzt geschmeidiger.
+1
elBohu
elBohu12.01.1808:26
Na, das wäre ja noch einen Versuch wert. Danke!
„wyrd bið ful aræd“
0
herwighenseler
herwighenseler12.01.1808:38
bmonno
Bei einem 1,3 GB großen Bild mit minimalen Änderungen hatte ich erwartet, dass beim Sichern APFS schneller als HFS+ ist

Wenn Du in einer Bildbearbeitung an einem Bild auch nur einen einzigen Pixel änderst, musst Du immer das gesamte Bild neu speichern - also die gesamte Datei neu schreiben. Da spielt das Dateisystem keine Rolle.

Herwig
„Life is a heuristic guided depth-first search without backtracking“
+1
McHep
McHep12.01.1810:00
herwighenseler
bmonno
Bei einem 1,3 GB großen Bild mit minimalen Änderungen hatte ich erwartet, dass beim Sichern APFS schneller als HFS+ ist

Wenn Du in einer Bildbearbeitung an einem Bild auch nur einen einzigen Pixel änderst, musst Du immer das gesamte Bild neu speichern - also die gesamte Datei neu schreiben. Da spielt das Dateisystem keine Rolle.

Herwig
Sorry, diese Aussage ist ein Witz. Jedes halbwegs vernünftige Bildbearbeitungsprogramm würde bei der Änderung von einem Pixel niemals die gesamt Datei neu schreiben. Sondern lediglich genau den Teil, der geändert wurde. Man nennt das auch Delta encoding oder data differencing
-1
MikeMuc12.01.1810:24
McHep
Nenne mir auch nur ein Programm was sich die Mühe macht. Ich halte deine Aussage für Quark auch wenn sie aus der Sicht einer SSD oder Festplatte optimal wäre um Schreiboperationen zu vermeiden. So ein Aufwand wird nur bei extremer Performance und riesigen Datenmengen betrieben
+1
bmonno12.01.1810:38
McHep
Sorry. Glauben heißt nicht Wissen! Ich habe ein großes Bild mit AffinityPhoto geladen, die Ebene dupliziert und Ergebnis gespeichert (1,3 GB). Dann in einer Ebene Pixel wegradiert und gesichert. In beiden Installationen (High Sierra einmal mit APFS, einmal mit HFS+) dauerte das Speichern 3 s.
Ich hatte erwartet, dass APFS selbst erkennt, dass sich kaum etwas geändert hat, und die Speicherung deutlich <1s erfolgt. Dem scheint nicht so zu sein oder das Vergleichen dauert so lange wie das Speichern unter HFS+.

Bevor du solche Mutmaßungen machst, solltest du es vielleicht mal selbst testen! Oder verrate uns die Programme, die das tun, was du sagst. Nochmal: Glauben heißt nicht Wissen!
+1
herwighenseler
herwighenseler12.01.1812:39
bmonno
Ich hatte erwartet, dass APFS selbst erkennt, dass sich kaum etwas geändert hat, und die Speicherung deutlich <1s erfolgt.

Wie soll das funktionieren? Eine Anwendung schreibt x Bytes, das OS bildet daraus Blöcke und schreibt sie, fertig.

Selbst wenn die Datei überschrieben werden würde (das müsste die Anwendung dann aber entsprechend tun und keine zweite Datei schreiben und erstere Löschen), müsste das OS ja erst einen Block lesen um zu erkennen, dass er gerade versucht das gleiche zu schreiben wie bereits vorhanden ist. Trifft dies zu, könnte man auf den Schreibvorgang verzichten und etwas Zeit sparen. Trifft es nicht zu, hätte man einen zusätzlichen Lesevorgang und Schreiben wäre sogar langsamer.

Ja, mit viel Glück wäre der Block noch im Buffercache des OS - in dem Fall würde man profitieren. Das könnte man dann aber auch in HFS+ implementieren und bräuchte nicht APFS.

Herwig
„Life is a heuristic guided depth-first search without backtracking“
+2
bmonno12.01.1814:08
herwighenseler
Es soll ja Datei-Systeme geben (APFS gehört derzeit wohl nicht dazu), die das beherrschen. ZFS kann sogar Deduplikation. Im Bereich Snapshot ist doch eigentlich alles dafür vorhanden: Bei Öffnen eines Dokumentes werden alle dafür gebrauchten Blöcke gesperrt, beim Sichern finden findet ein Vergleich auf Blockebene statt und nur die geänderten geschrieben. Oder verstehe ich da Snapshot falsch?
-1
herwighenseler
herwighenseler12.01.1815:15
bmonno

Deduplikation heisst, bei jedem Schreibvorgang wird geprüft, ob der Blockinhalt schon irgendwo auf der Platte vorliegt - möglicherweise auch in einer ganz andere Datei. Das benötigt aber Unmengen an Hauptspeicher, da von allen Blöcken ein Hashwert vorliegen muss - im Hauptspeicher. Auch auf einem fetten Server schaltet man dieses Feature nicht mal einfach so an.

APFS kann (noch) kein Deduplication.

Snapshots sind wieder ein ganz anderes Feature Die Blöcke werden nicht gesperrt, sondern mit einem copy-on-write-Flag versehen (in den Metadaten). Beim Überschreiben der Datei werden die vorhandenen Blöcke nicht überschrieben, sondern in jedem Fall neue Blöcke verwendet, damit der alte Inhalt über den Snapshot noch erreichbar ist.

Herwig
„Life is a heuristic guided depth-first search without backtracking“
+1
bmonno12.01.1821:15
.>herwighenseler
Und wie und unter welchen Voraussetzungen funktioniert dann das uns vollmundig auf der WWDC angepriesene Copy on Write? Das Duplizieren im Finder oder woanders kann ja wohl nicht gemeint sein.
herwighenseler
bmonno

Deduplikation heisst, bei jedem Schreibvorgang wird geprüft, ob der Blockinhalt schon irgendwo auf der Platte vorliegt - möglicherweise auch in einer ganz andere Datei. Das benötigt aber Unmengen an Hauptspeicher, da von allen Blöcken ein Hashwert vorliegen muss - im Hauptspeicher. Auch auf einem fetten Server schaltet man dieses Feature nicht mal einfach so an.

APFS kann (noch) kein Deduplication.

Snapshots sind wieder ein ganz anderes Feature Die Blöcke werden nicht gesperrt, sondern mit einem copy-on-write-Flag versehen (in den Metadaten). Beim Überschreiben der Datei werden die vorhandenen Blöcke nicht überschrieben, sondern in jedem Fall neue Blöcke verwendet, damit der alte Inhalt über den Snapshot noch erreichbar ist.

Herwig
-2
MikeMuc12.01.1823:02
bmonno
Und wie und unter welchen Voraussetzungen funktioniert dann das uns vollmundig auf der WWDC angepriesene Copy on Write? Das Duplizieren im Finder oder woanders kann ja wohl nicht gemeint sein.
Doch, genau das. Und sonst nix. So ungefähr
+2
McHep
McHep13.01.1809:44
bmonno
McHep
Sorry. Glauben heißt nicht Wissen! Ich habe ein großes Bild mit AffinityPhoto geladen, die Ebene dupliziert und Ergebnis gespeichert (1,3 GB). Dann in einer Ebene Pixel wegradiert und gesichert. In beiden Installationen (High Sierra einmal mit APFS, einmal mit HFS+) dauerte das Speichern 3 s.
Ich hatte erwartet, dass APFS selbst erkennt, dass sich kaum etwas geändert hat, und die Speicherung deutlich <1s erfolgt. Dem scheint nicht so zu sein oder das Vergleichen dauert so lange wie das Speichern unter HFS+.

Bevor du solche Mutmaßungen machst, solltest du es vielleicht mal selbst testen! Oder verrate uns die Programme, die das tun, was du sagst. Nochmal: Glauben heißt nicht Wissen!
Was hat APFS bzw. Apple damit zu tun, dass AffinityPhoto sich nicht die Mühe macht, nur die Änderungen zu speichern? Darüber hinaus kommt es immer noch darauf an, was man für ein Bildformat verwendet. Eins mit oder eben eins ohne Kompromierung. Logischerweise muss bei einer kompromierten Fassung diese neu berechnet werden, hingegen bei einer unkomprimierten eben nicht. Und ich stelle keine Mutmaßungen an, sondern sage, dass eine gute Bildbearbeitung auch so handhabt. Das hat nichts mit Glauben zu tun, sondern mit Wissen, dass es technisch möglich ist!
0
herwighenseler
herwighenseler13.01.1810:03
McHep
Logischerweise muss bei einer kompromierten Fassung diese neu berechnet werden, hingegen bei einer unkomprimierten eben nicht.

Ja, das wäre möglich. Hat nur leider überhaupt nichts mit dem Thema hier zu tun, wir reden nämlich über APFS und nicht darüber, ob bei einer Änderung eines Bytes die gesamte Datei neu geschrieben werden muss oder nicht. Einzelne Werte einer existierenden Datei zu verändern, indem man nur den jeweiligen Block neu schreibt geht auch mit HFS+ schon immer.

Herwig
„Life is a heuristic guided depth-first search without backtracking“
0
bmonno13.01.1811:43
Danke, dann habe ich mit das Falsche vorgestellt. Irgendwie habe ich auch ein Video in Erinnerung, wo was anderes suggeriert wurde. Marketing!
Dann werde ich halt warten, bis APFS erwachsen ist.
MikeMuc
bmonno
Und wie und unter welchen Voraussetzungen funktioniert dann das uns vollmundig auf der WWDC angepriesene Copy on Write? Das Duplizieren im Finder oder woanders kann ja wohl nicht gemeint sein.
Doch, genau das. Und sonst nix. So ungefähr
+1

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.