14

Linuxにファイル インデックス データベースがあります。現在、ファイルパスを識別子として使用しています。しかし、ファイルが移動/名前変更された場合、そのパスが変更され、DB レコードを新しいファイルに一致させることができず、レコードを削除/再作成する必要があります。さらに悪いことに、ディレクトリが移動/名前変更された場合、すべてのファイルとネストされたディレクトリのレコードを削除/再作成する必要があります。

一意のファイル識別子としてinode番号を使用したいのですが、ファイルを削除して別のファイルを作成すると、inode 番号を再利用できます。

{inode,crtime}では、一意のファイル識別子として のペアを使用できるかどうか疑問に思っています。ext4 では i_crtime を、NTFS では creation_time を使用したいと考えています。私の限定的なテスト (ext4 を使用) では、同じファイル システム内でファイルやディレクトリの名前を変更したり移動したりしても、inode と crtime は変更されません。

したがって、問題は、ファイルの inode または crtime が変更される場合があるかどうかです。たとえば、fsck、最適化、またはパーティションのサイズ変更によって、inode、crtime、またはファイルが変更される可能性がありますか?

http://msdn.microsoft.com/en-us/library/aa363788%28VS.85%29.aspxが言う興味深い :

  • " NTFS ファイル システムでは、ファイルは削除されるまで同じファイル ID を保持します。 "
    さらに:
  • "場合によっては、ファイルのファイル ID が時間の経過とともに変化することがあります。 "

それで、彼らが言及したそれらのケースは何ですか？

私は同様の質問を研究したことに注意してください：

しかし、彼らは私の質問に答えません。

4

3 に答える 3

5

Unix での i ノードの割り当てと管理は、ファイルシステムに依存しています。そのため、ファイルシステムごとに答えが異なる場合があります。

Ext3 ファイルシステム (最も一般的) の場合、i ノードは再利用されるため、一意のファイル識別子として使用することも、予測可能なパターンに従って再利用を行うこともできません。

Ext3 では、i ノードはビット ベクトルで追跡され、各ビットは単一の i ノード番号を表します。i ノードが解放されると、そのビットはゼロに設定されます。新しい i ノードが必要な場合、ビット ベクトルで最初のゼロ ビットが検索され、i ノード番号 (以前に別のファイルに割り当てられている可能性があります) が再利用されます。

これは、最小番号の使用可能な i ノードが再利用されるという素朴な結論につながる可能性があります。ただし、Ext3 ファイル システムは複雑で高度に最適化されているため、i ノード番号がいつ、どのように再利用されるかについては、たとえ再利用されることが明らかであっても、想定する必要はありません。

iノードが割り当てられているialloc.cのソースコードから：

i ノードの割り当てには 2 つのポリシーがあります。新しい i ノードがディレクトリの場合、空き領域があり、ディレクトリと i ノードの比率が低いブロック グループを前方検索します。それが失敗した場合は、平均以上の空き容量を持つグループのうち、ディレクトリが最も少ないグループが選択されます。他の inode については、親ディレクトリのブロック グループから前方に検索して、空いている inode を見つけます。

Ext3 でこれを管理するソース コードは ialloc と呼ばれ、最終版はこちら: https://github.com/torvalds/linux/blob/master/fs/ext3/ialloc.c

于 2014-08-28T23:42:27.003 に答える
-1

dBアプリケーションは、ファイルがバックアップから復元される場合を考慮する必要があると思います。これにより、ファイルのcrtimeは保持されますが、inode番号は保持されません。

于 2019-04-07T07:47:36.170 に答える