Introdução Sistemas Operacionais Sistemas de arquivos estruturados em log e jornalizados Trabalho sob a Licença Atribuição-SemDerivações-SemDerivados 3.0 Brasil Creative Commons. Para visualizar uma cópia desta licença, visite http://creativecommons.org/licenses/by-nc-nd/3.0/br/ Aula 14 Sistemas de arquivos apresentam questões quanto: Desempenho no acesso Confiabilidade (contra perdas e contra inconsistências) Eistem soluções em Hardware: configurações RAID Software: Log Structured File System e Jornalizados As soluções de hardware e software atuam de forma diferente para atender os requisitos de desempenho e confiabilidade Não são equivalentes Sistemas Operacionais 2 O problema de desempenho... eemplo Uma solução para o problema de desempenho... Escrever em um bloco de dados Ler i-node do diretório (para acessar o diretório) Ler o bloco de dados do diretório (para buscar a entrada do arquivo) Ler o i-node do arquivo (para poder acessar /atualizar o arquivo) Ler o bloco de dados do arquivo Escrever o bloco de dados no arquivo Pelo menos 4 escritas Escrever o bloco de dados do diretório (atualização da entrada do diretório) Escrever o i-node do arquivo (atualização de timestamps) Escrever o i-node do diretório (atualização de timestamps) Se fosse um novo bloco ainda haveria atualizações do bitmap de livres Implica em reposicionamento e em escritas de pequenas porções de dados (i-nodes) Utilizar cache em memória, mas... Aumenta chance de perda de dados e inconsistência do sistema de arquivos Inconsistência quando metadados em memória são modificados em relação aos valores que estão no disco Metadados podem ser escritos de forma síncrona (lento) A escrita de blocos dados no disco contínua a ser de forma assíncrona e lenta Lembrando que consistência... é vinculada a cada partição significa manter as invariantes do sistema garante a coerência dos metadados (lista de i-nodes, blocos livres, etc) garantia da consistência NÃO é sinônimo de garantia da integridade dos arquivos Sistemas Operacionais 3 Sistemas Operacionais 4
Log Structured File Systems Problemas com Log Structured File Systems Proposto por John Ousterhout, Fred Douglis (1998) e implementado por Mendel Rosenblum e J. Oustrhout no sistema distribuído Sprite (1991) Principio básico: Agrupar em memória as escritas que seriam pequenas e randômicas e fazê-las de uma única vez de forma sequencial (segmentos) Segmento pode possuir i-nodes, blocos de dados, blocos de diretório e bitmaps misturados em qualquer ordem O segmento é gravado no final do log (evita seeks) Se grande, maimiza a largura de banda de transferência (MB/s) Implementação baseada em i-nodes Uni Questões: Dados e metadados ficam misturados no disco. Como achá-los? Dados e metadados em memória até serem escritos. Como não perdê-los? Informação é sempre escrita no final do log. Como recuperar áreas que possuem informações antigas (e desatualizadas)? Soluções: Um registro informando o que tem no segmento (mapa de i-nodes) Possui a localização atual dos metadados no disco (i-nodes) Possível perder, desde que se tenha um estado consistente após reboot (checkpoint) Limpeza de informações desatualizadas (garbage colllector) Sistemas Operacionais 5 Sistemas Operacionais 6 Organização do disco (partição) Mecanismo de checkpoint A partição é o log e é organizada em segmentos Porção contínua no disco (unidade de transferência) Os segmentos possuem um sumário (localização de blocos e i-nodes dentro do segmento) Mapa de i-nodes Vetor indeado pelo i-number cujo conteúdo indica o endereço atual do disco onde está o i-node do arquivo Possui uma área especial denominada de checkpoint Posição no log onde todos metadados estão completos e consistentes Armazenado em áreas fias no disco Lida para memória na inicialização Atualizada de forma periódica, no unmount e no shutdown Resolve os dois problemas: localização e consistência Localização de i-nodes Checkpoint mantém a localização dos i-nodes (tabela de i-nodes) Mantida em memória (lida na inicialização) para melhorar o acesso Consistência Em caso de falha por colapso (crash), a última atualização do checkpoint é que vale para representar o disco na reinicialização do sistema Sistemas Operacionais 7 Sistemas Operacionais 8
Coleta de lio (garbage collection) Confiabilidade do sistema de arquivos Mecanismo para recuperar espaço em disco Feito de forma periódica por um processo especial (cleaner) Similar a coleta de lio feita em memória Eemplo: Segmentos 5 e 6 possuem dentro deles arquivos válidos e arquivos removidos: compacta os dois segmentos e cópia arquivos para uma região livre e refaz encadeamentos Eistem várias otimizações para acelerar esse processo Indica o grau de funcionamento correto do sistema de arquivos na ocorrência de problemas Aspectos: Correção na criação, na atualização e na remoção de arquivos Consistência e correção dos metadados Prevenção da perda de dados Consistência e correção de dados Conceito Falha é comportamento errado, ou inesperado, de um sistema em decorrência de um defeito (pane) Sistemas Operacionais 9 Sistemas Operacionais 10 Abordagens para confiabilidade Backup Estratégias Recuperação Acionado quando há a ocorrência de uma falha Leva o sistema a um estado consistente conhecido Tolerância a falhas O sistema oferece funcionamento correto, mesmo na presença de falhas Defeito (pane) não provoca falhas Técnicas possíveis Recuperação: backups Tolerância a falhas: armazenamento estável e ações atômicas Cópia de segurança ou cópia lógica Permite a recuperação de arquivos em caso de problemas ou barbeiragem Baseado em atributo de arquivamento e/ou datas criação/modificação Inicia em um ou mais diretórios especificados e recursivamente copia todos os arquivos e diretórios criados/modificados desde uma data base Mas, atenção, backup não é sinônimo de copiar os dados Backup preserva metadados, enquanto que cópias simples modificam (no mínimo a data de criação) Tipos de backup Normal (completo) Incremental Diferencial Sistemas Operacionais 11 Sistemas Operacionais 12
Tipos de backup Incremental diferencial Normal Copia todos arquivos selecionados para o backup Desmarca atributo de arquivamento Incremental Copia todos arquivos criados/modificados desde o último backup (normal ou incremental) Desmarca o atributo de arquivamento Recuperação: último normal e todos os incrementais Diferencial Copia todos arquivos criados/modificados desde o último backup normal Não desmarca o atributo de arquivamento Recuperação: último normal e último diferencial Bit de arquivamento: ativado quando um arquivo é criado/modificado Indica necessidade de ser incluído no backup (1: sim ; 0:não) Informação pode ser baseada em data criação/data modificação Sistemas Operacionais 13 Sistemas Operacionais 14 Consistência do sistema de arquivos Como garantir a consistência? Correção dos metadados e da operação do sistema de arquivos Se os metadados do sistema de arquivos são perdidos ou corrompidos ocorre a perda de consistência Eemplo: remoção de um arquivo (grandes passos) requer remover a entrada do diretório (1º) liberar o i-node do arquivo (2º) liberar os blocos que pertenciam ao arquivo (3º) Na ausência de colapso do sistema (crash) a ordem não interessa, mas com o crash ela se torna importante. Eemplos: Se faz (1º) e crash: perde i-nodes e blocos Se faz (2º) e crash: se perde os blocos de dados Mudar a ordem das operações não resolve o problema (dá apenas outros efeitos colaterais) Utilização de transações (como banco de dados) Conceitos envolvidos Armazenamento estável Ações atômicas Idempotência Sistemas de arquivos jornalizados Sistemas Operacionais 15 Sistemas Operacionais 16
Armazenamento estável (stable storage) Ações atômicas Princípio básico Realizar duas cópias dos dados (primária e secundária) Operação de Escrita: atualiza a primária e depois a secundária Leitura: lê a primária, se corrompida (ECC*), lê a secundária Casos (a) (b) (c) (d) Atualizando a primária Atualizando a secundária t 1 t 2 t 3 t 4 Garante que ao menos uma cópia está OK, mas sabe se o conteúdo é novo ou velho *ECC: Error Correcting Code (deteção e correção de dados, se possível) Sistemas Operacionais 17 tempo 1ª 2ª Legenda: velho novo corrompido falha Definição Uma ação que consiste de um conjunto de subações e cuja eecução apresente um comportamento tudo ou nada Resultado final é consequência da realização de todas as subações OU Resultado final é como se nenhuma subação fosse realizada Previne a inconsistência de dados na ocorrência de defeitos Consistência do sistema de arquivos é mantido se todas as operações envolvendo metadados for feita baseada em ações atômicas Inspirado no conceito de transações atômicas Tecnologia empregada em base de dados Sistemas Operacionais 18 Principio de funcionamento de ações atômicas Idempotência Definição de uma ação atômica begin_atomic_action_id e end_atomic_action_id Lista de subações Duas possibilidades na conclusão de uma ação atômica (end) Abort: os efeitos das subações são tornados inócuos Se retorna ao estado anterior ao begin Pode acontecer em consequência de uma falha ou por desistência Commit: os efeitos de todas as subações são tornadas válidas (e corretas) independente da ocorrência de falhas no sistema Ações devem ser idempotentes Propriedade relativa ao comportamento de operações Idempotente: pode ser realizada várias vezes fornecendo o mesmo resultado como se tivesse sido eecutada apenas uma vez e.g.: ler um bloco de dados de um arquivo, inserir um elemento em posição fia de um vetor, etc. Não idempotente: o resultado final é modificado pela reeecução e.g.: creditar ou debitar um valor em uma conta bancária; inserir ou remover um elemento em um vetor; etc. Operações idempotentes simplificam a realização de serviços em casos de falhas Possível torna operações não idempotentes em idempotentes Números de sequência, históricos e flags para detectar a reeecução As ações atômicas devem ter subações idempotentes Sistemas Operacionais 19 Sistemas Operacionais 20
Implementação de ações atômicas Inserção de um novo bloco em um arquivo (alocação encadeada) Implementação de ação atômica armazenamento estável Duas estruturas de dados na criação da ação (begin) : par (bloco_id, conteúdo) Flag commit: para indicar a confirmação, ou não, da eecução das subações Flag= not commited Write novo d 1 Write novo d j begin_atomic_action add_a_block d j.net = d 1.net d 1.net = address(dj) write d 1 write d j end_atomic_action add_a_block Flag= not commited CRASH Repete o procedimento a partir do begin(passo 3a) Flag= commited Commit Commit Abort Flag= not commited Flag= commited CRASH... Write novo d 1 Write novo d Aborto: destrói a lista e o flag j Sucesso: destrói a lista e o flag (passo 3a do algoritmo) Repete o procedimento do end (passo 2 do algoritmo) (passo 3.b do algoritmo = refazer passo 2) Sistemas Operacionais 21 Uso de armazenamento estável!!! 1. Eecução da ação atômica A i a. Na eecução de begin atomic action criar uma lista de intenções e um flag commit commit flag = (A i, not commited ) = vazia b. Para cada atualização feita por uma subação, adicionar um par (d, v) na lista de intenções, onde d é nro de um bloco e v é novo contéudo para este bloco c. Na eecução de end atomic action, colocar o valor da ação A i para commit, ir passo 2. 2. Processamento do commit 1. Para cada par (d,v) na lista de intenções, escrever no bloco d do disco o conteúdo v 2. Remover o flag commit e a lista de intenções 3. Na recuperação após uma falha: se o flag commit de uma ação A i eistir 1. Se o valor do flag é not commited : apagar o flag commit e a lista de intenções e reiniciar a ação atômica A i 2. Realizar o passo 2 se o valor do flag é commit Sistemas Operacionais 22 Sistemas de arquivos jornalizados Principio de funcionamento Sistema de arquivos mantém em memória (cache) Dados Metadados Recuperação em caso de problemas Arquivos podem ser recuperados do backup Metadados podem ser recuperados varrendo o sistema de arquivos (e. fsck) Procedimento lento e não 100% garantido Nova proposta: sistema de arquivos jornalizados Objetivo é acelerar a recuperação do sistema de arquivos e, em caso de problemas, colocando ele em um estado consistente Eemplos: et3 ou et4 (Linu); ReiserFS (linu); XFS (SGI); JFS (IBM); VFS (Véritas), NTFS (windows) Modificações no sistema de arquivo são Registrados em um arquivo especial (journal) na forma de ações atômicas e armazenadas de forma estável Após registradas, tenta efetivar os efeitos das subações no sistema de arquivos Propriedade tudo ou nada Em caso de pane no sistema consulta o journal para verificar quais ações não foram eecutadas Corresponde àquelas que tem registro no journal com o flag commit posicionado Sistemas Operacionais 23 Sistemas Operacionais 24
Modos de jornalização A jornalização na prática Write behind Garante a consistência apenas dos metadados (jornaliza só as modificações nestes) As operações de atualização de blocos de dados podem ser perdidas Ordered data Escreve os blocos de dados antes de realizar o commit nos metadados Pode acontecer de um bloco novo ter sido escrito no disco, mas ainda não ter sido atualizado como pertencente ao arquivo (perda de dados) Full data Garante a consistência dos dados e dos metadados Jornaliza todas as operações Sistemas de arquivos et3 e et4 (Linu) Objetivo: ser um sistema de arquivos jornalizados compatível com o et2 Permite ser configurado para um dos três modos de jornalização Writeback: apenas metadados Ordenado: metadados, porém os atualiza após ter escrito os dados regulares (default) Jornal: dados e metadados Arquivo de journal se localiza na raiz do sistema de arquivos (.journal) Sistema de arquivos NTFS Permite apenas o modo de metadados (write behind) O arquivo de jornal é dado por uma entrada especial no MFT ($LogFile) Sistemas Operacionais 25 Sistemas Operacionais 26 Prós e contras da jornalização Leituras complementares Tendência a fragmentar o disco Custo computacional Maior quantidade de operações de entrada e saída no disco Manutenção do arquivo de journal Atualização do jornal no disco é sem uso de cache Necessário recuperação do espaço no arquivo de journal eliminando as ações que foram abortadas e as realizadas (garbage collector) Paliativo: Nem toda partição necessita ser jornalizada Silberchatz, A.; Galvin, P.B. Operating Systems Concepts. Adisson wesley, 9 th edition, 2013. Capítulo 12 (seção 12.8) Tanenbaum, A.S.; Bos, Herbert Modern Operating Systems. 4 th edition, 2015. Capítulo 4 (seção 4.4) Sistemas Operacionais 27 Sistemas Operacionais 28