Journaling

Journaling é uma técnica para se recuperar de uma queda ou falta de energia sem varrer um volume inteiro atrás do dano. O ext2 não tem técnica nenhuma assim: registra um campo de state para detectar um volume desmontado de forma não limpa, deixado no meio de uma escrita, e depois depende de uma passagem completa de fsck sobre o volume inteiro para encontrar e corrigir o que a interrupção deixou inconsistente. ext3 e ext4, entre outros sistemas de arquivos posteriores, adotaram journaling especificamente para evitar essa varredura completa, mudando como uma escrita chega ao disco em primeiro lugar em vez de apenas reagir depois do fato.

Write-ahead logging

A ideia central é write-ahead logging: antes de uma mudança ser aplicada às estruturas principais de um sistema de arquivos no disco (uma tabela de inodes, um bitmap, um bloco de diretório), a intenção dessa mudança é primeiro escrita numa região de journal separada e sequencial, reservada especificamente para esse propósito. Só depois que essa entrada de journal está seguramente no disco o sistema de arquivos segue em frente para aplicar a mudança real às suas estruturas principais; se uma queda acontece entre essas duas etapas, o journal ainda contém um registro completo e autocontido do que deveria ter acontecido, em vez de estruturas principais deixadas em algum estado parcial desconhecido sem registro algum do que estava em andamento.

1. Escreve intenção no journal:  "atualiza inode 42: tamanho 4096 -> 8192"
2. Entrada de journal commitada (fsync'd, marcada como completa)
3. Aplica a mudança real ao inode 42 nas estruturas principais do sistema de arquivos
4. Marca a entrada de journal como checkpointed (não mais necessária para recuperação)

Uma entrada de journal tipicamente agrupa toda mudança pertencente a uma operação lógica (uma renomeação de arquivo tocando uma entrada de diretório e possivelmente um inode) numa única transação, commitada no journal como uma única unidade atômica em vez de várias escritas independentes que poderiam elas mesmas ser interrompidas no meio, o que é o que permite à técnica garantir que a recuperação só nunca vê uma transação como totalmente presente ou totalmente ausente do journal, nunca meio registrada.

Recuperação

Como o journal já contém um registro completo e ordenado da intenção de toda mudança recente, a recuperação depois de um desligamento não limpo tem uma quantidade específica e limitada de trabalho a fazer em vez de uma varredura aberta do volume inteiro: reproduzir toda transação commitada que ainda não tinha sido checkpointed para as estruturas principais, e descartar qualquer transação que só tinha sido parcialmente escrita no próprio journal quando a queda ocorreu (detectável porque uma transação faz commit com um marcador específico só depois que toda parte dela chegou ao disco). Essa é a melhoria concreta que journaling traz sobre a abordagem do ext2: o custo de recuperação escala com o quanto foi registrado no journal desde o último checkpoint, tipicamente uma janela pequena e recente, em vez de com o tamanho do volume inteiro da forma que uma passagem completa de fsck faz, já que só o próprio journal precisa ser lido e reproduzido.

O que é registrado no journal

Journaling só de metadados, o modo padrão para ext3 e ext4, protege as estruturas de contabilidade do próprio sistema de arquivos (inodes, bitmaps, entradas de diretório) mas não necessariamente os blocos de dados de arquivo que uma escrita de fato está modificando, o que significa que uma queda ainda pode deixar o conteúdo de um arquivo num estado inconsistente mesmo que a própria estrutura do sistema de arquivos descrevendo esse arquivo permaneça consistente e montável. Journaling completo de dados adicionalmente escreve os dados reais de arquivo através do journal antes de chegarem ao local final, dando garantias mais fortes sobre os próprios dados sobreviverem a uma queda, a um custo real de desempenho: todo byte de dado de arquivo é efetivamente escrito no disco duas vezes, uma no journal e uma no local final, em vez de uma vez. A maioria dos deployments de propósito geral usa journaling só de metadados como padrão especificamente porque essa troca, consistência estrutural garantida sem dobrar o tráfego comum de escrita, é o que a maioria das cargas de trabalho de fato precisa; uma carga de trabalho onde perder conteúdo de arquivo recém-escrito é genuinamente inaceitável é para o que journaling completo de dados existe.

Notas de implementação

O próprio journal é uma região reservada e de tamanho fixo do volume, dimensionada e alocada uma vez (frequentemente na criação do sistema de arquivos), e tratada de forma especial pelo código do sistema de arquivos: precisa ser escrito sequencialmente e suas próprias escritas precisam chegar ao disco numa ordem bem definida em relação ao marcador de commit da transação, já que um sistema de arquivos que reordena ou atrasa escritas de journal da mesma forma que poderia reordenar escritas comuns de dados por desempenho anularia a garantia da técnica inteira. Um journal que enche antes de suas entradas mais antigas terem sido checkpointed para as estruturas principais também precisa forçar esses checkpoints a acontecer (ou bloquear novas escritas) em vez de silenciosamente sobrescrever entradas de journal ainda necessárias, já que um sistema de arquivos que cai nesse ponto com um journal corrompido ou sobrescrito perde exatamente a rede de segurança que o mecanismo inteiro existe para fornecer.

Referências

^ S. Tweedie, “Journaling the Linux ext2fs Filesystem,” LinuxExpo, 1998: o artigo de design original introduzindo a camada de journaling do ext3 sobre o formato em disco já existente do ext2.
^ M. Rosenblum e J. Ousterhout, “The Design and Implementation of a Log-Structured File System,” ACM Transactions on Computer Systems, 1992: um tratamento antigo e influente de write-ahead logging aplicado à estrutura de um sistema de arquivos inteiro.

Ver também

ext2: o formato sem journaling cujas limitações de recuperação de falhas motivam este artigo.
VFS: a camada que permanece idêntica para chamadores independentemente de o sistema de arquivos por baixo ter journaling ou não.
Buffer Cache: a lacuna mais estreita que journaling de fato fecha, em contraste com o que um bloco dirty ainda não vazado neste cache continua exposto.