Linus Torvalds und das OS X-Dateisystem

28

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?

Kenster
quelle
2
Er ist dafür bekannt, dass er zu einigen Dingen eine sehr starke Meinung hat. Als er beispielsweise einen Vortrag über git @ google hielt, verbrachte er einen Großteil des Vortrags damit, die anderen Systeme zu zerstören. Ich würde also sagen, dass er wahrscheinlich einen Grund hat zu glauben, was er denkt, aber er ist auch eine sehr übertriebene Person, obwohl er ein Genie ist. youtube.com/watch?v=4XpnKHJAok8
El Developer
3
Wenn Sie hier keine Antwort auf diese Frage erhalten, auf die Sie gehofft haben, können Sie auch nach Unix & Linux oder Super User suchen (und möglicherweise auch fragen) . (Mit so vielen Standorten verfügbar ist es manchmal schwierig zu wissen , welche ist der Ort , um eine Frage zu stellen Mindestens IMHO :)..
irrational John
Ich neige dazu, mit HFS + mehr Köpfe zu stoßen als mit jedem anderen Dateisystem, dem ich normalerweise begegne. Heutzutage habe ich auf den meisten Systemen nicht das Gefühl, überhaupt zu bemerken oder mich darum zu kümmern, welches Dateisystem verwendet wird, aber HFS + lässt sich immer etwas einfallen. Wie gerade heute stellte ich fest, dass ich durch das Fehlen einer Auflösung von weniger als einer Sekunde für moderne Zeiten verärgert war. Es gab auch die Zeit, in der ich zwei Zeilen C-Code gefunden habe, die zu einem Deadlock im Dateisystem führen und die gesamte Maschine zum Absturz bringen könnten. Das war ab 10.5 nicht mehr behoben. Nicht sicher über neuere Versionen.
Iguananaut

Antworten:

21

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.

Rinzwind
quelle
1
Toller Link; das deckt viele wichtige Dinge ab. Mangelnde Unterstützung für spärliche Dateien ist ziemlich verrückt. Linux ext2 hat selbst mit einfacher Block-Bitmap-basierter Zuordnung, wie sie HFS + verwendet, Dateien mit geringer Dichte erstellt. Ich denke, er macht zu viel aus dem Speichern von Metadaten in Big-Endian. Die x86- bswapAnweisung ist sehr schnell. Es macht den Code größer und hässlicher, aber die Kompatibilität auf der Festplatte ist eine große Sache. Linux XFS speichert weiterhin alle Metadaten von Big-Endian (mit Ausnahme von Native-Endian im Journal), da es von SGI auf MIPS-CPUs stammt. Es ist keine ideale Situation, aber XFS wird nicht davon abgehalten.
Peter Cordes
7

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 !!!)

JJarava
quelle
1
Dies ist nur ein Punkt, und das eigentliche Problem ist, dass verschiedene Betriebssysteme die Zeichenfolgen einfach auf unterschiedliche Weise normalisieren und plattformübergreifende Apps damit nicht umgehen. Wenn Sie die Namen nicht normalisieren, ist dies wahrscheinlich schlimmer (Sie könnten unter OS X zwei verschiedene Dateien mit Namen haben, die sich auf dieselbe Zeichenfolge normalisieren).
Blaisorblade
4

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.

badams
quelle
9
Können Sie in Ihrer Antwort eine Zusammenfassung ihrer Diskussion angeben? Der Audio-Stream ist (zu diesem Zeitpunkt in unserer aktuellen Technologie) nicht durchsuchbar und sehr lang. Ganz zu schweigen davon, dass es sich auf einer anderen Website befindet und daher anfällig für Links ist. Dies wäre eine viel bessere Antwort, wenn sie spezifische Details zu ihrer Diskussion enthalten würde.
Ian C.
1
Die Diskussion über das Dateisystem beginnt 23 Minuten in.
neoneye
1
Die meisten im Podcast verfügbaren Informationen finden Sie auch in einem Ars Technica-Artikel von John Siracusa (einer der beiden Männer im Podcast)
TML