Que tipo de dados é armazenado no diário do sistema de arquivos ext4?

Question

O sistema de arquivos ext4 tem um recurso chamado has_journal . Na saída dumpe2fs , podemos ver algo assim:

# 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

Portanto, o diário tem 32 milhões de tamanho e começa no início do sistema de arquivos. Eu sei que o tamanho do diário depende do tamanho da partição. Não me lembro dos limites agora, mas não é um grande valor. Então, que tipo de dados é armazenado no diário?

Eu li uma vez que se você quiser proteger remover um arquivo do seu disco (via shred ), você deve levar em conta o diário do sistema de arquivos porque ele pode armazenar algumas informações sobre o arquivo removido. Existe uma maneira de verificar o que está no diário? Existem ferramentas que possam mostrar as informações?

    

Answer 1

O conteúdo exato da revista depende de como você configurou seu sistema de arquivos ext4. A documentação oficial do ext4 diz:

There are 3 different data modes:

• 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.

Assim, você pode ter os dois metadados (por exemplo, o nome do arquivo) e os dados reais (ou seja, o conteúdo do arquivo) que residem em seu arquivo de diário.

Se você tiver interesse em detalhes sobre o formato em que os dados da transação são realmente armazenados no diário, consulte o respectivo arquivo de cabeçalho:

link

Há também uma página wiki que explica como essas estruturas são dispostas no disco:

link

Existe um pacote no debian chamado sleuthkit , no qual você tem algumas ferramentas como jls ou jcat . A ferramenta jls pode listar todas as entradas de diário de um sistema de arquivos ext4 , por exemplo:

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

E, claro, há mais entradas dependendo do tamanho do diário. Nesse caso, havia cerca de 16382, a maioria dos quais estava vazia. Se você quiser fazer alguma coisa com o log, por exemplo, recuperar algum arquivo, você tem que usar jcat para extrair o bloco do i-node:

jcat grafi.img 8 10 > blok-161

E inspecione o único nó i. O bloco tem 4096 bytes e abrange 16 i-nodes, cada um dos quais é 256 bytes. De qualquer forma, você pode obter o primeiro bloco de uma extensão, o número de blocos na extensão, quantas extensões foram usadas para descrever esse arquivo em particular, seu tamanho e outras coisas como essa. Tudo o que você precisa para recuperar o arquivo do disco com base apenas na entrada do nó i que você obteve no diário.

Há também debugfs em e2fsprogs package. Tem logdump tool, que é semelhante ao jls .

    

Answer 2

Gostaria de referir a definição do sistema de arquivos de registro no diário (da Wikipédia) e esperamos que você obtenha a resposta:

A journaling file system is a file system that keeps track of changes not yet committed to the file system's main part by recording the intentions of such changes in a data structure known as a "journal", which is usually a circular log. In the event of a system crash or power failure, such file systems can be brought back online quicker with lower likelihood of becoming corrupted

Veja:

link e link

Para mais informações.