web-dev-qa-db-ja.com

ext4ファイルシステムのジャーナルにはどのようなデータが保存されますか？

ext4ファイルシステムには、has_journalという機能があります。 dumpe2fsの出力では、次のように表示されます。

# 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を介してディスクからファイルを安全に削除したい場合は、削除されたファイルに関する情報を保存できるため、ファイルシステムのジャーナルを考慮する必要があることを一度読んだことがあります。ジャーナルの内容を確認する方法はありますか？情報を表示できるツールはありますか？

filesystemssecurityhard-disk
5
Mikhail Morfikov

ジャーナルの正確な内容は、ext4ファイルシステムの構成方法によって異なります。 公式ext4ドキュメント はこう言っています：

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

  • 書き戻しモードdata = writebackモードでは、ext4はデータをジャーナルしません。このモードは、デフォルトモードのメタデータジャーナリングで、XFS、JFS、およびReiserFSと同様のレベルのジャーナリングを提供します。クラッシュ+リカバリにより、クラッシュの直前に書き込まれたファイルに誤ったデータが表示される可能性があります。このモードは、通常、ext4の最高のパフォーマンスを提供します。

  • 順序付きモードdata = orderedモードでは、ext4はメタデータを正式にジャーナルするだけですが、データブロックに関連するデータ変更に関連するメタデータ情報を、トランザクションと呼ばれる単一のユニットに論理的にグループ化します。新しいメタデータをディスクに書き込むときは、関連するデータブロックが最初に書き込まれます。一般に、このモードは、ライトバックよりわずかに遅く実行されますが、ジャーナルモードより大幅に高速です。

  • ジャーナルモードdata = journalモードは、完全なデータとメタデータのジャーナリングを提供します。すべての新しいデータは、最初にジャーナルに書き込まれ、次に最終的な場所に書き込まれます。クラッシュが発生した場合、ジャーナルを再生して、データとメタデータの両方を一貫した状態にすることができます。このモードは、データの読み取りと書き込みを同時に行う必要がある場合を除き、最も低速で、他のすべてのモードよりもパフォーマンスが優れています。このモードを有効にすると、遅延割り当てと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

Debianにはsleuthkitというパケットがあり、jlsやjcatなどのツールがいくつかあります。 jlsツールは、ext4ファイルシステムのすべてのジャーナルエントリを一覧表示できます。次に例を示します。

# 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を使用してiノードブロックを抽出する必要があります。

jcat grafi.img 8 10 > blok-161

そして、単一のiノードを検査します。ブロックのサイズは4096バイトで、16 iノードをカバーしています。各i_nodeの長さは256バイトです。とにかく、そのようにして、エクステントの最初のブロック、エクステント内のブロック数、特定のファイルを記述するために使用されたエクステントの数、そのサイズ、およびこのような他のものを取得できます。ジャーナルから取得したiノードエントリのみに基づいて、ディスクからファイルを回復するために必要なすべてのこと。

e2fsprogsパッケージにはdebugfsもあります。 logdumpに似たjlsツールがあります。

12
Dmitry Grigoryev

（wikipediaからの）ジャーナリングファイルシステムの定義を参照したいと思います。うまくいけば、答えが得られます。

ジャーナリングファイルシステムは、そのような変更の意図を、通常は循環ログである「ジャーナル」と呼ばれる「ジャーナル」と呼ばれるデータ構造に記録することにより、ファイルシステムの主要部分にまだコミットされていない変更を追跡するファイルシステムです。システムクラッシュや電源障害が発生した場合、そのようなファイルシステムは、破損する可能性を低くして、迅速にオンラインに戻すことができます。

参照する：

https://en.wikipedia.org/wiki/Ext4#Features および https://en.wikipedia.org/wiki/Journaling_file_system#Logical_journals

詳細については。

0
Svetlin Tonchev