web-dev-qa-db-ja.com

ジャーナルの「削除されたファイル」エントリはどのように表示されますか

私はこれが正しいことを願っています：ファイルのinodeには、iノード番号、最終変更時刻、所有権などのデータと、エントリ："削除時間"。それは私を興味深くさせました：
ファイルの削除は、ファイルのiノードnumberを削除することを意味し、ファイルにリンクされているストレージスペースを使用可能としてマークします。削除されたファイルを（誤って）回復するためのツールがあります（たとえば、利用可能な場合はジャーナルから）。そして、私はstatコマンドを知っています。

質問

「削除されたファイル」エントリはジャーナルでどのように表示されますか？

私の推測では、statコマンドが発行された場合など、非常に見栄えの悪い出力です。

ファイルを削除して復元しようとするのは直接の経験になることはわかっていますが、外部の助けなしにこれを実行できる段階ではなく、自分が何をしているのかを正確に理解したいと思います。私は基本的なことをしっかりと把握しようとしているので、データの復活に入るのは今のところ私にとっては脇道です...私は怠惰ではありません、これは宿題ではありません、これは私的な研究のためです。

filesystemsinodejournaling
7
erch

ファイルまたはディレクトリが「削除」されると、そのiノード番号がファイルを含むディレクトリから削除されます。 treeコマンドを使用すると、特定のディレクトリに含まれるiノードのリストを確認できます。

例

$ tree -a -L 1 --inodes .
.
|-- [9571121]  dir1
|-- [9571204]  dir2
|-- [9571205]  dir3
|-- [9571206]  dir4
|-- [9571208]  dir5
|-- [9571090]  file1
|-- [9571091]  file2
|-- [9571092]  file3
|-- [9571093]  file4
`-- [9571120]  file5

5 directories, 5 files

リンク

ハードリンクがどのように機能するかを理解することが重要です。このチュートリアルのタイトルは次のとおりです。 iノードの概要 iノードの動作の基本的な理解を始めたばかりの場合は、優れた詳細があります。

抜粋

Iノード番号は一意ですが、一部のファイル名とiノード番号のリストに同じ番号のファイルが表示されていることに気付いたかもしれません。重複はハードリンクによって引き起こされます。ファイルが複数のディレクトリにコピーされると、ハードリンクが作成されます。同じファイルが、同じストレージユニットのさまざまなディレクトリに存在します。ディレクトリリストには、同じ番号の2つのファイルが表示され、それらが同じ物理上のストレージユニットにリンクされています。ハードリンクを使用すると、同じファイルを複数のディレクトリに「存在」させることができますが、物理ファイルは1つしか存在しません。その後、ストレージユニットのスペースが節約されます。たとえば、1メガバイトのファイルが2つの異なるディレクトリに配置されている場合、ストレージで使用されるスペースは2メガバイトではなく1メガバイトです。

削除

同じチュートリアルには、iノードが削除されたときに何が起こるかについても書かれています。

ファイルを削除すると、サイズがゼロになり、直接/間接ブロックエントリがゼロになり、ストレージユニットの物理スペースが未使用として設定されます。ファイルの削除を元に戻すには、メタデータが使用されている場合はジャーナルから復元されます（ ジャーナル記事 を参照）。メタデータが復元されると、ストレージユニットで物理データが上書きされない限り、ファイルに再びアクセスできるようになります。

エクステント

エクステントとその機能についてもブラッシュアップすることをお勧めします。再びlinux.orgサイトから、次のタイトルの別の優れたチュートリアル： Extents は、基本を理解するのに役立ちます。

コマンドfilefragを使用して、特定のファイル/ディレクトリが使用しているエクステントの数を特定できます。

例

$ filefrag dir1
dir1: 1 extent found

$ filefrag ~/VirtualBox\ VMs/CentOS6.3/CentOS6.3.vdi 
/home/saml/VirtualBox VMs/CentOS6.3/CentOS6.3.vdi: 5 extents found

-vスイッチを使用すると、より詳細な出力を取得できます。

$ filefrag -v dir1
Filesystem type is: ef53
File size of dir1 is 4096 (1 block of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       0:   38282243..  38282243:      1:             eof
dir1: 1 extent found

注：ディレクトリは常に最小4Kバイトを消費することに注意してください。

ファイルにある程度のサイズを与える

サンプルファイルの1つを取得して、次のように1MBのデータを書き込むことができます。

$ dd if=/dev/zero of=file1 bs=1k count=1k
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 0.00628147 s, 167 MB/s

$ ll | grep file1
-rw-rw-r--. 1 saml saml 1048576 Dec  9 20:03 file1

filefragを使用してこのファイルを分析すると、次のようになります。

$ filefrag -v file1
Filesystem type is: ef53
File size of file1 is 1048576 (256 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     255:   35033088..  35033343:    256:             eof
file1: 1 extent found

ファイルをすばやく削除して再作成する

実行できる興味深い実験の1つは、上記のfile1などのファイルを作成し、それを削除してから再作成することです。何が起こるか見てください。ファイルを削除した直後に、dd ...コマンドを再実行すると、file1がfilefragコマンドに次のように表示されます。

$ filefrag -v file1
Filesystem type is: ef53
File size of file1 is 1048576 (256 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     255:          0..       255:    256:             unknown,delalloc,eof
file1: 1 extent found

少し時間が経つと（数秒から数分が経過します）：

$ filefrag -v file1
Filesystem type is: ef53
File size of file1 is 1048576 (256 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     255:   38340864..  38341119:    256:             eof
file1: 1 extent found

ファイルがついに表示されます。ここで何が起こっているのか完全にはわかりませんが、ファイルの状態がジャーナルとディスクの間で安定するまでには時間がかかるようです。 statコマンドを実行すると、iノードを含むファイルが表示されるのでそこにありますが、filefragが使用するデータは解決されていないため、少し不安定な状態になっています。

6
slm

ファイルの削除には、いくつかの手順が含まれます。

  1. ディレクトリ内の名前を削除済みとしてマークします
  2. Iノードのリンクカウントをデクリメントします
  3. リンク数がゼロになった場合は、削除時刻を設定して
  4. ビットマップでデータブロックを空きとしてマークします

したがって、ジャーナルはこのシーケンスの「ように見えます」。

0
psusi