昨年リリースされたLinux 5.2のパッチノートを読んでいたところ、ext4 ファイルシステムで大文字と小文字を区別しない名前のオプションサポート。
そこで私が疑問に思っているのは、カーネルに大文字小文字を区別しないオプション（casefoldと正規化を含む）が必要だった理由です。別の記事これは、大文字小文字を区別するファイルシステムをサポートするカーネル コードを書いた Krisman によって書かれたものですがcase-insensitive file system allows us to resolve important bottlenecks for applications being ported from other operating systems、私には納得できず、正規化と大文字小文字を区別するプロセスによってディスク ストレージがどのように最適化されるのか理解できません。
ご協力に本当に感謝しています!
答え1
大文字と小文字を区別しないファイルシステムにより、他のオペレーティングシステムから移植されるアプリケーションの重要なボトルネックを解決できます。
私には理解できませんし、正規化とケースフォールディングのプロセスによってディスク ストレージを最適化できる仕組みも理解できません。
ワイン、Samba、Android持っている大文字と小文字を区別しないファイルシステムのセマンティクスを提供する。基盤となるファイルシステムが大文字と小文字を区別する場合、大文字と小文字を区別する検索が失敗するたびに、Wine らは各ディレクトリをスキャンして、大文字と小文字を区別しない一致がないことを証明する必要があります (たとえば、検索が失敗した場合は、 内のすべてのファイルと 内のすべてのディレクトリ、およびの/foo/bar/readme.txt完全なディレクトリ一覧と大文字と小文字を区別した比較を実行する必要があります)。foo/bar/*foo/*/*
これにはいくつか問題があります:
- 深くネストされたパス（これにより数百のFSコール）または数万のファイルを含むディレクトリ（つまりSMB経由で増分バックアップを保存する）。
- これらのチェックにより競合状態が発生します。
- これは根本的に不健全です。
readme.txtと の両方がREADME.txt存在するが、アプリケーションが を要求した場合README.TXT、どちらのファイルが返されるかは未定義です。
AndroidはFUSE/wrapfsとカーネル内機能を使って大文字小文字を区別しない動作をエミュレートするところまで行った。SDカードFSしかし、SDCardFSはプロセスをカーネルスペースに移動することですべてを高速化しただけです†。それでもファイルシステムをたどる必要があり（したがってIOバウンド）、競合状態が発生し、根本的に不健全でした。そのため、GoogleはF2FSのネイティブなディレクトリごとの大文字小文字の区別なしの開発に資金を提供し†、その後廃止しました。SDカードFS。
過去には、VFS経由で大文字と小文字を区別しない検索を可能にする試みが複数回行われてきました。2018年の最新の試みでは、ファイルシステムの大文字と小文字を区別しない表示Ted Tso は、この機能を追加した理由として wrapfs の問題を具体的に挙げました。少なくとも高速になり、競合状態もなくなる (と私は信じています) からです。しかし、それでもまだ不健全でした (要求するとまたは がREADME.TXT返される可能性があります)。これは却下され、代わりにディレクトリごとに大文字と小文字を区別しないサポートを追加することになりましたが、VFS†† に取り入れられる可能性は低いでしょう。readme.txtREADME.txt
さらに、ユーザーは大文字と小文字を区別しないことを期待しているため、消費者向けのオペレーティングシステムはそれを提供する必要があります。Unix は、Unicode が存在せず、文字列が単なるバイトの集まりであったため、ネイティブにサポートできませんでした。大文字と小文字の区別の処理方法については、多くの正当な批判があります。過去に、しかしUnicodeは不変 case-fold関数すべてに有効ですが単一のロケール（トルコ語でもコードポイントは2つだけです）。そしてファイルシステム B ツリーこの動作を実装する唯一の適切な場所です。
†私の知る限り
††私は、VFS ベースの大文字と小文字を区別しない検索と、EXT4 および F2FS 上のディレクトリごとの大文字と小文字を区別しないサポートの両方の作者である Krisman に電子メールを送りました。
答え2
他のオペレーティング システムでは、大文字と小文字を区別しないファイル システムが使用されます。
たとえば、MacOS では大文字と小文字を区別しない (デフォルト) か区別するかを選択できます。Adobe Photoshop と Adobe Lightroom は、大文字と小文字を区別するファイル システムではうまく動作しません。つまり、Adobe プログラムには、ハードコードされたパスがあり、さまざまな方法で記述されている可能性があります (異なるライブラリに「Documents」と「documents」があるか、場合によってはフィルターが適用されている可能性があります (たとえば、小文字にしてスペースを削除するなど、データのパスと異なる場合があります)。問題なく機能するため、誰も気にしませんでした。
したがって、現在、私たちの時代の一般的な独自のオペレーティング システム用に作成されたプログラムを移植したい場合は、ファイル名の大文字と小文字が常に一貫して使用されるようにすべてのパスを修正するか、これらを処理するファイル システムを使用することをお勧めします。
AdobeはMacOSではそれができなかったので、他のベンダーにとっては物事がはるかに困難（そしてコスト高）になると考えられます。https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html
答え3
大文字と小文字を区別する FS を持つ理由が私にはまったくわかりません。ユーザーを完全に混乱させるだけです。Microsoft の開発者は最初からそれを理解しており、壊れた概念に煩わされることはありませんでした。30 年経った今、一部の Linux 開発者は大文字と小文字を区別しない方が安全で論理的であることに気づき、ついにそれを実装しました。
なぜ最初の Unix ファイルシステムは大文字と小文字を区別していたのでしょうか。CPU の負荷が軽減されたためかもしれません。大文字と小文字が異なっていても、似たような名前のファイルがすでに存在するかどうかを確認するために CPU サイクルを消費する追加関数は必要ありません (また、ラテン語や英語以外のアルファベットでは、大文字と小文字を区別しない実装が簡単ではありません)。今日では、最新の超高速 CPU では、大した問題ではありません。