Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Apples neues Dateisystem APFS: Entwickler kritisiert unzureichende Dokumentation

Was für iPhones und iPads schon seit iOS 10.3 standardmäßig zur Verfügung steht, schaffte mit macOS High Sierra (10.13) im Herbst 2017 auch den Sprung auf den Mac: Apples neues Dateisystem APFS. Die Softwareschmiede Coriolis Systems macht APFS jetzt maßgeblich für die baldige Einstellung der zwei hauseigenen Apps iDefrag and iPartition verantwortlich. Genauer gesagt geht es dem Entwickler um die seiner Meinung nach mangelhafte Dokumentation, die Apple zum Dateisystem liefert.


Software-Anpassung für APFS würde zu lange dauern
Coriolis Systems zeigt sich im Blogeintrag bezüglich des Endes von iDefrag and iPartition enttäuscht über Apples Veröffentlichungsstrategie bei APFS. Es sei verwunderlich, dass das Unternehmen ein neues Dateisystem auf den Markt bringt und Systempartitionen auf SSDs standardmäßig zu APFS konvertiert, ohne zuerst die entsprechenden Spezifikationen zu veröffentlichen. Auch Monate nach dem Marktstart von High Sierra fehle es an nötigen Informationen für Drittanbieter. Deswegen könne nicht exakt prognostiziert werden, wie lange eine Anpassung von iDefrag and iPartition an APFS dauern würde. Mit einem halben Jahr Entwicklungszeit sei mindestens zu rechnen.

Da die beiden Anwendungen in der Zwischenzeit für High-Sierra-Macs die Hauptfunktionalität verlieren und sich schon diverse Käufer der Apps über besagten Umstand beschwerten, zieht Coriolis Systems jetzt die Notbremse. Auch die gestiegenen Schutzvorrichtungen in macOS High Sierra sieht der Entwickler zwar als Vorteil für Endkunden, aber als hohe Hürde für App-Anbieter, deren Programme tief ins System eingreifen. Funktionen wie der direkte Zugriff auf das Boot-Laufwerk und der Reboot-and-Defragment-Mode werden seit der aktuellen macOS-Version von den Coriolis-Systems-Lösungen nicht mehr unterstützt.

Früher habe Apple noch enger mit Drittanbietern zusammengearbeitet, wenn es um Funktionsmöglichkeiten für zum Beispiel Kernelerweiterungen gegangen sei, so der Entwickler. Bei den jüngsten Schutzvorrichtungen wie der Abschottung des Recovery-Partition-Images sei Apple aber nicht mehr so kooperativ auf Entwickler zugekommen wie früher.

Die Konsequenz: iDefrag and iPartition werden nicht mehr weiterentwickelt. Die beiden Apps sind vorerst noch zu einem reduzierten Preis verfügbar. Coriolis empfiehlt die Programme explizit nur für macOS-Installationen ohne APFS.

Kommentare

ThorsProvoni
ThorsProvoni23.02.18 16:09
Kein Verlust - nichts, was man nicht auch mit Bordmitteln erledigen kann (iPartition) oder wo der Nutzen sowieso eher zweifelhaft ist (iDefrag).
+2
Memmnarch23.02.18 17:08
Ich hab hier Sierra installiert. MacOS X 10.13 ist eh eine totale Katastrophe. Mein Mac mit Fusion Drive wird von Apple nicht richtig unterstützt, da brauch ich auch kein neues BS. Von daher sind die Preise für die Programme hier schon interessant.
+4
Marcel_75@work
Marcel_75@work23.02.18 17:55
Leider hat dieser Entwickler nicht unrecht – die Spezifikationen für APFS sind nach wie vor nicht komplett veröffentlicht, auch andere ehemalige Platzhirsche, wie z.B. das bei HFS/HFS+/HFS+ Journaled extrem zuverlässige „DiskWarrior“ von Alsoft, sind bisher nicht APFS-ready … 🤔😔
+16
larsvonhier23.02.18 18:27
Hatte mal vor Jahren iDefrag gekauft beim Entwickler, und zwar nur wegen einer nachträglichen Installation einer Bootcamp Partition auf einer schon gut gefüllten Platte. Dann noch einmal auf einem weiteren Rechner benutzt, sofort kam übelstes Gemecker von Coriolis, was mir einfiele, eine Lizenz auf zwei Computern zu nutzen... Habe meine Meinung dazu erwidert, danach war die Lizenz auf beiden Rechnern und für Neuinstallationen gesperrt. Soviel zum Geschäftsgebaren des Herren dort. Hab's nie wieder gebraucht, und nicht vermisst. Mit Bordmitteln geht das auch alles bzw. das alte NTFS/Win-XP-Defragmentierungsgewurschtel ist mit HFS+ sowieso für die Katz' und bei SSDs sogar lebensdauerverkürzend.
+10
Hannes Gnad
Hannes Gnad23.02.18 18:54
Memmnarch
Ich hab hier Sierra installiert. MacOS X 10.13 ist eh eine totale Katastrophe.
Bestes macOS = Aktuelles macOS - 0.1 und 10.6.8, 4evär!
Schlimmstes macOS = Aktuelles macOS

Gilt anscheinend immer noch.
+4
rosss23.02.18 19:52
Hannes Gnad
Bestes macOS = Aktuelles macOS - 0.1

Kann nicht sein. Sierra hat zu viele sichtbare Bugs, das fällt auf beim arbeiten.
Hannes Gnad
und 10.6.8, 4evär!

Rosetta war der Hammer!

Alle Features die danach kamen, fand ich entbehrlich, im besten Falle nice2have – wenn sie denn funktionieren.

Ja, ja. Ich weiß. Ewiggestriger. Aber ich verdiene mein Geld mit dem Mac, da brauche ich ein gutes Werkzeug. 10.4 – 10.6 – 10.9 waren die problemlosesten Systeme. Aus Sicherheitsgründen nutze ich aktuell 10.12 – aber die Bugs vermitteln mir eben kein Gefühl von Sicherheit.

Ein gutes Werkzeug lenkt nicht ab, man nutzt es unbewusst.
-2
Kobayjashi
Kobayjashi23.02.18 19:59
MBP 13" TB 2016
Ich hab 0(null) Probleme mit 10.13.x , heute das zwischen Update eingespielt.
Alles wie immer!
Aber aus meiner Support Tätigkeit kann ich schon von x fehlgeschlagenen 10.13 Installationen berichten.... meinst war leider der USER schuld der den Prozess auf Grund geht nicht schnell genug oder was macht der Mac .... einfach beendet / den Mac per Einschalttaste aus gemacht hat !!!!
Das sind dann die, die OHNE TM Backup dann vor mir stehen und heulen !!!!!
0
ratti
ratti23.02.18 20:24
ThorsProvoni
Nutzen sowieso eher zweifelhaft ist (iDefrag).

Vorweg: Ich kenne das Tool nicht. Grundsätzlich ist es aber ein weit verbreiteter Irrglaube, man bräuchte solche Tools generell nicht.

Früher waren Dateisysteme ziemlich dumme Dinger, die Daten linear runtergeschrieben haben. Für Systeme wie FAT16 war die regelmässige Defragmentierung daher Pflicht.

Moderne Dateisysteme sind mit Fragmentierung im Hinterkopf entwickelt. Sie lassen Dateien Platz zum wachsen, nutzen nicht die erste kleine Lücke zum Schreiben usw. usf.

Trotzdem gibt es immer noch Systeme, die einen besonderen Datenbestand haben. Das könnte zum Beispiel ein Mailserver sein, der Millionen kleine Maildateien hat. Oder ein Archiv mit Millionen animierten GIF-Bildchen. Eine Fontsammlung. Ein Datenbankserver mit wenigen, aber riesigen Dateien.

Hier macht es tatsächlich Sinn, auch mal umzusortieren.
-3
Marcel Bresink23.02.18 20:50
ratti
Grundsätzlich ist es aber ein weit verbreiteter Irrglaube, man bräuchte solche Tools generell nicht.

Nein, das ist kein Irrglaube, dann Apple hat ab Mac OS X 10.3, also bereits vor 15 Jahren, automatische Defragmentierung ins Betriebssystem eingebaut.
ratti
Hier macht es tatsächlich Sinn, auch mal umzusortieren.

Zusätzlich zur Defragmentierung findet seit 10.3 auch eine automatische Umsortierung oft genutzter Dateien vollautomatisch statt. Diese Funktion wird von Apple "Hot Adaptive File Clustering" genannt.
+11
sierkb23.02.18 21:08
Marcel Bresink
Nein, das ist kein Irrglaube, dann Apple hat ab Mac OS X 10.3, also bereits vor 15 Jahren, automatische Defragmentierung ins Betriebssystem eingebaut.

Die aber, wenn ich Amit Singh richtig verstehe, ihre engen Grenzen hat und an bestimmte Bedingungen geknüpft ist (z.B. nur Dateien kleiner 20MB oder 10MB – z.B. so manche Medien-Datei von heute (Audio, Video etc.) ist heutzutage um Einiges größer als lediglich 10 oder 20MB) – sind die alle Bedingungen geichzeitig erfüllt, wird automatisch defragmentiert, sind sie nicht alle gleichzeitig erfüllt, wird nicht automatisch defragmentiert (es summieren sich also durchaus dann Daten-Fragmente auf):
While Apple does not provide a defragmentation tool, they introduced a few HFS+ optimizations in "Panther", two of which play important roles in countering (even undoing) the fragmentation of files that are below a certain size, and are frequently accessed.

On-the-fly Defragmentation

When a file is opened on an HFS+ volume, the following conditions are tested:
  • If the file is less than 20 MB in size
  • If the file is not already busy
  • If the file is not read-only
  • If the file has more than eight extents
  • If the system has been up for at least three minutes

If all of the above conditions are satisfied, the file is relocated -- it is defragmented on-the-fly.
Quelle: Amit Singh (2004): Fragmentation in HFS Plus Volumes
Marcel Bresink
Zusätzlich zur Defragmentierung findet seit 10.3 auch eine automatische Umsortierung oft genutzter Dateien vollautomatisch statt. Diese Funktion wird von Apple "Hot Adaptive File Clustering" genannt.

Auch hier offenbar wieder nur begrenzt:
Amit Singh
Hot File Clustering

This optimization is currently available only on boot volumes. Hot File Clustering is a multi-staged clustering scheme that records "hot" files (except journal files, and ideally quota files) on a volume, and moves them to the "hot space" on the volume (0.5% of the total filesystem size located at the end of the default metadata zone, which itself is at the start of the volume). The files are also defragmented. The various stages in this scheme are DISABLED, IDLE, BUSY, RECORDING, EVALUATION, EVICTION, and ADOPTION. At most 5000 files, and only files less than 10 MB in size are "adopted" under this scheme.
Quelle: Amit Singh (2004): Fragmentation in HFS Plus Volumes

Oder hat Amit Singh Unwahres veröffentlicht oder ist das irgendwie anders zu verstehen als dort steht?

Zudem: nach allem, was man lesen kann: auch SSDs fragmentieren und können dadurch an Performance und Lebensdauer einbüßen.
+3
sierkb23.02.18 21:45
Michael Tsai (22.02.2018): iDefrag and iPartition Discontinued ;
zudem seine beiden Kommentare darunter und .
+2
MacTaipan23.02.18 22:39
ThorsProvoni
Kein Verlust - nichts, was man nicht auch mit Bordmitteln erledigen kann (iPartition) oder wo der Nutzen sowieso eher zweifelhaft ist (iDefrag).

Ich hatte einen Anwendungsfall für iPartition: Eine Bootcamp-Partition zu erzeugen, die nicht am Beginn der Platte liegt, habe ich mit Bordmitteln nicht hinbekommen. Wahrscheinlich geht es auch mit diskutil im Terminal irgendwie, aber das hätte mehr Einarbeitungszeit gebraucht, als ich zu investieren bereit war (und ich bin Informatiker und Mac-User seit System 7 und in solchen Dingen nicht unbedarft).
-1
sierkb23.02.18 22:58
Was die bisher unzureichende bzw. fehlende Dokumentation zu APFS angeht, hier ein Kommentar unlängst von Thomas Tempelmann:
Thomas Tempelmann, heise Forum, 07.12.2017
heise Forum-Nutzer
Ohne eine Offenlegung der Informationen über das Dateisystem APFS wäre das Tool von Tempelmann nicht möglich gewesen.

Das stimmt so nicht. Meine Arbeit, und auch die der anderen Lösungen, ist auf Reverse-Engineering basiert, denn Apple hat bisher nichts zum APFS-Format dokumentiert. (Die Hauptarbeit stammt von Jonas Plum, später habe ich dann auch noch Einiges beigetragen: https://github.com/cugu/apfs.ksy).

Apple hat schon immer ihre Dateisysteme dokumentiert. Apple hat auch angekündigt, daß das irgendwann für APFS passieren soll. Ich vermute, es ist noch nicht geschehen, weil die 2 Entwickler, die sich bei Apple mit APFS auskennen, noch so sehr mit der Weiterentwicklung beschäftigt sind, daß sie noch keine Zeit für die Doku hatten. Prioritäten, halt.
Quelle: heise (07.12.2017): Tool erlaubt Einlesen von APFS-Volumes unter Windows und älteren Macs
Biskus APFS Capture kann Apples neues Dateiformat für Analysen und zum Kopieren von Dateien erfassen – auch auf Rechnern, die es nicht unterstützen. Billig ist das nicht.
+8
sierkb23.02.18 23:02
BTW: ebenso interessant zu lesen zum aktuellen Stand der Dinge von APFS auf SSDs und auch HDDs bzw. Fusion Drives:

eclecticlight.co (17.02.2018): Is APFS fully supported yet?
+1
Nebu2k24.02.18 00:00
Programme [die] tief ins System eingreifen.
gehören sowie so verboten!
+1
Mammutherde24.02.18 09:06
ratti
Früher waren Dateisysteme ziemlich dumme Dinger,
Ja.
Für Systeme wie FAT16 war die regelmässige Defragmentierung daher Pflicht.
Nein, nur extrem selten.
Moderne Dateisysteme sind mit Fragmentierung im Hinterkopf entwickelt. Sie lassen Dateien Platz zum wachsen, nutzen nicht die erste kleine Lücke zum Schreiben usw. usf.
Moderne Betriebssysteme puffern mit viel RAM Dateizugriffe. Der langsame Zugriff auf die Platte, weil der Kopf ständig bewegt werden muss, ist damit irrelevant.
Das könnte zum Beispiel ein Mailserver sein, der Millionen kleine Maildateien hat.
Nein, siehe Puffer.
Oder ein Archiv mit Millionen animierten GIF-Bildchen.
Nein. Fragmentierung entsteht durch ständiges Löschen und Neuschreiben oder durch Erweiterung bestehender Dateien. Das ist hier nicht gegeben.
Eine Fontsammlung.
Nein. Fragmentierung entsteht durch ständiges Löschen und Neuschreiben oder durch Erweiterung bestehender Dateien. Das ist hier nicht gegeben.
Ein Datenbankserver mit wenigen, aber riesigen Dateien.
Nein. DB-Server beherrschen den optimalen Zugriff schon deutlich länger als Betriebssysteme.
Hier macht es tatsächlich Sinn, auch mal umzusortieren.
Ganz sicher nicht in diesen Beispielen. Und niemals bei SSDs.
+6
RiddleR
RiddleR24.02.18 12:26
Hannes Gnad
Bestes macOS = Aktuelles macOS - 0.1 und 10.6.8, 4evär!

Bestes macOS = 10.x.6 oder höher
-3
ratti
ratti25.02.18 22:02
Au weia, hier ist ja wieder ein „Sachverstand“ unterwegs.

Die eingebaute „Defragmentierung“ von OS X kann man vergessen. Sie greift bei Dateien bis maximal 20 MB.
Mammutherde
ratti
Für Systeme wie FAT16 war die regelmässige Defragmentierung daher Pflicht.
Nein, nur extrem selten.
Quatsch.
Moderne Dateisysteme sind mit Fragmentierung im Hinterkopf entwickelt. Sie lassen Dateien Platz zum wachsen, nutzen nicht die erste kleine Lücke zum Schreiben usw. usf.
Moderne Betriebssysteme puffern mit viel RAM Dateizugriffe. Der langsame Zugriff auf die Platte, weil der Kopf ständig bewegt werden muss, ist damit irrelevant.

Das gilt nur in den wenigen Fällen, wo (wiederholtes) schreiben/lesen zeitnah beieinander liegt. Also so gut wie nie.
Das könnte zum Beispiel ein Mailserver sein, der Millionen kleine Maildateien hat.
Nein, siehe Puffer.
Wieviel RAM willst Du denn da reinstopfen? Ich allein habe doppelt soviel Mailspace wie mein Mailserver RAM.
Oder ein Archiv mit Millionen animierten GIF-Bildchen.
Nein. Fragmentierung entsteht durch ständiges Löschen und Neuschreiben oder durch Erweiterung bestehender Dateien. Das ist hier nicht gegeben.

Fragmentierung entsteht nicht nur in Dateien, sondern auch in Verzeichnissen, und genau das ist hier gegeben.
Eine Fontsammlung.
Nein. Fragmentierung entsteht durch ständiges Löschen und Neuschreiben oder durch Erweiterung bestehender Dateien. Das ist hier nicht gegeben.
Siehe oben, Verzeichnisse.

Ich habe umfangreiche Font- und Fotosammlungen. Das sind die langsamsten Ordner, die Du dir vorstellen kannst.

Ein Datenbankserver mit wenigen, aber riesigen Dateien.
Nein. DB-Server beherrschen den optimalen Zugriff schon deutlich länger als Betriebssysteme.
Den Satz versteht wohl keiner…

Kaum eine Datei dürfte so heftig fragmentieren wie eine Datenbank.


Ganz sicher nicht in diesen Beispielen. Und niemals bei SSDs.

…weil SSDs intern, Trommelwirbel: …sich regelmässig defragmentieren.
-3
MarkInTosh26.02.18 05:19
ratti
...
Hier macht es tatsächlich Sinn, auch mal umzusortieren.

Und da immer mehr - auch im Server-Bereich - SSDs eingesetzt werden, macht auch hier Defragmentierung bald gar keinen Sinn mehr. In solch einer Situation mit Dokumenten aus dem Jahr 2004 zu argumentieren, ist ein wenig "Knowledge by Ggogle" und hat im Jahr 2018 kaum noch Relevanz.
+1
MarkInTosh26.02.18 05:30
ratti
Fragmentierung entsteht nicht nur in Dateien, sondern auch in Verzeichnissen, und genau das ist hier gegeben.

Hmmmm... Verzeichnisse sind logische Strukturen, die in der File Allocation Table abgelegt sind. Die Inhalte von Verzeichnissen liegen mitnichten "zusammen" auf der HD. Somit können Verzeichnisse auch nicht fragmentiert sein, sondern nur deren Inhalte.
+1
sffan26.02.18 07:51
Hab irgendwo gelesen, daß die Tools seit gefühlt 10 Jahren kein update verpasst bekamen und immer noch munter verkauft wurden.
Und jetzt hätten sie wirklich mal was tun müssen und dann sind, wie immer, die anderen schuld..
Na ja..
0
ratti
ratti26.02.18 09:29
MarkInTosh

Und da immer mehr - auch im Server-Bereich - SSDs eingesetzt werden, macht auch hier Defragmentierung bald gar keinen Sinn mehr. In solch einer Situation mit Dokumenten aus dem Jahr 2004 zu argumentieren, ist ein wenig "Knowledge by Ggogle" und hat im Jahr 2018 kaum noch Relevanz.

Die Mehrheit der Daten liegen immer noch auf Festplatten, und das wird auch Mittelfristig so bleiben. Zumindest solange Apple High-End-Rechner verkauft, deren SSD halb so groß ist wie meine Fotosammlung, und da haben wir noch gar nicht über Musik und vor allem Filme geredet.

(Und nein, der Mainstream guckt seine Filme noch nicht im Netz)
+1
ratti
ratti26.02.18 09:32
MarkInTosh

Hmmmm... Verzeichnisse sind logische Strukturen, die in der File Allocation Table abgelegt sind. Die Inhalte von Verzeichnissen liegen mitnichten "zusammen" auf der HD. Somit können Verzeichnisse auch nicht fragmentiert sein, sondern nur deren Inhalte.

Nein, auch Verzeichnisse verteilen sich über den Datenträger. Wenn Du 1000 Dateien in einen Ordner kippst, dann muss das System ja eine Liste von 1000 Namen verwalten, und die verteilt sich über die Platte.
-1

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.