問題タブ [ext4]

ファイル システム Ext4 の機能の 1 つは、ここに記載されている新しいスケーラビリティ機能です。ソース コード レベルでどのような変更を加えれば、Ext3 では実現できなかった事実上無制限の数のサブディレクトリなど、Ext4 でこのような機能をサポートできるようになるのだろうと考えていました。カーネル ソース ツリーの関連する領域へのポインタをいただければ幸いです。

fs/ext4/ ソースで手がかりを見つけようとしましたが、まだできていません。

あまり大きくない (4kb、8kb など) 非常に多数のファイルを作成する必要があります。私のコンピューターでは、すべての inode を最大 100% 使用するため、これ以上ファイルを作成できません。

(ファイルを削除し始めたので、現在 67% です)

ノードあたりのバイト数は、私のファイルシステム (ext4) では 256 です。

この値を 128 未満でも非常に低く設定することは可能でしょうか (再フォーマット中)。はいの場合、どの値を使用すればよいですか? どうも

POSIXファイルシステムでファイルの名前を永続的に変更する正しい方法は何ですか？特にディレクトリのfsyncについて疑問に思っています。（これがOS / FSに依存する場合は、Linuxとext3 / ext4について質問しています）。

注：StackOverflowには、永続的な名前変更に関する他の質問がありますが、AFAICTではディレクトリのfsyncに対応していません（これは私にとって重要です-ファイルデータも変更していません）。

私は現在（Pythonで）持っています：

特定の質問：

• これも暗黙的にソースディレクトリをfsyncしますか？または、電源を入れ直した後、ファイルが両方のディレクトリに表示される可能性があります（つまり、ハードリンクカウントを確認して手動でリカバリを実行する必要があります）。つまり、永続的なアトミック移動操作を保証することは不可能ですか？
• 宛先ディレクトリの代わりにソースディレクトリをfsyncした場合、それは暗黙的に宛先ディレクトリもfsyncしますか？
• 関連する有用なテスト/デバッグ/学習ツール（フォールトインジェクター、イントロスペクションツール、モックファイルシステムなど）はありますか？

前もって感謝します。

ファイル名の長さは、ディスクの残りのストレージスペースにどのように影響しますか？

これはファイルシステムに依存していることに気づきました。特に、EXTシリーズのファイルシステムについて考えています。iノードがディスクスペースにどのように影響し、ファイル名自体がどのように保存されるかを完全には理解していません。この質問に関連する検索結果を取得することも困難です。だから私はここで尋ねています。Linuxでは、ファイル名の最大長は通常255文字または256文字です。ファイルシステムが作成されるとき、その量のスペースはすべてのファイル名に対して「予約」されていますか？つまり、最大値がすでに使用されているため、ディスクストレージは実際のファイル名の影響を受けませんか？それともそれよりも複雑ですか？

「joe.txt」という名前のファイルがあり、その名前を「joe2.txt」に変更するとします。この後、使用可能なディスク容量は減少しましたか？「joe_version.txt」や「joe_original_version_with_bug_that_Jim_solved.txt」のような長い名前はどうですか？8、16、32、64などの文字のしきい値が心配です。何百万もの画像を保存します。私はこれまでそのような問題について心配することを気にしたことがないので、これがどのように機能するのか完全にはわかりません。

私が使用しているファイルシステムはEXTだけですが、FATなどについて話し合うことは、同様の質問をしている他の人にとって役立つかもしれません。

更新：私は非常に愚かだったことがわかりました。アクセス時間を確認する必要があるのに、変更時間を確認していました。再現性がなかった理由は、テストファイルがで作成されたためですdd if=/dev/urandom of="$target" bs='1K' count=1 || exit 1。ほとんどの場合、新しいファイルの変更時間（の終わりdd）がアクセス時間（の開始時間）と異なるには速すぎましたdd。注意すべきもう一つのこと。

あるファイルのアクセス時間をプラス2年を別のファイルに適用するスクリプトに取り組んでいます。これは、、stat -c %xおよびdate --rfc-3339=nsを使用しtouch -a --date="$result"ます。stat両方ともdate、ナノ秒の日付文字列を出力します。

、そしてinfo coreutils 'touch invocation'それはナノ秒をサポートすると言います。ただし、タッチを適用すると、適用されたタイムスタンプと後でstatによって返されるタイムスタンプにわずかな違いがある場合があります。実際の実行からのデータは次のとおりです。

したがって、100回のテストのうち21回が失敗し、平均は3.938ミリ秒、中央値は4.001ミリ秒でした。これを引き起こす可能性のあるアイデアはありますか？

Tim Bray の記事"Saving Data Safely"は未解決の問題を残しました。今日、それは 1 か月以上経ちましたが、フォローアップが見られなかったので、ここでトピックを扱うことにしました。

この記事のポイントの 1 つは、FileOutputStream を使用する場合、安全のために FileDescriptor.sync() を呼び出す必要があることです。Java を 12 年間やっている間、Java コードが同期しているのを見たことがなかったので、最初はとてもイライラしました。特に、ファイルへの対処はかなり基本的なことです。また、FileOutputStream の標準 JavaDoc は、同期をほのめかしませんでした (Java 1.0 - 6)。いくつかの調査の結果、ext4 が実際に同期を必要とする最初のメインストリーム ファイル システムである可能性があることがわかりました。(明示的な同期が推奨される他のファイル システムはありますか?)

この件についての一般的な考えに感謝しますが、具体的な質問もいくつかあります。

1. Android はいつファイル システムと同期しますか? これは定期的であり、さらにライフ サイクル イベントに基づいている場合もあります (たとえば、アプリのプロセスがバックグラウンドに移行するなど)。
2. FileDescriptor.sync() はメタデータの同期を処理しますか? つまり、変更されたファイルのディレクトリを同期しています。FileChannel.force() と比較してください。
3. 通常、FileOutputStream に直接書き込むことはありません。これが私の解決策です（同意しますか？）： /code>