Linux ext4 режимы работы журнала

Русские Блоги

Три режима журнала файловой системы Ext4 — журнал, упорядоченный, обратная запись

Непосредственно проверьте документацию, предоставленную ядром, например, linux-4.4.4:

linux-4.4.4\Documentation\filesystems\ext4.txt

В этом документе описаны три режима журналирования файловой системы ext4, как показано на рисунках 1 и 2:

Из содержания приведенного выше рисунка видно, что существуют три режима журнала:journal、ordered、writeback. Упорядоченный режим со знаком * — это режим по умолчанию.

1. journal

Режим data = journal обеспечивает полный журнал блоков данных и метаданных.Все данные сначала записываются в журнал, а затем записываются на диск (энергонезависимый носитель данных после сбоя питания). Когда файловая система выходит из строя, журнал можно воспроизвести, чтобы вернуть данные и метаданные в согласованное состояние.Производительность режима журнала является самой низкой среди трех режимов, потому что все данные должны записываться в журнал. Этот режим не поддерживает выделение и O_DIRECT.

2. ordered（*）

В режиме «данные = упорядоченный» файловая система ext4 предоставляет только журналы метаданных, но логически группирует информацию метаданных и блоки данных, связанные с изменениями данных, в единицу, называемую транзакцией. Когда метаданные необходимо записать на диск, сначала будет записан блок данных, связанный с метаданными. То есть сначала данные помещаются на диск, а затем регистрируются метаданные. При нормальных обстоятельствах производительность этого режима немного ниже, чем у режима обратной записи, но намного выше, чем у режима журнала.

3. writeback

В режиме data = writeback, когда метаданные отправляются в журнал, данные могут быть отправлены непосредственно на диск. То есть будут вестись журналы метаданных, данные не будут регистрироваться, и нет гарантии, что данные будут помещены на диск раньше метаданных. Обратная запись — лучший режим, предоставляемый ext4.

Источник

What kind of data is stored in the ext4 file system’s journal?

The ext4 file system has a feature called has_journal . In the dumpe2fs output, we can see something like this:

# 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 

So the journal is 32M in size, and it starts at the beginning of the file system. I know that the size of the journal depends on the size of the partition. I don’t remember the limits right now, but it’s not that big value. So what kind of data is stored in the journal? I’ve read once that if you want to secure remove a file from your disk (via shred ), you have to take into account the file system’s journal because it can store some information about the removed file. Is there a way to check what is in the journal? Are there any tools that can show the information?

2 Answers 2

The exact contents of the journal depend on how you have configured your ext4 file system. The official ext4 documentation says:

• writeback mode In data=writeback mode, ext4 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode — metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext4 performance.
• ordered mode In data=ordered mode, ext4 only officially journals metadata, but it logically groups metadata information related to data changes with the data blocks into a single unit called a transaction. When it’s time to write the new metadata out to disk, the associated data blocks are written first. In general, this mode performs slightly slower than writeback but significantly faster than journal mode.
• journal mode data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to its final location. In the event of a crash, the journal can be replayed, bringing both data and metadata into a consistent state. This mode is the slowest except when data needs to be read from and written to disk at the same time where it outperforms all others modes. Enabling this mode will disable delayed allocation and O_DIRECT support.

So you can have both metadata (e.g. file name) and actual data (i.e. file contents) residing in your journal file.

If you’re interested in details on the format in which transaction data is actually stored in the journal, you should refer to the respective header file:

There’s also a wiki page which explains how these structures are laid out on the disk:

There’s a packet in debian called sleuthkit , in which you have some tools like jls or jcat . The jls tool can list all journal entries of an ext4 file system, for example:

# 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) . 

And of course, there’s more entries depending on the size of the journal. In this case there was about 16382, most of which were empty. If you want to do something with the log, for instance, recover some file, you have to use jcat in order to extract the i-node block:

jcat grafi.img 8 10 > blok-161 

And inspect the single i-node. The block is 4096 bytes in size, and covers 16 i-nodes, each of which is 256 bytes long. Anyways in that way you can get the first block of an extent, the number of blocks in the extent, how many extents were used to describe that particular file, its size and other stuff like this. All you need to recover that file from the disk based only on the i-node entry that you got from the journal.

There’s also debugfs in e2fsprogs package. It has logdump tool, which is similar to the jls .

Источник