Linus TorvaldsとOS Xファイルシステム

2008年に、Linus Torvaldsがインタビューで有名に「OS Xは何らかの点でWindowsよりも実際にプログラムが悪い。彼らのファイルシステムは完全で完全にくだらない、これは恐ろしい」と言った。OS Xファイルシステム（おそらくHFS +）について彼がこのように感じている理由について詳しく調べましたが、何も見つかりませんでした。

Linusは確かに基本的なUnixファイルシステムモデルを嫌いませんし、大文字と小文字を区別しないことでHFS +が嫌いだとは思えません。そして、彼のコメントがどれほど挑発的に表現されているとしても、それが完全にメリットがないとは思えません。コメントはOS Xのプログラミングのコンテキスト内にあったため、彼の意見はパフォーマンス、堅牢性、オペレーティングシステムインターフェイス、またはそれらに沿ったものに基づいているのではないかと思います。2008年時代のLinusが2008年時代のHFS +でどのような苦情を抱えていたのか誰もが知っていますか？

Linusがコメントを作成した「Q＆A」セッションのトランスクリプトは入手可能ですが、詳しく説明するように求められなかったようです。HFS +についての彼の意見のより詳細な分析が他のどこかに書かれているかどうかはわかりません。

他の誰かの問題の分析については、John SiracusaのMac OS Xレビューをご覧ください。特に、Mac OS X Lion向けの「HFS +の何が問題なのか」というタイトルのセクションがあります。最も重要なのは（エンファシスマイニング）です。

並行性、正しいバイト順で書き込まれたメタデータ、1秒未満の日付精度、大量のボリュームサイズのサポート、スパースファイルのサポートはすべて、Unixファイルシステムの一般的な機能です。もちろん、Mac OS XはUnixの基盤の上に構築されています。HFS +が従来のMac OSからMac OS Xに移植されたとき、Unixファイルシステムに期待される最小限の機能セットをサポートするために拡張する必要がありました。

これらの機能の中には簡単に適合するものもありましたが、後方互換性を損なうことなくファイルシステムに追加するのは非常に困難なものもありました。特に恐ろしい例の1つは、HFS +でのハードリンクの実装です。ハードリンクを追跡するために、HFS +は、ボリュームのルートレベルにある隠しディレクトリ内の各ハードリンクに対して個別のファイルを作成します。隠しディレクトリはそもそも不気味なものですが、不必要なデータの重複を避けるためにハードリンクを使用してTime Machineが実装されていることを思い出すと、本当に恐ろしくなります。

ここで重要な点は、Mac OS XがUnixシステム用に設計されていないファイルシステムを使用していることです。従来のMac OS用に設計され、下位互換性を維持しながらMac OS X 10.0の機能を実装するようにパッチが適用されています。Appleはその後、Mac OS X 10.7に現在搭載されている追加機能（ジャーナリング、メタデータ、ファイルシステムイベントなど）を、「ゼロから設計する」アプローチではなく、同じパッチングアプローチを使用して実装しました。これを非技術的に説明する方法がわかりませんが、これらの追加機能はすべて、それらをサポートするように設計されていない従来のMac OS基盤に基づいていると言えます。これは、ソリューションが可能な限り良くないことを意味します。Siracusaが議論を続ける例は、HFS +の制限内で作業している間にAppleがハードリンクに使用しなければならなかったソリューションがハードウェア障害に敏感すぎることです。整合性。もちろん、従来のMac OSとの互換性を維持することは、Mac OS X 10.0では望ましい制限でしたが、実際にはMac OS X 10.7ではもうありません。

私はオペレーティングシステムの専門家ではなく、Windowsから来てOSXを使い始めたばかりですが、自分はWindowsのPowerUserであり、Linuxでかなり有能であると考えています。その背景から来て、OSXのようなかなり最近のOSでは、ファイルシステムにファイルの名前が「マングル」されているなどの奇妙なことがあることに驚いています。

LinusのHFS +に関する問題は同じ点に由来することを理解しています。問題を調査した結果、HFS +はUnicodeを使用してファイル名を保存しますが、ファイルが「拡張」または非ASCII文字（á、 é、í、ó、ú、ñスペイン語またはドイツ語のüのようなもの）、Unicodeは名前をエンコードする2つの方法を提供しますが、OSXはストレージ時に暗黙的にエンコードを「正規化」します...ファイルはOSXで作成および使用されていますが、他のOSのユーザーと情報を共有している場合、ファイルの名前が変更されるという事実により、あらゆる種類の奇妙な動作が発生します...

適切な事例：私は過去8年以上、Subversionでの作業 "アーティファクト"（ファイル、ドキュメントなど）を追跡しています。Macに移行すると、Mac用のSVNクライアントを取得し、関連するディレクトリのチェックアウトを行った後、アクセントのあるすべてのファイルが欠落しているように見え、同じ名前の新しいファイルがバージョン非対応として表示されることがわかりました。掘り下げてみると、問題はファイルシステム内のファイルがアップルでエンコードされているのに対し、リポジトリ内のデータは別の（完全に有効で正当な）Unicodeエンコードを使用していることです...

これは私のデータの大まかな「マングリング」だと思います。Appleはファイル名エンコードの両方の形式を理解しています（Windowsで共有にアクセスするか、WindowsからUSBスティックを使用すると適切なファイル名などが表示されます）。 ..

繰り返しますが、ほとんどのユーザーが気付かないことです-ファイルのコピーを作成するか、ファイルの名前を変更し、元のファイルに戻し、明らかに同じ2つのファイルになるまで!!!）

John SiracusaとDan Benjaminは、Hypercritical＃56の HFS +のいくつかの欠点について説明しています。

HFS +のデータ破損に対処し、ZFSの機能の一部を検討します。