私が推測するのは
- EXT4やXFSなどのファイルシステム。チェックサムとともにブロックをディスク（ハードドライブまたはSSDのいずれか）に書き込みます。
- 再読み込み時に確認に失敗した場合読むこの操作はデータを返さず、エラーまたはEOF（またはデータなし）を示します。
- リブート時に（オペレーティングシステムのメモリページがフラッシュされない突然のシャットダウン後でも）、Linuxオペレーティングシステムはチェックサムを使用してファイルブロックの整合性を確認し、アプリケーションがこれらのエラーが検出されたブロックを読み取ろうとすると、ファイルの場合はLinuxオペレーティングシステムはチェックサムを使用してファイルブロックの整合性を確認します。部分の読む読み取りが上記のブロックに達すると、操作は失敗します。
- （Linuxオペレーティングシステムによって）検出された破損したブロックがファイルの中央にある場合。後続のブロックにエラーがなくても、破損したブロックに到達すると読み取り操作が失敗し、アプリケーションは破損したブロックの後のデータを読み取ることができません。
たとえば、ファイルサイズが4KBでブロックサイズが1KBであるとします。したがって、このファイルはA、B、C、Dの4つのブロックにわたって配布されます。 Linux がブロック C が破損していることを検出したとします。今読むこれにより、ファイルの最初の2 KBを処理できます。しかし、方法はありません。読むアプリケーションがファイルの場所を3KBの後に配置しても、最後の1KBです。
上記の仮定が正しい場合、[ファイルを操作する一部の侵入者はここでは考慮されません。]
- アプリケーションは、ファイルを書き込むときに独自のチェックサムを入力し、再読み込み時にそれを確認する必要はありません（OSが突然終了した後も）。
- アプリケーションは、提供されたデータが以下に由来するものと想定できます。読むもともと書かれたということです。起こりうる最悪の状況は、ファイルの末尾からデータを読み取ることができないことです。
これらの仮定は間違っていますか（OS = Linux RedHat Enterprise Linux 8.Xおよびファイルシステム= EXT4、XFSの文脈で）もしそうなら、何が間違っているのか教えてください。。
ベストアンサー1
EXT4やXFSなどのファイルシステム。チェックサムとともにブロックをディスク（ハードドライブまたはSSDのいずれか）に書き込みます。
いいえ、両方のファイルシステムにデータチェックサムはありません。
再読み込み時にチェックサムが失敗した場合、読み取り操作はデータを返さず、エラーまたはEOF（またはデータなし）を示します。
いいえ。前述したように、データチェックサムは実行されません。はいEOF、（間違っています！）はありませんが、EIOエラーコードが設定されます。
リブート時に（オペレーティングシステムのメモリページがフラッシュされない突然のシャットダウン後でも）、Linuxオペレーティングシステムはチェックサムを使用してファイルブロックの整合性を確認します。
いいえ。これはジャーナリング・ファイル・システムなので、通常、ファイル・システム全体のチェックサム・チェックは必要ありません。また、上記のように、両方のファイルシステムにデータチェックサムはありません（少なくともXFSにはファイルメタデータのチェックサムがあります）。
また、いいえ、オペレーティングシステムとしてのLinuxは、存在するチェックサム、さらにはデータチェックサムを含むファイルシステムに対してもボリュームチェックを実行しません。これには長い時間がかかり、ソフトウェアのインストールはユーザーに任せられる可能性が高くなります。破損したチェックサムは、ストレージデバイスにエラーが発生し始めたことを意味する可能性があることを考えると、これは得よりも多くの可能性があります。前述したように、最新のファイルシステムでは、完全なファイルシステムチェックはほとんど行われません。代わりにアクセス確認が一般的です。
アプリケーションがこれらのエラー検出ブロックを含むファイルを読み取ろうとすると、読み取りが上記のブロックに達すると読み取り操作が失敗します。
いいえ、データチェックサムがないためです。しかし、彼らが次のようになるとしましょう。
（Linuxオペレーティングシステムによって）検出された破損したブロックがファイルの中央にある場合。後続のブロックにエラーがなくても、破損したブロックに到達すると読み取り操作が失敗し、アプリケーションは破損したブロックの後のデータを読み取ることができません。
いいえ。私はLinuxとPOSIXがこれについて何も保証しないと思います。1GBseekを超えると、データチェックサムを持つファイルシステムの合理的なファイルシステムドライバは、チェックサムを確認するために1GBのデータを読み取ることはありません。したがって、あなたの家は間違っています。
たとえば、ファイルサイズが4KBでブロックサイズが1KBであるとします。したがって、このファイルはA、B、C、Dの4つのブロックにわたって配布されます。
XFSの仕組みに関する詳細はなく、通常ext4の仕組みの詳細もありません。範囲ベースの割り当てが何であるか疑問に思います。
Linux がブロック C が破損していることを検出したとします。
同様に、どのファイルシステムでも持つデータチェックサムは、Cを読み取るときにのみ発生します。遅れました。
これで、読み取り操作でファイルの最初の2 KBを提供できるようになりました。
なぜこれ以上行けないのですかfseek？
ただし、アプリケーションがファイルの場所を3KB以降に配置しても、最後の1KBを読み取ることはできません。
上記のように、これは間違っています。
しかし、
アプリケーションは、ファイルを書き込むときに独自のチェックサムを入力し、再読み込み時にそれを確認する必要はありません（OSが突然終了した後も）。
はい。ブロックデバイスの抽象化の代わりにデータの整合性をアプリケーションに委ねること悪い設計エラー。
ファイルシステムの鍵は、アプリケーションがデータを格納する物理メディアを知る必要がないことです。この抽象化によって、基礎となるハードウェアの醜い詳細が明らかにされないことは、アプリケーションがエラーの確率、発生する可能性のあるエラーの種類、および物理メディア上の場所を理解できないことを意味します。
ただし、重複した情報について情報に基づいて選択するには、これらすべてが必要です。
簡単に言うと：ファイルシステムを使用してブロックデバイスにデータを保存する場合、データの整合性を保証するのはアプリケーション層ではなくブロックデバイス層です。。
アプリケーションは、読み取りによって提供されたデータが元の書き込みデータであると仮定することができ、起こり得る最悪の状況は、ファイルの終わりからデータを読み取ることができないことです。
適用分野〜しなければならないファイルから読み取ったデータが正しいとします。そうしないと、アプリケーションが正しいか実行するすべての操作が正しいとは見なされません。繰り返しますが、これはファイルシステムがアプリケーションに提供する保証です。ファイルシステムを使用しているので、そうすることができます。
これらの仮定は間違っていますか（OS = Linux RedHat Enterprise Linux 8.Xおよびファイルシステム= EXT4、XFSの文脈で）それでは、どちらが間違っているのか教えてください。
上記のように、基本的にすべての仮定は間違っています。