ext4 ファイルシステムのログにはどのような種類のデータが保存されますか?

ext4 ファイルシステムのログにはどのような種類のデータが保存されますか?

ファイルext4システムにはという名前のファイルシステムがありますhas_journaldumpe2fs出力に次のような内容が表示されます。

# dumpe2fs /dev/sda2 | grep -i journal
Journal inode:            8
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             32M
Journal length:           8192
Journal sequence:         0x00000662
Journal start:            1

したがって、ログサイズは32Mで、ファイルシステムの先頭から始まります。ログのサイズはパーティションのサイズによって異なります。今は限度がいくらだったのか覚えていませんが、あまり価値がありませんでした。では、ログにはどのようなデータが保存されますか?

ディスクからファイルを安全に削除するには、削除されたshredファイルに関する情報を保存できるファイルシステムのログを考慮する必要があることを読んだことがあります。日記の内容を確認する方法はありますか?この情報を表示するためのツールはありますか?

ベストアンサー1

ログの正確な内容は、ext4ファイルシステムの構成方法によって異なります。これext4公式文書説明する:

3つのデータモードがあります。

  • Writebackモードdata = writebackモードでは、ext4はデータをまったく記録しません。このモードは、XFS、JFS、およびReiserFSのデフォルトモードであるメタデータロギングと同様のロギングレベルを提供します。競合+回復により、競合の直前に作成されたファイルのデータが正しくない可能性があります。このモードは通常最高のext4パフォーマンスを提供します。

  • Orderedモードdata = orderedモードでは、ext4は形式的にメタデータのみを記録しますが、データブロックを使用して、データ変更に関連するメタデータ情報をトランザクションという単一の単位に論理的にグループ化します。新しいメタデータをディスクに書き込む必要がある場合は、関連するデータブロックが最初に書き込まれます。通常、このモードは書き込み保存より少し遅くなりますが、ログモードよりはるかに高速です。

  • ジャーナルモードデータ=ジャーナルモードは、完全なデータとメタデータのロギングを提供します。すべての新しいデータは最初にログに書き込まれ、最後の場所に書き込まれます。競合が発生した場合は、ログを再生してデータとメタデータを一貫した状態にすることができます。このモードは、データをディスクから同時に読み書きする必要がある場合を除いて、最も遅いです。この場合、他のすべてのモードよりも優れています。このモードを有効にすると、遅延割り当てとO_DIRECTサポートが無効になります。

したがって、メタデータ(ファイル名など)と実際のデータ(ファイルの内容など)の両方がログファイルに存在する可能性があります。

トランザクションデータが実際にログに格納されている形式の詳細に興味がある場合は、そのヘッダーファイルを参照する必要があります。

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/jbd2.h

これらの構造がディスクにどのように配置されるかを説明するWikiページもあります。

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout

またはsleuthkit同じツールを持つDebianというパッケージがあります。このツールは、ファイルシステムのすべてのログエントリを一覧表示できます。たとえば、次のようになります。jlsjcatjlsext4

# jls grafi.img

JBlk    Description
0:      Superblock (seq: 0)
sb version: 4
sb version: 4
sb feature_compat flags 0x00000000
sb feature_incompat flags 0x00000000
sb feature_ro_incompat flags 0x00000000
1:      Allocated Descriptor Block (seq: 2)
2:      Allocated FS Block 161
3:      Allocated Commit Block (seq: 2, sec: 1448889478.49360128)
4:      Allocated Descriptor Block (seq: 3)
5:      Allocated FS Block 161
6:      Allocated Commit Block (seq: 3, sec: 1448889494.3355841024)
7:      Allocated Descriptor Block (seq: 4)
8:      Allocated FS Block 145
9:      Allocated FS Block 1
10:     Allocated FS Block 161
11:     Allocated FS Block 129
12:     Allocated FS Block 8359
13:     Allocated FS Block 8353
14:     Allocated FS Block 0
15:     Allocated FS Block 130
16:     Allocated Commit Block (seq: 4, sec: 1448889528.3540304896)
...

もちろん、ジャーナルのサイズによってはより多くの項目があるでしょう。この場合、約16382個ありますが、ほとんどが空です。一部のファイルの復元など、一部の操作をログで実行するには、jcat次のコマンドを使用してinodeブロックを抽出する必要があります。

jcat grafi.img 8 10 > blok-161

単一のiノードを確認してください。ブロックの4096サイズはバイト単位で、16iノードを含み、各i256ノードは長さバイトです。いずれにせよ、この方法を使用すると、範囲の最初のブロック、その範囲内のブロック数、特定のファイルを記述するために使用される範囲の数、サイズ、およびその他の同様の情報を取得できます。ログから取得したi-nodeエントリに基づいてディスクからファイルを復元できます。

debugfsそれはまた包装に含まれていますe2fsprogslogdumpに似たツールがありますjls

おすすめ記事