昨年発表されたLinux 5.2パッチノートを読んでパッチノートが始まったことがわかりました。ext4ファイルシステムで大文字と小文字を区別しない名前のオプションのサポート。
だから...カーネルに大文字と小文字を区別しないオプション（大文字と小文字の区別と正規化の両方）が必要な理由が気になります。私が見つけることができますその他の記事ケース折りたたみファイルシステムをサポートするカーネルコードを書いたKrismanによって書かれていますが、case-insensitive file system allows us to resolve important bottlenecks for applications being ported from other operating systems正規化とケース折りたたみプロセスによってディスクストレージを最適化する方法を理解することができないことは気になりませんでした。
あなたの助けに感謝します！
ベストアンサー1
大文字と小文字を区別しないファイルシステムを使用すると、他のオペレーティングシステムでアプリケーションを移植するときに発生する重大なボトルネックを解決できます。
正規化とケース折りたたみプロセスによってディスクストレージを最適化する方法を理解できるという事実は気に入らない。
ワイン、サンバ、アンドロイド持つ大文字と小文字を区別しないファイルシステムセマンティクスを提供します。デフォルトのファイルシステムが大文字と小文字を区別すると、すべての大文字と小文字の区別の検索が失敗します。 Wine et al。各ディレクトリをスキャンして大文字と小文字を区別しない一致がないことを証明する必要があります。たとえば、検索が失敗した場合は、すべてのファイルとすべてのディレクトリに対して完全なディレクトリ/foo/bar/readme.txtリストと大文字と小文字を比較する必要があります。foo/bar/*foo/*/*
これにはいくつかの問題があります。
- 深くネストされたパスは非常に遅くなる可能性があります。何百ものFS呼び出し）または数万のファイルを含むディレクトリ（例：SMBストレージによる増分バックアップ）。
- これらの検査では競合状態が発生します。
- 基本的に健全ではありません。と両方が
readme.txt存在しますREADME.txtが、アプリケーションがそれを必要とする場合、README.TXTどのファイルが返されるかは定義されません。
AndroidはFUSE / wrapfsを使用して大文字と小文字を区別し、カーネルを使用します。SDカードFS。しかし、SDCardFSは単にプロセスをカーネル空間に移動することで、すべてをより速くします†。それでもファイルシステムを通過する必要があり（したがってIOバインドされている）、競合状態が発生し、基本的に健全ではありません。したがって、Google が大文字と小文字を区別せず、廃止された F2FS の基本ディレクトリ別 F2FS 開発に資金を提供した理由SDカードFS。
過去には、VFSを介して大文字と小文字を区別しないクエリを有効にしようとしたことが何度もありました。 2018年の最近の試みでは、インストールが許可されました。ファイルシステムの大文字と小文字を区別しないビュー。 Ted Tsoは、この機能を追加するときに少なくとも高速で競合状態がないため、Wrapfs関連の問題に具体的に言及しました。しかし、それでも音は出ません（要求はORをREADME.TXT返すことがあります）。これは大文字と小文字を区別しないディレクトリ固有のサポートを追加することを拒否され、VFS††に統合される可能性はほとんどありません。readme.txtREADME.txt
また、ユーザーは大文字と小文字を区別しないことを期待しているため、すべての消費者向けオペレーティングシステムはこれを提供する必要があります。 Unicodeが存在せず、文字列は単なるバイトパケットであるため、Unix自体はそれをサポートできません。ケースの折りたたみがどのように処理されるかについて、多くの有効な批判があります。過去にしかし、Unicodeは不変 ケース折りたたみ機能これは、以下を除くすべての人に適用されます。単一ロケール（トルコ語はそれにもかかわらず、2つのコードポイントにすぎません）。しかもファイルシステムBツリーこの行為を犯す唯一の合理的な場所です。
†アジア情報通信技術協会
私は、VFSベースの大文字と小文字を区別しない照会と、EXT4とF2FSのディレクトリ固有の大文字と小文字を区別するサポートの作成者であるKrismanに電子メールを送信しました。