APFS muss sein?

Wenn der Rest dir nicht reicht...

Zumal gehe ich davon aus, dass das nächste macOS sich nicht mehr auf HFS installieren lassen wird. Es bekommt also eh jeder.
 
Olivetti schrieb:
bisher war's halt NFD, während der rest NFC verwendet. mir ist das jetzt mit APFS so lieber, somit kann man auf NFC umschwenken (weniger cloudprobleme). IMHO ist letzteres eh' einer der gründe das so einzuführen (bzw. wegzulassen :p )..
Zum Vergrößern anklicken....
Gibt es ein Argument, daß Apple nicht lieber doch NFC implementiert hat? Wie halten es die anderen Dateisysteme? Überlassen die es der SW oder implementieren die das selbst?
 
spatiumhominem schrieb:
Wenn der Rest dir nicht reicht...

Zumal gehe ich davon aus, dass das nächste macOS sich nicht mehr auf HFS installieren lassen wird. Es bekommt also eh jeder.
Zum Vergrößern anklicken....
Bei der Standard-Installation kannst du es nicht verhindern. Du könntest aber den Installationsvorgang via Shell starten und dem Starter eine Option mitgeben, daß es das Dateisystem nicht konvertieren soll. Wenn ich es wiederfinde, kann ich das ja noch mal schreiben.

Ansonsten kannst du eine OSX-Installation auf ein HFS+-Medium klonen, z.B. mit Carbon Copy Cloner.

Wie lange das aber noch geht… keine Ahnung. Apple käst sich ja leider nicht aus. Wäre ja schlimm, wenn Admins zuviel Planungssicherheit hätten… :)
 
  • Gefällt mir
Reaktionen: dg2rbf und Schiffversenker
agrajag schrieb:
Gibt es ein Argument, daß Apple nicht lieber doch NFC implementiert hat? Wie halten es die anderen Dateisysteme? Überlassen die es der SW oder implementieren die das selbst?
Zum Vergrößern anklicken....
die erste frage verstehe ich nicht wirklich, apple hat sich einfach mal anpassen müssen. ansonsten sind die üblichen verbreiteten file systeme oder datenbanken meist normalisierungs-agnostisch, wie jetzt auch APFS. i.d.R. wird NFC in SW verwendet, d.h. diesbzgl. konvertierungen/anpassungen können entfallen, fehler treten gar nicht erst auf.
 
Also, wenn ich dich richtig verstanden habe: andere Dateisysteme, "die wo" nicht HFS+ sind, normalisieren gar nicht und alle SW benutzt per Konvention NFC.

Agnostisch an sich finde ich ja prinzipiell gut. Nur bei Dateinamen hoffe ich dann doch, daß sich da alle einigen…
 
1. ja.
2. einig war man sich ja bisher auch nicht (apple vs. rest). solange alle unicode verwenden, siehst du nachwievor ein Ü. :p
 
Ich sehe das recht pragmatisch. Wenn Apple oder andere Hersteller auf iMac erste Funktionen zur Verfügung stellen die ich haben/nutzen möchte und APFS erfordern werde ich es nutzen/installieren. Bis es so weit ist beobachte ich entspannt die Entwicklung.
 
spatiumhominem schrieb:
Das tut mir aufrichtig leid :hehehe:
Zum Vergrößern anklicken....
Muß nicht, ich habe mich, obwohl seit den Achtzigern von Apple träumend und seit Mitte der Neunziger auch mit Apple arbeitend, bewusst gegen die iOS-Dinger entschieden. Kein einsehbares Dateisystem, dafür der Zwang, mit jeder Aktualisierung auch den Rechner anpassen zu müssen, einschließlich einem iTunes-Update - und iTunes wurde mit jeder Version schrecklicher (und ich will es für Musik benutzen, nicht als Sync-Programm).
Wer damit leben mag, hat natürlich eine perfekte Integration.
 
Für wohl die meisten Nutzer macht es kaum einen Unterschied, ob HFS+ oder APFS, ich benutze es seit der frühen Beta-Phase von High Sierra und seit dem auch in der Case-sensitive-Variante. Es gibt noch Anwendungen die wegen der nervigen Unicode-Normalisierung ärger machen, aber das wird sich auch irgendwann ändern. FileVault funktioniert natürlich einfacher auf APFS, genau wie Local TimeMachine, weil das System einfach nur regelmäßig einen Snapshot vom Dateisystem macht, kopiert wird da nichts.
 
  • Gefällt mir
Reaktionen: spatiumhominem
Ich bin auf HFS+ zurück, u.a. weil Counting von Objektgrößen bei mir so gar nicht funktionieren wollte, bzw. ich ewig auf das Ergebnis warten sollte. Dabei war das Versprechen doch deutlich bessere Counting-Geschwindigkeit.
 
  • Gefällt mir
Reaktionen: Carmageddon
Na ja, also das Designziel von einem CoW Dateisystem ist nicht unbedingt Performance. BtrFS ist langsamer als XFS, ZFS vermute ich auch. Die schleppen ja auch viel mehr Metadaten mit sich rum, und CoW ist schon vom Design her anders/langsamer als das inplace ersetzen wie es die alten Dateisysteme machen.

Ich frag mich ja echt wieso die bei APFS keine Checksummen eingebaut haben, und wieso es ein fsck_apfs gibt. Vielleicht weil Checksummen eher Sinn ergeben bei RAID (mind. 2 Platten), und Apple sich da nicht so sieht ("Server"-Markt, Eher Consumer)?

Na ja, mal abwarten. Vielleicht kommt das ja noch und kann man das bei APFS nachträglich in die Metadaten packen ohne das man das Dateisystem neuschreiben muss.

Frag mich was mit Windows passiert. ReFS ist ja eher nicht für den Desktop entwickelt.
 
agrajag schrieb:
Schau mal, wie lange ZFS gebraucht hatte, bis es mal größer ausgerollt wurde. Das hat fast 10 Jahre gedauert, bis es als abgehangen genug galt, daß man es getrost einsetzen kann. "Die Linuxer" sind da immer noch nicht überzeugt von Linux-Implementation, wobei Canonical mit Ubuntu wohl eine Ausnahme sind.
Zum Vergrößern anklicken....
Das war anders. ZFS wurde gar nicht für Linux entwickelt, sondern für Solaris. Auf Grund unterschiedlicher Lizenzen war es daher rechtlich schon immer fraglich, ob man ZFS in Linux einbauen darf. Und nach 10 Jahren sagt Canonical einfach: ja.

Im Grunde hast Du aber recht, ein neues Dateisystem birgt viele Risiken. Microsoft wollte auch mal einen Nachfolger von NTFS einführen, hat's dann aber gelassen. In der Linux-Welt treffen Deine Argumente auf brfs zu.
 
thorstenhirsch schrieb:
Das war anders. ZFS wurde gar nicht für Linux entwickelt, sondern für Solaris. Auf Grund unterschiedlicher Lizenzen war es daher rechtlich schon immer fraglich, ob man ZFS in Linux einbauen darf. Und nach 10 Jahren sagt Canonical einfach: ja.

Im Grunde hast Du aber recht, ein neues Dateisystem birgt viele Risiken. Microsoft wollte auch mal einen Nachfolger von NTFS einführen, hat's dann aber gelassen. In der Linux-Welt treffen Deine Argumente auf brfs zu.
Zum Vergrößern anklicken....
ZFS braucht sehr viel Memory. Ich denke das es deshalb gescheitert ist, weil die Smartphones von damals nur n paar MB hatten. Und ich glaube nicht, dass Apple sich mit verschiedenen Dateisystemen rumschlagen wollte. Klar, das rechtliche sicher auch, aber die hatten es ja schon portiert. Würde man das machen bei rechtlichen Komplikationen?

Nachfolger von NTFS kommt sicher noch. ReFS gibts ja schon. Und das WinFS mit der eingebauten Datenbank hat heutzutage einfach keinen Einsatzzweck mehr. Irgendwo gibts im Internet einen Blogpost von einem damaligen Windowsmanager der die Vistaentwicklung mitgemacht hat. Der erklärt wieso das nie rauskam. Das lag eher an dem Prozess den die damals hatten. 3 Monate Entwicklungszeit, 2 Jahre debuggen. Da war kein Platz für ein Dateisystem.

Edit: Habs gefunden: https://blog.usejournal.com/what-really-happened-with-vista-an-insiders-retrospective-f713ee77c239
Ist lesenswert!
 
xentric schrieb:
ReFS gibts ja schon.
Zum Vergrößern anklicken....

Jepp, nur würde ich da im Moment noch Abstand von nehmen... selbst in den Datev-Installationshilfen für Server 2016 wird explizit davon abgeraten. Mal sehen, wie sich APFS längerfristig in der Praxis schlägt. Im Moment kommt es für mich eh noch nicht in Frage, da ich derzeit noch auf El Capitan unterwegs bin.
 
xentric schrieb:
Ich frag mich ja echt wieso die bei APFS keine Checksummen eingebaut haben, und wieso es ein fsck_apfs gibt. Vielleicht weil Checksummen eher Sinn ergeben bei RAID (mind. 2 Platten), und Apple sich da nicht so sieht ("Server"-Markt, Eher Consumer)?
Zum Vergrößern anklicken....
Der ZFS Typ, der hier schon verlinkt wurde, vermutet ob man damit in Zukunft vielleicht mal Integrität der Dateien prüfen kann. Reparatur ist aber mit APFS nicht möglich und solch eine manuelle Prüfung wäre auch für den Anwender relativ sinnlos, da man die (unbemerkt korrumpierten) Dateien ja fröhlich backuped und korrekte Versionen überschreibt.
 
agrajag schrieb:
Bei der Standard-Installation kannst du es nicht verhindern. Du könntest aber den Installationsvorgang via Shell starten und dem Starter eine Option mitgeben, daß es das Dateisystem nicht konvertieren soll. Wenn ich es wiederfinde, kann ich das ja noch mal schreiben.
Zum Vergrößern anklicken....

Ich habe erfolgreich nach dieser Anleitung einen Clean Install von High Sierra von USB-Stick auf meine interne SSD durchgeführt:

https://malcont.net/2017/09/how-to-...sierra-without-filesystem-change-hfs-to-apfs/

Ich hatte HS vorher schon mit APFS drauf, aber nachdem der Rechner einmal eingefroren war und danach kein BS mehr auf der SSD erkannt hat, habe ich HS lieber ohne APFS neu installiert. Die Recovery konnte ich noch starten, aber die macOS-Partition ließ sich nicht reparieren.
 
Semi-OT: Ich hatte eben mein erstes Problem mit APFS, und zwar hatte ich hier einen neuen-alten iMac von 2012 auf dem macOS High Sierra installiert war und den ich mit einem macOS Sierra Clean-Install neu aufsetzen wollte. Vom USB-Stick gebootet und im FPDP angekommen, bin ich aber nicht weitergekommen, denn das FPDP verweigert das Löschen/Formatieren des Laufwerks (aktuell APFS), um es für Sierra mit GUID/HFS+ auszurüsten.
Erfolgreicher Work-Around: Windows 10 Install-Stick an den Mac angeschlossen, Setup gestartet und die SSD mit Windows, ja, ihr lest richtig, formatiert, danach hat alles geklappt. - Ich musste den Kopf schütteln und lachen.
 
@Elebato: genau, diesen Weg meinte ich. :)

@iPhill: Der Trick ist, zuerst den Container der OSX-Installation zu löschen. Danach kannst du das gesamte Laufwerk neu partitionieren. Keine Ahnung was da schief läuft. Das FDP ist halt so mäh. Ich kann seit 1-2 Jahren nur selten ein Medium auf anhieb neu formatieren. Zuerst kommt in 90% aller Fälle der Abbruch mit "konnte nicht ausgeworfen werden. Witzigerweise wurde es aber fast immer ausgeworfen. Im zweiten Anlauf klappt es dann. Klingt nach einem Timing-Problem.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten