Linus Torvalds und das OS X-Dateisystem

Bereits 2008 sagte Linus Torvalds in einem Interview, dass "OS X in gewisser Hinsicht schlechter zu programmieren ist als Windows. Ihr Dateisystem ist vollständig und absolut beschissen, was beängstigend ist." Ich habe nach weiteren Details gesucht, warum er das OS X-Dateisystem (vermutlich HFS +) so empfindet, aber ich konnte nichts finden.

Linus mag das grundlegende Unix-Dateisystemmodell mit Sicherheit nicht, und ich bezweifle, dass er HFS + hasst, weil Groß- und Kleinschreibung nicht beachtet wird. Und obwohl sein Kommentar so provokant formuliert ist, bezweifle ich, dass er völlig unbegründet ist. Da sich der Kommentar auf die Programmierung für OS X bezog, vermutete ich, dass seine Meinung auf der Leistung, der Robustheit, der Betriebssystemschnittstelle oder etwas in dieser Richtung beruhte. Weiß jemand, welche Beschwerden Linus in der Ära 2008 mit HFS + in der Ära 2008 hatte?

Ein Transkript der „Q & A“ -Sitzung, in der Linus den Kommentar abgegeben hat, ist verfügbar, aber es scheint, dass er nicht gebeten wurde, dies zu erläutern. Ich bin mir nicht sicher, ob eine eingehendere Analyse seiner Meinung zu HFS + woanders niedergeschrieben wurde.

Eine Analyse der Angelegenheit durch eine andere Person finden Sie in den Mac OS X-Rezensionen von John Siracusa. Insbesondere das für Mac OS X Lion, das einen Abschnitt mit dem Titel " Was ist los mit HFS +?" Enthält . Ich denke, das herausragendste ist (Hervorhebung von mir):

Parallelität, in der richtigen Bytereihenfolge geschriebene Metadaten, Datumsgenauigkeit von weniger als einer Sekunde, Unterstützung für enorme Datenträgergrößen und Unterstützung für Dateien mit geringer Dichte sind gemeinsame Merkmale von Unix-Dateisystemen. Mac OS X basiert natürlich auf einer Unix-Basis. Wenn HFS + von klassischem Mac OS auf Mac OS X portiert wurde, musste es erweitert werden, um einige Mindestfunktionen zu unterstützen, die von Unix-Dateisystemen erwartet werden .

Einige dieser Funktionen waren einfach anzupassen, andere konnten nur sehr schwer zum Dateisystem hinzugefügt werden, ohne die Abwärtskompatibilität zu beeinträchtigen. Ein besonders beängstigendes Beispiel ist die Implementierung von Hardlinks in HFS +. Um den Überblick über Hardlinks zu behalten, erstellt HFS + eine separate Datei für jeden Hardlink in einem versteckten Verzeichnis auf der Stammebene des Volumes. Versteckte Verzeichnisse sind anfangs gruselig, aber der eigentliche Schrecken entsteht, wenn Sie sich daran erinnern, dass Time Machine mithilfe fester Verknüpfungen implementiert wird, um unnötige Datenduplikationen zu vermeiden.

Der wichtige Punkt hierbei ist, dass Mac OS X ein Dateisystem verwendet, das nicht einmal für ein Unix-System entwickelt wurde. Es wurde für klassisches Mac OS entwickelt und gepatcht, um die Funktionen von Mac OS X 10.0 zu implementieren und gleichzeitig die Abwärtskompatibilität zu gewährleisten. Apple hat die zusätzlichen Funktionen, die es jetzt in Mac OS X 10.7 gibt (Journaling, Metadaten, Dateisystemereignisse ...), nach demselben Patching-Ansatz implementiert und nicht von Grund auf neu entwickelt. Ich bin mir nicht sicher, wie ich das nicht technisch erklären soll, aber man kann sagen, dass all diese zusätzlichen Funktionen auf einer klassischen Mac OS-Grundlage basieren, die nie dafür entwickelt wurde, sie zu unterstützen. Dies bedeutet, dass die Lösung nicht so gut ist, wie sie sein könnte. Das Beispiel, über das Siracusa spricht, ist, dass die Lösung, die Apple bei der Arbeit mit HFS + für harte Links verwenden musste, zu anfällig für Hardwarefehler ist. Dies wird durch die Tatsache verstärkt, dass HFS + auch nie dafür entwickelt wurde, sich mit Daten zu befassen Integrität. Natürlich war die Beibehaltung der Kompatibilität mit klassischem Mac OS eine wünschenswerte Einschränkung in Mac OS X 10.0, aber in Mac OS X 10.7 ist dies nicht mehr der Fall.

Obwohl ich kein Betriebssystemexperte bin und OSX erst seit Windows benutze, sehe ich mich als PowerUser in Windows und als ziemlich kompetent in Linux. Vor diesem Hintergrund war ich überrascht, dass das Dateisystem in einem ziemlich modernen Betriebssystem wie OSX Macken aufweist, wie die Art und Weise, wie die Namen von Dateien "verwechselt" werden.

Ich verstehe, dass die Probleme von Linus mit HFS + auf denselben Punkt zurückzuführen sind: Nach meinen Recherchen speichert HFS + die Namen von Dateien mit Unicode, aber wenn eine Datei "erweiterte" oder NICHT-ASCII-Zeichen verwendet (wie á, (é, í, ó, ú, ñ aus dem Spanischen oder dinge wie das ü in Deutsch), für die Unicode 2 Möglichkeiten zur Kodierung des Namens bietet, "normalisiert" OSX stillschweigend die Kodierung zur Speicherzeit ... Kein echtes Problem, wenn das Datei wurde in OSX erstellt und verwendet, aber wenn Sie Informationen mit Benutzern anderer Betriebssysteme austauschen, führt die Tatsache, dass sich der Name der Datei ändert, zu merkwürdigen Verhaltensweisen ...

Ein typisches Beispiel: Ich habe meine Arbeit "Artefakte" (Dateien, Dokumente usw.) in den letzten 8 Jahren in Subversion nachverfolgt. Als ich auf den Mac umgestiegen bin, habe ich den SVN-Client für den Mac erhalten. Nach einer Prüfung meiner relevanten Verzeichnisse habe ich festgestellt, dass alle Dateien mit Akzenten fehlen und eine neue Datei mit demselben Namen als nicht versioniert angezeigt wird. Das Problem dabei ist, dass die Datei im Dateisystem Apfel-codiert ist, während die Daten im Repository eine andere (absolut gültige und legitime) Unicode-Codierung verwenden ...

Ich denke, dies ist eine grobe "Verwirrung" meiner Daten. Apple versteht zwar beide Formate der Dateinamencodierung (der Zugriff auf eine Freigabe in Windows oder die Verwendung eines USB-Sticks in Windows zeigt die richtigen Dateinamen usw. an), aber bei der Dateierstellung wird entschieden, dass "es besser weiß", und die Dateien werden einfach umbenannt. ..

Auch hier wird den meisten Benutzern nichts auffallen - bis sie eine Kopie einer Datei erstellen oder diese umbenennen und an den ursprünglichen Speicherort zurückversetzen und am Ende zwei scheinbar gleiche Dateien erhalten !!!)

John Siracusa und Dan Benjamin diskutieren einige Nachteile von HFS + in Hypercritical # 56 .

Sie beheben Datenbeschädigungen in HFS + und berücksichtigen einige der ZFS-Funktionen.