Bereiche
News
Rewind
Tipps & Berichte
Forum
Galerie
Journals
Events
Umfragen
Themenwoche
Kleinanzeigen
Interaktiv
Anmelden
Registrierung
Zu allen empfangenen Nachrichten
Suche...
Zur erweiterten Suche
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?
kay1
11.01.18
13: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!
Hilfreich?
0
Kommentare
elBohu
11.01.18
13: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“
Hilfreich?
0
rene204
11.01.18
13: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...“
Hilfreich?
+1
elBohu
11.01.18
14: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“
Hilfreich?
0
MikeMuc
11.01.18
14:42
Ist doch egal wenn die Daten Hops gehen, aus dem Grund hast du doch vorher ein Backup gemacht
Hilfreich?
+2
elBohu
11.01.18
14:53
Jaja... kostet aber Zeit. Vielleicht ist apfs doch nicht so wie wichtig.
„wyrd bið ful aræd“
Hilfreich?
-3
kay1
11.01.18
19: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 ...
Hilfreich?
0
kawi
11.01.18
19: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
Hilfreich?
+2
bmonno
11.01.18
20: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!
Hilfreich?
0
kay1
11.01.18
23: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.
Hilfreich?
0
bmonno
12.01.18
03: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.
Hilfreich?
0
elBohu
12.01.18
07: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“
Hilfreich?
0
Lupolino
12.01.18
07: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.
Hilfreich?
+1
elBohu
12.01.18
08:26
Na, das wäre ja noch einen Versuch wert. Danke!
„wyrd bið ful aræd“
Hilfreich?
0
herwighenseler
12.01.18
08: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“
Hilfreich?
+1
McHep
12.01.18
10: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
Hilfreich?
-1
MikeMuc
12.01.18
10: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
Hilfreich?
+1
bmonno
12.01.18
10: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!
Hilfreich?
+1
herwighenseler
12.01.18
12: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“
Hilfreich?
+2
bmonno
12.01.18
14: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?
Hilfreich?
-1
herwighenseler
12.01.18
15: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“
Hilfreich?
+1
bmonno
12.01.18
21: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
Hilfreich?
-2
MikeMuc
12.01.18
23: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
Hilfreich?
+2
McHep
13.01.18
09: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!
Hilfreich?
0
herwighenseler
13.01.18
10: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“
Hilfreich?
0
bmonno
13.01.18
11: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
Hilfreich?
+1
Kommentieren
Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.
iPhone 17 Pro: Leaks sollen Details zur neuen R...
Vor 40 Jahren: Der Apple Laser Writer wird ange...
MacStammbaum 11 und MobileFamilyTree 11 sind er...
2 TByte für 259 US-Dollar: Erste Upgrade-SSDs f...
Countdown 2024: Apple mit Preisnachlass für 31 ...
Apple plant Umstellungen bei "AppleCare+" – weg...
Mac-Wartung: Alte Kernel-Erweiterungen entfernen
Kurz: Trump unterstützt Musk als TikTok-Besitze...