iノード番号のシーケンスはどのように機能しますか？異なるコンピューターへの同一のインストール間で一貫性を期待できますか？
A、B、Cの3台のコンピューターがあり、それらに同じオペレーティングシステムとソフトウェアのインストールを実行します。 A上の特定のファイルについて、BとC上の同じファイルが、そのファイルのインスタンスに対して同じiノード番号を持つことを期待できますか？
私たちの侵入検知システムは、Aから最初のファイルシステムイメージを取得し、同じファイルシステムイメージを使用してA、B、Cとの将来の比較を行うことでセットアップされています。私はプログラムに不慣れですが、これは機能しているようです。過去には。
Iノード番号のシーケンスがどのように機能するかわからないので、1から始まり、ファイルごとにカウントアップするか、または同様のものだと思います。その場合は、これまで、ファイルのiノード番号がコンピューター間でも一貫していたのはそのためです。同じファイルが同じ順序で作成されていました。いつでも頼りにできるかどうかはわかりませんが。
ただし、現在、いくつかのファイルが変更されたという通知を受け取っています。最初のファイルについて調べているのは、変更されたファイルのiノード番号だけです。誰かが通知とともにオペレーティングシステムとソフトウェアをコンピューターに再インストールしたと思います。
ファイルのiノード番号は、異なるコンピューターへの同一のOS /ソフトウェアのインストール（または同じコンピューターへの順次再インストール）で同じであると見なすことができますか？
A、B、またはCのいずれかから新しいファイルシステムイメージを取得する場合、「問題」が修正されることを期待できますか（問題かどうかさえわかりません）。
私は通常、一度に1台または2台のコンピューターにしかアクセスできないため、現在AまたはCを検査することはできず、それらのレポートがどのようになるかわかりません。コンピューターBの少なくとも1つのファイルのiノード番号が予想されたものではないことを知っているだけです。
この場合、オペレーティングシステムはQNX 6です。ファイルシステムタイプの場合、mountは、/ dev/hdファイルが "on/type qnx4"であることを示します...ファイルシステムタイプqnx4？ qnxには独自のファイルシステムタイプがあると思いますか？気づかなかった。あるいは、それは正確ではないかもしれません。ファイルシステムの種類を確認するための他のコマンドがコンピュータに存在しないようです。
更新：どうやら私は何かについて間違っていたようです。ファイルシステムの元の状態に関する参照データにはファイルのiノード番号が含まれており、それをテストに含めるオプションがありますが、質問で説明したこのチェックにiノードデータを含めることは想定されていませんでした。 「過去に働いた」のはこのためです。ですから、結局、ここで求めたものは実際には必要ありません。申し訳ありません。私はまだそれが面白いと思い、コメントで部分的な答えが始まっているので、私はこの質問を開いたままにしておきます。
[...]そして私はそれらに同じオペレーティングシステムとソフトウェアのインストールを実行します。
A上の特定のファイルについて、BとC上の同じファイルが、そのファイルのインスタンスに対して同じiノード番号を持つことを期待できますか？
いいえ、I/Oは並行して実行され、I/O操作の順序は決定論的ではなく、ハードウェアの動作に影響されるためです。 OSはiノード番号を割り当てます。たとえばシステムAとBで一部の操作が異なる順序で実行される場合、OSは「同じ」ファイルに異なるiノード番号を割り当てる可能性があります。
同様のアーティファクトは、同じシステムであっても、/dev/の割り当てが再起動間で一貫していることが保証されないことです。/dev/sdbは、前回の起動時に/dev/sdaであった可能性があります。
A、B、またはCのいずれかから新しいファイルシステムイメージを取得する場合、「問題」が修正されることを期待できますか（問題かどうかさえわかりません）。
これは問題ではありません（1つにしない限り）。もちろん、ファイルシステムイメージ全体をコピーすると、同じiノード番号になります。
ファイルシステムの元の状態に関する参照データにはファイルのiノード番号が含まれており、それをテストに含めるオプションがありますが、質問で説明したこのチェックにiノードデータを含めることは想定されていませんでした。
丁度。答えは「いいえ、信頼できないので、テストしないでください。問題になるからです」です。