Journaling File System
Sabrina Kappann da Silva
Departamento de Computação e Matemática – Faculdade de Filosofia, Ciências e Letras
Universidade de São Paulo – Ribeirão Preto, São Paulo, Brasil
Resumo. Este artigo traz aspectos gerais de um funcionamento de um
“journaled file system”, com ênfase no ext3, e a comparação deste com o
UNIX file system com seu processo do fsck.
1. Introdução
Um file system gerencia um conjunto de estruturas para lidar com arquivos, diretórios e
seus metadados (dados sobre os dados armazenados). Além disso, deve garantir que os
arquivos sejam persistentes, mesmo com possíveis falhas de software ou hardware, tais
como queda de energia, mal funcionamento dos equipamentos físicos ou programas
“crashados”. Nesse sentido, o Journaled File System (JFS), de forma breve, ‘anota’ tudo
o que é feito, para que possa ser recuperado.
Ao modificar um arquivo, por exemplo, é preciso, também, escrever 3 coisas: o inode
(que guarda metadados dos arquivos e sua localização no bloco), bitmap (indica que um
bloco e inode foi alocado), e um bloco de conteúdo (que escreve efetivamente o
conteúdo em disco). Um problema conhecido como “crash-consistency” acontece
porque não é possível dar um append no arquivo e escrever o inode, bitmap e novo
bloco no disco atômicamente, e erros podem acontecer enquanto atualizam-se essas
informações. Uma solução para isso é o Journaled File System (JFS). Aqui, será
abordado o JFS aplicado no ext3 do Linux.
O primeiro JFS foi lançado em 1990 pela IBM, mas atualmente o ext3 (“third extended
file system”)
é o mais popular nesse sentido, utilizado desde 2001. Foi criado para
manter a compatibilidade do ext2 mas, ao mesmo tempo, trazer inovações como o fato
de ser journaled.
2. Aspectos Técnicos
2.1. Conceitos iniciais e inconsistência de dados
Para escrever um novo bloco de memória, o bitmap (que aloca blocos e relaciona-os com
números de inode) e o inode bitmap também devem ser atualizados. Um inode (index node) é
uma estrutura que tem metadados dos arquivos, tais como tipo, tamanho, permissões e última
modificação. Dado um inumber (número de inode), você sabe em qual inode está localizado e,
com isso, sabe em qual bloco o arquivo está. A tabela 1 mostra os casos onde uma (ou mais)
dessas três estruturas deixam de ser escritas - o “sim” ou “não” indica se a estrutura foi, ou não,
escrita no journal.
Inode
Bitmap
DataBlock
Problema
não
não
sim
O conteúdo é escrito em disco, mas não há inode apontando para
