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

Details zum neuen Apple-Dateisystem APFS

Apples derzeitiges Dateisystem HFS ist nun - von Updates einmal abgesehen - seit 30 Jahren am Markt. Früher wurde es auf kleinsten Festplatten und Disketten eingesetzt, nun auf modernsten SSDs. Apple erweiterte das alte Dateisystem mit einigen Tricks und Kompromissen um moderne Funktionen wie zum Beispiel Journaling - aber viele neue Technologien konnten nicht umgesetzt werden.

Erst durch die Entwicklerdokumentation wurde gestern bekanntgegeben, dass Apple im kommenden Jahr ein neues Dateisystem mit dem Namen "Apple File System", kurz APFS, auf den Markt bringen wird. Dabei scheint es sich nach derzeitigen Informationen um eine Eigenentwicklung von Apple zu handeln und nicht um ein übernommenes Open-Source-Projekt.


Kopieren ohne Verzögerung

Eine besonders interessante Neuerung in APFS ist "Copy On Write". Dies bedeutet, dass eine kopierte Datei erst dann tatsächlich kopiert wird, wenn das Original oder die Kopie wirklich verändert wird - bis dahin existieren für den Benutzer zwar zwei Dateien im Finder, aber nur einmal physikalisch auf der Festplatte. Dadurch werden selbst gigantisch große Dateien praktisch ohne zeitliche Verzögerung kopiert. Bestehende Programme müssen nicht angepasst werden, um diese neue Funktionalität zu nutzen.

Flexible Partitionen

Apple führt mit Space Sharing eine aus anderen fortschrittlichen Dateisystemen bekannte Technik ein, mit der sich eine Festplatte mit mehreren Partitionen erstellen lässt, die aber keine feste Größe mehr haben. Jede einzelne Partition meldet, dass der gesamte Platz der Festplatte zur Verfügung steht. Dies ist praktisch, wenn man im Vorhinein mehrere Systeme auf einem Mac installieren will, aber nicht genau weiß, wie viel Platz man auf den jeweiligen Partitionen tatsächlich für das Arbeiten benötigt.

Snapshots

Mit dem neuen Dateisystem ändert sich die Art und Weise, wie Backups angefertigt werden. APFS unterstützt Snapshots - dies sind Momentaufnahmen des aktuellen Stands des gesamten Dateisystems. Beim Anfertigen eines Snapshots findet erst einmal kein Kopiervorgang statt. Es wird lediglich markiert, welcher Stand von welcher Datei zu diesem Snapshot gehört. Erst wenn eine Datei nach Erstellen des Snapshots geändert wird, schreibt das Dateisystem die geänderte Stelle der Datei an eine neue Position auf der Festplatte und APFS registriert, dass diese Änderung nicht zum Snapshot gehörte. So kann Time Machine beim späteren Kopieren sich die lästige Suche nach geänderten Dateien sparen - Backups auf andere physikalische Medien sind so deutlich effizienter.

Sofortige Größenberechnung von Ordnern

Jeder Nutzer kennt die ewig langsame Berechnung von Ordnergrößen,  selbst auf Macs mit SSD. Dies soll mit APFS der Vergangenheit angehören - Ordnergrößen sollen sich der Entwickler-Dokumentationen sehr effizient errechnen lassen. Leider gibt Apple hier wenig Informationen bekannt, auf welche Weise dies erreicht wird.

Verschlüsselung nativ im Dateisystem

APFS bietet nun eine Verschlüsselung direkt auf Ebene des Dateisystems an. Bisher war dies nur auf OS X mittels File Vault möglich - iOS-Geräte verschlüsselte jede Datei individuell. APFS vereint die beiden Ansätze und bietet viele verschiedene Abstufungen an Verschlüsselungsverfahren: Keine Verschlüsselung, Verschlüsselung mit einem einzigen Schlüssel und Verschlüsselung mit individuellen Schlüsseln pro Datei. Als Verschlüsselungsverfahren kommt entweder AES-XTS oder AES-CBC zum Einsatz, je nachdem auf welcher Hardware das Dateisystem betrieben wird.

Weitere Neuerungen

Im alten HFS-Dateisystem wurden Änderungs- und Erstellungszeitpunkte noch mit einer Präzision von einer Sekunde gespeichert - Apple erhöhte dies in AFPS auf eine Nano-Sekunde. Der Sinn dahinter ist, dass das Dateisystem so erheblich genauer den Änderungsverlauf an einer Datei protokollieren kann um so im Falle eines Absturzes den letzten Zustand wieder herstellen zu können.

Ein alter Bekannter aus den frühen Mac-OS-Tagen wird mit APFS endgültig begraben: Das Apple Filing Protocol, kurz AFP, erlaubte seit System 6 das Austauschen von Dateien über Netzwerke. AFP wird auf APFS-formatierten Volumes nicht mehr funktionieren - Apple wird nur noch das ursprünglich von Microsoft entwickelte und im Unternehmensumfeld verbreitete SMB unterstützen. Schon seit OS X 10.9 Mavericks ist SMB das bevorzugte Protokoll, mit dem zwischen Macs Dateien im Netzwerk ausgetauscht werden.

APFS erlaubt nun auch endlich flexible Datei-Attribute wie beispielsweise unendlich viele Etikett-Typen. Im alten Dateisystem HFS wurden Dateiattribute über eine gesonderte Datei realisiert - dies ist aber ein großer Kompromiss aus Entwickler-Sicht gewesen.

Große Dateien, welche erst im Laufe der Zeit mit Daten gefüllt werden (Beispiel: Virtuelle Festplatte einer Virtualisierungsumgebung wie Parallels oder VMWare), belegen mit APFS nur den tatsächlich genutzten Speicherplatz.

Von Marktreife noch weit entfernt

Laut Apple soll APFS erstmalig 2017 beim Endkunden eingesetzt werden. In macOS Sierra können Entwickler schon Partitionen oder DMGs mit APFS formatieren, um Programme mit dem neuen Dateisystem zu testen. Leider stehen viele Funktionen wie z.B. Snapshots oder das schnelle Errechnen von Ordnergrößen bislang noch nicht zur Verfügung.

Kommentare

MikeMuc14.06.16 10:42
Na ob das was wird? Und was wird aus TimeMachine wenn das Filesystem doch schon Snapshots unterstützt?
Bevor man da etwas komplett neues macht könnte man doch ZFS wieder auf nehmen, da wäre doch schon eine Basis vorhanden
-1
gritsch14.06.16 10:44
"Copy On Write" kann aber auch nerven.
Wenn ich zb vor dem Mittagessen die 900 GB-Datei dupliziere um sie nachher zu bearbeiten, dann wird der "langsame" duplizierungsprozess erst gestartet sobald ich nach dem mittagessen die datei effektiv verändere anstatt wärend ich nicht am rechner bin...
0
gritsch14.06.16 10:45
MikeMuc
Na ob das was wird? Und was wird aus TimeMachine wenn das Filesystem doch schon Snapshots unterstützt?
Bevor man da etwas komplett neues macht könnte man doch ZFS wieder auf nehmen, da wäre doch schon eine Basis vorhanden

ZFS geht Lizenzrechtlich nicht (mehr).

Snapshots sind noch lange kein Backup!
0
Jfk14.06.16 10:50
wie verhält es sich denn mit Dateiberechtigungen unter SMB?
Gerade im Mischbetrieb zb
0
Tirabo14.06.16 10:53
gritsch
"Copy On Write" kann aber auch nerven.
Wenn ich zb vor dem Mittagessen die 900 GB-Datei dupliziere um sie nachher zu bearbeiten, dann wird der "langsame" duplizierungsprozess erst gestartet sobald ich nach dem mittagessen die datei effektiv verändere anstatt wärend ich nicht am rechner bin...

Dann "bearbeite" sie doch minimalst schon vor dem Mittagessen, dann wird der Prozess doch auch schon vor dem Mittagessen gestartet, oder habe ich da was falsch verstanden?
0
sockenpuppe_23414.06.16 10:55
gritsch
"Copy On Write" kann aber auch nerven.
Wenn ich zb vor dem Mittagessen die 900 GB-Datei dupliziere um sie nachher zu bearbeiten, dann wird der "langsame" duplizierungsprozess erst gestartet sobald ich nach dem mittagessen die datei effektiv verändere anstatt wärend ich nicht am rechner bin...
Du kannst die Datei dann vor dem Mittagessen duplizieren (dauert ja nur noch weniger als 1 sec) und vor dem Mittagessen die erste Änderung speichern. Während dem Speichern der ersten Änderung kannst Du dann in Ruhe mittagessen
0
gritsch14.06.16 10:58
Tirabo
gritsch
"Copy On Write" kann aber auch nerven.
Wenn ich zb vor dem Mittagessen die 900 GB-Datei dupliziere um sie nachher zu bearbeiten, dann wird der "langsame" duplizierungsprozess erst gestartet sobald ich nach dem mittagessen die datei effektiv verändere anstatt wärend ich nicht am rechner bin...

Dann "bearbeite" sie doch minimalst schon vor dem Mittagessen, dann wird der Prozess doch auch schon vor dem Mittagessen gestartet, oder habe ich da was falsch verstanden?

Bei 1 datei ja kein problem. Kopiert man aber ein komplettes projekt mit 5 files muss man 5 files bearbeiten etc... dann warte ich lieber nach dem essen etwas länger...
0
Bitsurfer14.06.16 11:00
gritsch
"Copy On Write" kann aber auch nerven.
Wenn ich zb vor dem Mittagessen die 900 GB-Datei dupliziere um sie nachher zu bearbeiten, dann wird der "langsame" duplizierungsprozess erst gestartet sobald ich nach dem mittagessen die datei effektiv verändere anstatt wärend ich nicht am rechner bin...

Warum? Die Kopierte Datei ist physisch nur einmal vorhanden. Du öffnest zum bearbeiten, und speicherst dann. Dann sind es zwei Dateien. Der Kopiervorgang dauert wohl gleichlang wie der Speichervorgang.
0
ratti
ratti14.06.16 11:20
Ist das dann ENDLICH der Tod für den .DS_Store-Scheiss?
0
Mendel Kucharzeck
Mendel Kucharzeck14.06.16 11:21
ratti
Keine gesicherten Infos hierzu, da aber echte Meta-Informationen unterstützt werden, könnte das .DS_Store endlich Geschichte sein!
+1
gritsch14.06.16 11:45
Mendel Kucharzeck
ratti
Keine gesicherten Infos hierzu, da aber echte Meta-Informationen unterstützt werden, könnte das .DS_Store endlich Geschichte sein!

Wie soll das gehen? Das .DS_Store und all die anderen ._Attribute fällt ja niemandem auf außer man kopiert seine Dateien auf ein Laufwerk welches ein anderes Dateisystem hat welches dieses feature nicht unterstützt. Dieses andere Dateisystem kann also entweder die infos verwerfen (nicht optimal) oder sie eben als eigene datei abspeichern wenn es selbst keine andere möglichkeit hat datei-attribute zu speichern.
Das problem liegt also eher an FAT und co und nicht an dem Dateisystem das Attribute erlaubt...
0
Fehler 11
Fehler 1114.06.16 11:50
Kein AFP mehr? Was wird dann aus Time Machine? Bekommt Apple SMB bis 2017 in den Griff? Bin sehr gespannt... Die Features klingen schon mal sehr gut aber ob das alles wirklich so funktionieren wird. Irgendwie traue ich das Apple nicht zu. Ist aber auch nur ein Bauchgefühl...
0
someone14.06.16 11:50
gritsch
Mendel Kucharzeck
ratti
Keine gesicherten Infos hierzu, da aber echte Meta-Informationen unterstützt werden, könnte das .DS_Store endlich Geschichte sein!

Wie soll das gehen? Das .DS_Store und all die anderen ._Attribute fällt ja niemandem auf außer man kopiert seine Dateien auf ein Laufwerk welches ein anderes Dateisystem hat welches dieses feature nicht unterstützt. Dieses andere Dateisystem kann also entweder die infos verwerfen (nicht optimal) oder sie eben als eigene datei abspeichern wenn es selbst keine andere möglichkeit hat datei-attribute zu speichern.
Das problem liegt also eher an FAT und co und nicht an dem Dateisystem das Attribute erlaubt...
Das .DS_Store Konzept hinterlaesst quasi eine Spur der Verwuestung (vor allem in fremden Dateisystemen) da Timestamps der Verzeichnisse veraendert werden und z.B. Skripte welche nicht mit solchen Files rechnen falsch laufen koennen etc.
0
gritsch14.06.16 12:08
someone
gritsch
Mendel Kucharzeck
ratti
Keine gesicherten Infos hierzu, da aber echte Meta-Informationen unterstützt werden, könnte das .DS_Store endlich Geschichte sein!

Wie soll das gehen? Das .DS_Store und all die anderen ._Attribute fällt ja niemandem auf außer man kopiert seine Dateien auf ein Laufwerk welches ein anderes Dateisystem hat welches dieses feature nicht unterstützt. Dieses andere Dateisystem kann also entweder die infos verwerfen (nicht optimal) oder sie eben als eigene datei abspeichern wenn es selbst keine andere möglichkeit hat datei-attribute zu speichern.
Das problem liegt also eher an FAT und co und nicht an dem Dateisystem das Attribute erlaubt...
Das .DS_Store Konzept hinterlaesst quasi eine Spur der Verwuestung (vor allem in fremden Dateisystemen) da Timestamps der Verzeichnisse veraendert werden und z.B. Skripte welche nicht mit solchen Files rechnen falsch laufen koennen etc.

nicht "vor allem" sondern NUR auf anderen dateisystemen weil die eben keine attribute für ordner unterstützen (so wie auch HFS+ das nicht unterstützt und daher die infos in die datei kommen). Wenn jetzt aber das neue Dateisystem Attribute für Ordner unterstützt, dann gibts es zwar keine .DS_Store dateien mehr sondern eben eine ._Ordnername datei in jedem ordner(auf anderen dateisystemen) - und das filtert man sehr viel schwerer als einen fixen dateinamen.
0
SchaubFD14.06.16 12:42
Bitte vorher mal lesen was CopyOnWrite ist! Der Mist der hier geschrieben wird ist haaresträubend! Gilt auch für den Autor des Beitrags.

"Eine besonders interessante Neuerung in APFS ist "Copy On Write".
Weder Apple, noch Sun noch Netapp haben diese Methode entwickelt (Info)!

"Dies bedeutet, dass eine kopierte Datei erst dann tatsächlich kopiert wird, wenn das Original oder die Kopie wirklich verändert wird - bis dahin existieren für den Benutzer zwar zwei Dateien im Finder, aber nur einmal physikalisch auf der Festplatte. Dadurch werden selbst gigantisch große Dateien praktisch ohne zeitliche Verzögerung kopiert."
Was hier beschrieben wird ist Deduplikation und nicht CopyOnWrite!

"Bestehende Programme müssen nicht angepasst werden, um diese neue Funktionalität zu nutzen."
Der Satz stimmt wenigstens
0
SchaubFD14.06.16 12:45
gritsch
Snapshots sind noch lange kein Backup!

Richtig, aber bei ZFS der Weg zum Backup.
0
SchaubFD14.06.16 12:50
Für den Rest hier, bitte versucht COW (CopyOnWrite) und Deduplikation auseinander zu halten. Viele eurer Aussagen sind sonst im Zusammenhang falsch.
0
sierkb14.06.16 13:01
gritsch
MikeMuc
Bevor man da etwas komplett neues macht könnte man doch ZFS wieder auf nehmen, da wäre doch schon eine Basis vorhanden

ZFS geht Lizenzrechtlich nicht (mehr).

Deine Begründung dazu ist welche?
ZFS ging lizenztechnisch immer, war und ist lizenztechnisch sogar prädestiniert und ideal. ZFS stand und steht immer noch unter der CDDL (ausgesprochen: 'cuddle.'). Die ist bewusst BSD-ähnlich. Und genau das spielt Apple somit geradezu in die Hände. Lizenztechnisch gab es nie und gibt es da auch jetzt keinen Hinderungsgrund für Apple.
0
Cupertimo14.06.16 13:06
Was ist denn jetzt nun CopyOnWrite?
0
SchaubFD14.06.16 13:17
Bin gerade im Mittag. COW wird benötigt um Snaphots generell erst zu ermöglichen. Nur veränderte Daten/Blöcke werden neu geschrieben. Kann dazu später mehr schreiben.
0
jensche14.06.16 13:17
Wikipedia
Bei Dateisystemen bedeutet Copy-On-Write, dass geänderte Blöcke nicht überschrieben, sondern zunächst vollständig an einen freien Platz geschrieben werden. Danach werden Verweise auf den Block in den Metadaten aktualisiert. Copy-On-Write ermöglicht transaktionsbasierende Dateisysteme, die unter anderem ohne Verzögerung Speicherabbilder (oder Schnappschüsse derselben) anlegen können. Alte Metadaten und Blöcke werden dabei nicht gelöscht, sondern dem jeweiligen Speicherabbild zugeordnet.

ZFS oder Btrfs sowie WAFL (Netapp) sind bekannte Vertreter von Dateisystemen, die auf Copy-on-Write bauen.
0
sierkb14.06.16 14:02
SchaubFD
COW wird benötigt um Snaphots generell erst zu ermöglichen. Nur veränderte Daten/Blöcke werden neu geschrieben.

Dazu Apples Doku zu APFS:
Apple File System Guide
[…]
New Features
[…]
Cloning of Files and Directories

A clone is a nearly instantaneous copy of a file or directory that occupies no additional space for file data. When a cloned file is modified, only the modified blocks are written to new locations on storage. In this way, the file system can store multiple revisions of the same document with less storage space.
[…]

Snapshots

A snapshot is a read-only instance of a file system on a volume. The operating system can use snapshots to make backups work more efficiently, and offer a way to revert changes to a given point in time.
[…]
Quelle: ,
0
SchaubFD14.06.16 15:03
Danke Sirkb, stellt sich halt noch die Frage, warum nicht gleich ZFS? Letztlich lese ich auch nichts von Compression und Datenintegrität, möchte aber den Beitrag nicht ins Uferlose gehen lassen.
0
Weia
Weia14.06.16 15:42
MikeMuc
Bevor man da etwas komplett neues macht könnte man doch ZFS wieder auf nehmen, da wäre doch schon eine Basis vorhanden
Apple hat bekanntermaßen vor 9 Jahren mit ZFS geliebäugelt, sich dann aber (warum auch immer) dagegen entschieden, und entwickelt jetzt seit 8 Jahren an APFS. Da werden sie nun Deinen Vorschlag sicher liebend gern aufgreifen, kurz vor Fertigstellung von APFS doch wieder auf ZFS zurüchzugehen.
Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)
0
sierkb14.06.16 16:30
Weia
MikeMuc
Bevor man da etwas komplett neues macht könnte man doch ZFS wieder auf nehmen, da wäre doch schon eine Basis vorhanden
Apple hat bekanntermaßen vor 9 Jahren mit ZFS geliebäugelt, sich dann aber (warum auch immer) dagegen entschieden

Sun Microsystems stand damals unter Beschuss seitens Netapp, welche Sun bzgl. ZFS eine Patentklage an den Hals hängten. Das war Apple wohl zu heikel bzw. sie wollten nicht das Risiko tragen/mittragen, evtl. Lizenzgebühren an NetApp zu zahlen oder als Auch-Nutzer ggf. auch verklagt zu werden, Apple wollte dem Vernehmen nach von Sun eine Zusicherung und volle alleinige Risikoübernahme haben, selbst wenn auch Apple verklagt worden wäre, das wollte oder konnte Sun Apple wohl nicht geben, das ging Sun zu weit, dass Apple da wohl so null Risiko bereit war zu tragen, deswegen kam der Deal zwischen beiden nicht zustande. Das alles ist nur halboffiziell bekannt, offiziell nicht, alle schweigen sich über die Details aus (es kam dawohl auch zu Meinungsverschiedenheiten zwischen Sun und Apple). Aber einer, der da wohl damals dabei oder seh nah dran war, hat mal vor einiger Zeit auf einer Apple Dev-Mailingliste ein wenig den Vorhang gelupft und diese Andeutungen gemacht und ein paar an ihn gerichtete gezielte Fragen quasi durch Kopfnicken oder Kopfschütteln bestätigt bzw. verneint und dem dann weitere Andeutungen hinzugefügt, die derlei Schlussfolgerungen dann von ihm unwidersprochen nach sich zogen, also scheint diese Lesart der Story sehr nah an den damaligen Geschehnissen zu sein.

Nicht lange, nachdem Apple von ZFS dann Abstand genommen hatte, folgte der Aufkauf von Sun durch Oracle, und eine der ersten Amtshandlungen Oracles war, den Patentstreit mit NetApp beizulegen und sich zu einigen. Seitdem herrscht bzgl. ZFS Rechtssicherheit. Und seitdem hätte Apple den Faden wieder aufnehmen können, es nochmal versuchen können bzgl. ZFS. Zumal inzwischen Apples ZFS-Verantwortlicher gegangen ist und eine eigene Firma mit seiner für Apple erarbeiteten ZFS-Implementierung betrieb (Ten Complements). Apple hätte ihn zurückholen können. Apple hätte da weitermachen können, wo sie aufgehört hatten, die Rechtsunsicherheit, der Patentstreit zwischen Sun/Oracle und NetApp sind ja inzwischen schon lange beigelegt. Möglicherweise ist die Meinungsverschiedenheit zwischen Sun und Apple da ja auch so heftig gewesen, dass da was in der Kommunikation zwischen beiden zerrissen ist und Apple deshalb den Faden nicht wieder aufgenommen hat, obwohl sie es hätten tun können, der Patentstreit ist ja längst geklärt, Rechtssicherheit ist ja längst geschaffen. Was sich andere Interessenten inzwischen ja auch sehr zunutze machen: ZFS hat z.B. längst Einzug in FreeBSD erhalten, lange nach diesem Rechtsstreit, und das Einarbeiten vonZFS dort ging sogar relativ gesehen fix, in Ubuntu und Debian GNU/Linux sogar jetzt auch.
und entwickelt jetzt seit 8 Jahren an APFS

Das ist die Frage und wäre mal interessant herauszubekommen, wie lange sie da schon dran arbeiten, ob es wirklich 8 Jahre sind oder weniger, grad' unter Berücksichtigung von grad' Gesagtem.
Da werden sie nun Deinen Vorschlag sicher liebend gern aufgreifen, kurz vor Fertigstellung von APFS doch wieder auf ZFS zurüchzugehen.

Lieber was Eigenes machen mit entsprechender neuer Lernkurve, neuen Fehlern und neuen Risiken und entsprechend nötiger Reifezeit... Und wenn es bedeutet, das Rad nochmal zu erfinden, statt vorhanden Bewährtes und Gutes einfach zu nehmen und für sich anzupassen. Not-invented-here-(NIH)-Syndrom
Naja, egal. Hauptsache, es kommt am Ende was richtig Gutes bei heraus,dasistdie Hauptsache. Dauert halt nur etwas länger, bis es im harten Einsatz unter allen nur denkbaren harten Bedingungen und Worst-Case-Szenarien gereift ist und keine Kinderkrankheiten mehr hat (ca.10+ Jahre). Ich denke, diese Zeit hätte man sich mit ZFS bzw. OpenZFS sicher verkürzen können, das hat seine Reife- und Bewährungszeit schon hinter sich, zeigt seine Stabilität und Zuverlässigkeit seit Jahren schon. Und ist dadurch eigentlich umso attraktiver. APFS steht das nun alles noch bevor.
0
Weia
Weia14.06.16 16:52
sierkb
Weia
und entwickelt jetzt seit 8 Jahren an APFS
Das ist die Frage und wäre mal interessant herauszubekommen, wie lange sie da schon dran arbeiten
Apple hat nach der Entscheidung gegen ZFS sehr bald Stellen für entsprechende Fachleute ausgeschrieben und zügig besetzt, wenn ich mich recht erinnere. Das wurde damals auch vom Auge der Öffentlichkeit verfolgt, aber danach ist das Interesse dann eingeschlafen, weil halt nicht sofort etwas Sichtbares dabei herauskam.

Von daher denke ich, man kann davon ausgehen, dass Apple seitdem an APFS gearbeitet hat und das System intern einen langen Reifungsprozess hinter sich hat. Klar, Erfahrungen mit dem Einsatz in der rauen Wirklichkeit sind damit nicht zu ersetzen.
Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)
0
sierkb14.06.16 17:17
Weia
Von daher denke ich, man kann davon ausgehen, dass Apple seitdem an APFS gearbeitet hat und das System intern einen langen Reifungsprozess hinter sich hat. Klar, Erfahrungen mit dem Einsatz in der rauen Wirklichkeit sind damit nicht zu ersetzen.

Das ist die Frage, ob das Ding intern schon so lange in der Mache ist. Lies Dir die Developer-Doku dazu mal durch, da steht verschiedentlich, dass verschiedene APIs dazu noch gar nicht existieren oder noch gar nicht stabil sind und verschiedene Dinge noch gar nicht möglich sind, aber für die Zukunft angedacht sind.
Hört sich für mich ehrlich gesagt nicht danach an, als wenn das Ganze schon einen langen internen Reifungsprozess durchgemacht hat, in 8 Jahren hätten sie dann ja wenigstens mal für alles APIs bereitstellen und definieren können. Aber wenn selbst die noch nicht mal in dem Zustand sind, dass sie "freezed" sind sondern noch im Fluss oder sogar in weiten Teilen noch gar nicht existent... Ich weiß nicht...
0
Weia
Weia14.06.16 17:45
sierkb
Das ist die Frage, ob das Ding intern schon so lange in der Mache ist. Lies Dir die Developer-Doku dazu mal durch, da steht verschiedentlich, dass verschiedene APIs dazu noch gar nicht existieren oder noch gar nicht stabil sind und verschiedene Dinge noch gar nicht möglich sind, aber für die Zukunft angedacht sind.
Hört sich für mich ehrlich gesagt nicht danach an, als wenn das Ganze schon einen langen internen Reifungsprozess durchgemacht hat
Hmmm … guter Punkt …
Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)
0
someone14.06.16 17:58
Ich hoffe es arbeiten nicht die gleichen Leute dran die bisher auch an HFS+ rumgepfuscht haben, sonst sehe ich da zappenduster...
0
SchaubFD14.06.16 18:32
Wisst ihr was daran besonders lustig ist. Es gibt schon lange ein ZFS für OS X, welches frei geladen werden kann. Meine iTunes Musik z.B. liegt auf einem ZFS Triple RAID aus drei Laptopplatten. Apple muss aber wie üblich ein eigenes Ding drehen. Es ist wie bei Linux mit BTRFS. Nichts gegen Entwickler, die gerne auch mal was entwickeln wollen. ZFS ist aber viel mehr als nur ein schnödes Dateisystem und daran können BTRFS (Linux), HammerFS (BSD) und ReFS/NTFS (Windows) nichts ändern. Allen genannten fehlt ein Volume Manager! Datenintegrität geht nur richtig, wenn man Prüfsummen bis auf die Einzelplatte schreibt. Viele verstehen bis heute nicht, dass RAID nur den Plattenausfall abfängt, nicht aber den Inhaltsausfall der Platte. Von den CRC Prüfsummen einer Platte, die sich quasi alle 256 Blöcke wiederholen zu schweigen. Wir reden heute nicht mehr von Kilobyte Disketten! S.M.A.R.T. ist übrigens genau so eine Augenwischerei.

Einer der Schreiber sagte es schon, es sollte endlich einen portablen Standard für diesen Zweck geben. ZFS in der Form OpenZFS läuft von Solaris über BSD und Linux bis OS X. Wenn ich eine ZFS Partition kopiere, dann weiß ich, dass alle meine Daten 100% korrekt auf dem anderen RAID gelandet sind. Kein Hardware-RAID und viele Software-RAID's können dies nicht. ZFS kann defekte Blöcke erkennen und diese Fehler korrigieren. PS: Immer darauf achten, dass unter diesen Dateisystemen kein Software-RAID existiert. Ist z.B. bei den Synology NAS Systemen der Fall, damit ist zwar die Fehlererkennung möglich, die Korrektur geht so aber nicht.
0
Weitere News-Kommentare anzeigen

Kommentieren

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