UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE CIÊNCIAS DA COMPUTAÇÃO SEMINÁRIO JOURNALING FILESYSTEMS Seminário com o tema Journaling FileSystems apresentado como requisito parcial para aprovação na disciplina INE5355 - Sistemas Operacionais I ministrada pelo Prof. Dr. Antônio Augusto Fröhlich Alunos: Diego Perez Alvarez Fernando de Lucca Siqueira Karina Fasolin FLORIANÓPOLIS JUNHO/2008
SUMÁRIO 2.MOTIVAÇÃO... 4 3.CONTEXTO...5 3.1 VERIFICAÇÃO DE INTEGRIDADE... 6 3.2 JOURNALING... 7 3.3 JOURNALING FILESYSTEMS PARA LINUX...8 3.3.1 EXT3 - THIRD EXTENDED FILESYSTEM... 8 3.3.2 RAISERFS... 9 3.3.3 XFS...9 3.3.4 JFS... 10 4. COMPARAÇÕES...11 REFERÊNCIAS...15
3 1. INTRODUÇÃO FileSystems são métodos para armazenar e organizar arquivos e seu conteúdo, de modo a facilitar a procura e acesso a eles. Em uma analogia, pode-se comparar um FileSystem a um banco de dados para o armazenamento, organização, manipulação, acesso e busca de dados. Uma vez que se formata uma partição, se define o FileSystem que esta irá implementar, sendo que pode ser jornalado ou não. Journaled FileSystems então é um tipo de FileSystem onde as mudanças ocorridas nos dados são armazenadas em um journal como um log antes de efetivarem a mudança real no sistema.em um FileSystem, é importante manter a integridade dos dados mesmo após a ocorrência de falhas do sistema. Quando se tem um Journaling FileSystem a recuperação de erros são mais rápidas e eficientes, uma vez que se tem em mãos o log de todas mudanças realizadas no disco. Com log, como em banco de dados, pode-se fazer a verificação da consistência entre o que está escrito no journal e o que de fato está armazenado em disco. Isso torna a recuperação do sistema após uma falha muito mais simples do que em um FileSystem não jornalado, onde necessitaria percorrer toda a estrutura de dados para a verificação. Sistemas jornalados são realmente rápidos em alguns aspectos, por exemplo, no boot do sistema em um filesystem sem suporte a journal, é feita a verificação de todo o sistema enquanto num sistema com suporte a journal é verificada apenas a parte apontada pelo journal.
4 2.MOTIVAÇÃO Com a evolução tecnológica que está cada vez mais rápida são inúmeros os serviços requeridos dos filesystems, como grandes partições de discos, recuperação rápida após um crash, alta performance de I/O, e é necessário armazenar milhares de arquivos que podem representar terabytes de dados. Além disso, journaling é uma característica exigida pelas empresas, mas que beneficia todos os usuários finais. Um journaling filesystem pode simplificar reinicio, reduzir fragmentação e acelerar I/O, melhor ainda journaling file systems fazem a checagem de consistência de disco de uma maneira muito mais rápida. Se você precisa manter um sistema de complexidade consideravelmente alta ou que requira alta disponibilidade, você deve seriamente considerar um journaling filesystem. São vários os filesystems que implementam journaling, no linux os quatro em desenvolvimento são: Ext3, ReiserFS, XFS, e JFS, no windows: NTFS e no MAC OS X o HFS.
5 3.CONTEXTO Quando é necessário atualizar de um arquivo com n blocos para n+2 blocos, vários são as alterações feitas pelo filesystem em poucos passos o que deve acontecer é: 1. Primeiro, dois novos blocos são alocados para guardar os novos dados 2. Depois, os i-nodes dos arquivos são atualizados para gravar os ponteiros dos dois blocos novos e o novo tamanho do arquivo. 3. Finalmente, os dados atuais são escritos nos blocos. Porém esses passos não são atômicos, como exemplificado na figura abaixo: Figura 1: Esquema de i-node e como os blocos são alocados. Fonte:http://www.linux-mag.com/images/2002-10/img2/jfs_01.jpg Como pode ser visto o processo de escrever dados no arquivo o processo uma série de passos (mais passos podem ser mostrados se considerar todas as operações requeridas para
6 remover blocos livres de sua lista, entre outras mudanças de metadados possíveis) dessa forma está longe de ser uma operação atômica, onde poucos problemas podem ocorrer. Se todos os passos para escrever o arquivo são completados (e isso acontece na maioria das vezes) o arquivo é salvo com sucesso. Entretanto, se o processo é interrompido a qualquer tempo (talvez por problema de energia ou outra falha de sistema), um filesystem sem journaling pode terminar num estado inconsistente. Arquivos são corrompidos porque as operações lógicas de escrita (ou atualização) que na verdade são uma seqüência de I/O, não conseguem ser totalmente gravadas na mídia em determinado tempo. Se os meta-dados ou os dados do arquivo são deixados em um estado inconsistente, o filesystem não funcionará corretamente por muito tempo. 3.1 VERIFICAÇÃO DE INTEGRIDADE Filesystem sem journaling executam testes de integridade de filesystems (fsck ou scandisk) mais frequentemente, examinando toda a área de metadados do filesystem para detectar e reparar problemas com integridade estrutural antes de reiniciar. Se o Linux é desligado corretamente, fsck geralmente atesta sua integridade, Entretanto, depois de uma queda de energia ou crash, fsck é usado para encontrar algum tipo de erro nos meta-dados. Em filesystem que tem muitos meta-dados, a verificação de integridade pode ser muito lenta. Além disso, a verificação tem que escanear por completo o repositório de metadados do filesystem para assegurar consistência e operações sem erros. Como você já deve ter experimentado, a velocidade da verificação em uma partição do disco é proporcional ao tamanho dela, o número de diretórios e o número de arquivos em cada diretório. Para grandes filesystems, journaling tem se tornado crucial. Um journaling filesystem provê aumento na consistência estrutural, melhor recuperação e, reinicio mais rápido do que filesystems sem journaling. Na maioria dos casos, journaling filesystems podem reiniciar em menos de um segundo. O aumento de performance em um journaling filesystem vem do fato de que a verificação de integridade apenas vai varrer o journal do filesystem, verificando assim as operações que não tinham sido completadas e ficaram pendentes. A forma que esse journal é
7 construído permite que isso ocorra, uma vez que antes de cada alteração nos arquivos essa alteração é declarada no journal, sendo retirada do mesmo apenas quando ja está gravada em uma mídia. 3.2 JOURNALING A mágica do Journaling FileSystem está nas transações. Assim como uma transação de banco de dado, uma transação de um Journaling FileSystem trata uma sequência de mudanças como uma única operação, mas ao invés de atualizar tabelas, se faz atualizações nos metadados do filesystem ou nos arquivos do usuário. A transação garante que ou todas ou nenhuma atualização no sistema é feita. Por exemplo, o processo de criar um novo arquivo modifica várias estruturas de metadados (i-nodes, lista de blocos livres, entradas dos diretórios, etc). Antes do filesystem fazer essas mudanças, cria a transação que descreve o que está prestes a fazer. Uma vez que a transação foi gravada no disco, o filesystem continua e modifica o metadado. O journal de um Journaling filesystem é simplesmente a lista das transações. Em caso de uma falha no sistema, o filesystem é restaurado para um estado consistente refazendo as transações contida no journal. Ao invés de analisar todos metadados (com o fsck ou scandisk), o filesystem apenas verifica as partes dos metadados que foram recentemente modificados. A recuperação é bem mais rápida, normalmente dura segundos. E o melhor de tudo é que o tempo de recuperação deixa de ser dependente do tamanho da partição. Além de recomeçar muito mais rápido, a maioria dos Journaling filesystem também resolve outro problema significante: escalabilidade. Se você combinar alguns discos de grande capacidade, você pode juntar os filesystems. Dessa forma os journaling filesystems incluem propriedades como localização mais rápida de blocos livres, grande números de arquivos em um diretório, arquivos grandes e menor fragmentação interna.
8 3.3 JOURNALING FILESYSTEMS PARA LINUX 3.3.1 EXT3 - THIRD EXTENDED FILESYSTEM O ext3 (que significa "third extended file system") faz parte da nova geração de sistemas de gestão de arquivos do Linux, foi desenvolvido por Stephen Tweedie e colaboradores na Red Hat, ele seria um ext2 com recurso de journaling. Talvez, essa seja a razão de seu uso amplo: ele é totalmente compatível com ext2 (que foi um sistema de arquivos muito usado), o que nenhum outro sistema de arquivos baseado em Journaling é. O ext3 passou a ser efetivamente suportado pelo kernel do Linux a partir da versão 2.4. Conseqüentemente, todas as distribuições Linux lançadas com esse kernel ou superior, tem suporte padrão para ext3. No ext3 o journal usa uma camada chamada JDB (Journaling Block Device). A JBD foi criada com o propósito de implementar Journal em qualquer tipo de dispositivo com base em blocos de dados. Por exemplo, o código ext3 informa e "pede autorização" à JDB para efetuar as mudanças, antes de modificar/adicionar qualquer dado no disco. Sendo assim, é o JDB que verdadeiramente "gerencia" o Journal. O fato mais interessante disso é que, a JDB funciona como uma entidade independente, permitindo que não só o ext3 a use, mas também outros sistemas de arquivos. A JBD utiliza um método diferente na recuperação de dados, ao invés de armazenar bytes que devem ser gravados, ele armazena blocos modificados do sistema de arquivos na memória para poder rastrear as operações que ficaram pendentes, a vantagem é que ele não precisa lidar com a complexidade de gravar bytes no journal e a desvantagem é que o journal acaba ficando maior. A adição do journaling é feita em um arquivo chamado.journal que fica oculto pelo código ext3 na partição (desta forma ele não poderá ser apagado, o que comprometeria o funcionamento do sistema). Em relação ao ext2 o ext3 se diferencia em: - Conter um Journal. - Árvore de diretórios para diretórios quebrados em mais de um bloco. O ext3 suporta três tipos de implementação do Journaling: Journal: grava todas as mudanças no sistema de arquivos, ou seja, todos os
9 metadados e conteúdo dos arquivos são escritos antes de serem escritos no sistema de arquivos principal. É o mais lento dos três modos pois tem que gravar duas vezes, mas é o que possui maior capacidade de evitar perda de dados; Ordered: grava somente mudanças em arquivos metadata (arquivos que guardam informações sobre outros arquivos), mas guarda as atualizações no arquivo de dados antes de fazer as mudanças associadas ao sistema de arquivos. Este Journaling é o padrão nos sistemas de arquivos ext3; Writeback: também só grava mudanças para o sistema de arquivo em metadata, mas utiliza o processo de escrita do sistema de arquivos em uso para gravação. É o mais rápido Journaling ext3, mas o menos confiável. O modo Ordered é o padrão no ext3, mas é possível especificar qual o modo que você deseja usar, através da atualização do arquivo fstab. Por exemplo, pode ser que a linha /dev/hda1/opt tenha sua opção data com o valor ordered. Você pode mudar este valor para writeback ou journal. 3.3.2 RAISERFS O RaiserFS, criado por Hans Reiser especialmente para o Linux e é o filesystem padrão das distribuições GNU/Linux da SuSe, o ReiserFS não utiliza blocos de tamanho fixo, mas ajusta o tamanho de acordo com o arquivo, sendo assim muito rápido em ler arquivos menores e não desperdiçando espaço do disco. Ele é baseado em Árvore B+ para organizar os objetos do filesystem (informações dos arquivos como permissão, i-node, etc), o que dá um acesso mais rápido aos arquivos e diretórios. RaiferFS trata toda a partição como se fosse uma única tabela de banco de dados contendo diretórios, arquivos e arquivos de meta-data, aumentando o desempenho de aplicativos que trabalham com arquivos pequenos (são lidos em apenas um I/O do HD). 3.3.3 XFS
10 O XFS foi desenvolvido originalmente pela Silicon Graphics para atender ao seu sistema operacional IRIX e posteriormente disponibilizado o código fonte para se adaptar as versões Linux, é um sistema de arquivos muito rápido na gravação, possui um desfragmentador para arquivos, reconhecido pelo seu alto I/O throughput (testado até 7GB/sec). Tinha como objetivo ser um sistema de arquivos para gravação e reprodução de vídeos em tempo real. Usa muito a Árvore B+, principalmente para aumentar a escabilidade. Assim como o RaiserFS, o XFS utiliza tamanho variável de bloco, podendo assumir um tamanho de 512 bytes a 64 kilobytes. O log do XFS é gravado de forma assíncrona, isso é, os dados modificados não podem ser escritos em disco enquanto não for escrito no log. Com isso, múltiplas atualizações podem ser feitas e serem representadas por uma única escrita no log, aumentando sua eficiência. 3.3.4 JFS O JFS Journaling FileSystem, foi desenvolvido pela IBM para AIX. No JFS, o tamanho do bloco pode variar entre 512, 1024, 2048, e 4096 bytes, com o padrão de 4096. JFS aloca dinamicamente espaço para o i-node do disco quando necessário, liberando espaço quando não precisar mais. Para diretórios menores, armazena diretamente o conteúdo do diretório e seu i-node. Já para diretórios maiores, é usado uma Árvore B+, provendo operações mais rápidas para a manipulação dos arquivos.
11 4. COMPARAÇÕES Os gráficos comparativos aqui relacionados foram extraídos da palestra apresentada na FISL 9.0 pelo professor João Eriberto Mota Filho que é Oficial de Cavalaria do Exército Brasileiro e atua como Gerente de Rede e de Segurança em Rede do Gabinete do Comandante do Exército. Também é Coordenador e professor da Pós-graduação em Software Livre na Faculdade Fortium, em Brasília. Na palestra intitulada "Filesystems: Você realmente sabe instalar o GNU/Linux?" foram apresentados quadros comparativos entre os journaling filesystems:xfs, NTFS, JFS, ReiserFS e Ext3 e os antigos: Fat32 e Ext2. Teste de criação de 50000 arquivos de 5 bytes Tempo: Fonte:<http://www.eriberto.pro.br/palestras/fisl_2008/filesystems.pdf>
12 Reiser tem tempo pequeno por ter tamanho variável de blocos. Apesar do XFS também ter tamanho variável de blocos, a criação de entradas nos diretórios é lenta, por isso seu tempo foi superior aos demais. O fat32 tem baixa performance para muitos arquivos. Espaço Ocupado: Fonte:<http://www.eriberto.pro.br/palestras/fisl_2008/filesystems.pdf> Ext3 ocupa mais espaço do que os demais Journaling FileSystems por ter seu journal maior que os outros.
13 Teste de criação de 20000 arquivos de 11200 bytes Tempo: Fonte:<http://www.eriberto.pro.br/palestras/fisl_2008/filesystems.pdf> Para arquivos ocupando mais que 2 blocos, o NTFS perde muito da sua eficiência, demorando muito mais que os outros, enquanto o fat32 se mostra ser melhor para menos arquivos e maiores do que para mais arquivos e menores, devido a atualização da tabela realizada a cada mudança no sistema.
14 Espaço Ocupado: Fonte:<http://www.eriberto.pro.br/palestras/fisl_2008/filesystems.pdf> Novamente se percebe que em espaço ocupado, o Ext3 ocupa mais por ter seu journal maior que os outros, independente da quantidade de arquivos comparados.
15 REFERÊNCIAS BEST, Steve. Journaling File Systems. Linux Magazine Tuesday, October 15th, 2002. Disponível em: <http://www.linux-mag.com/de>. Acesso em 15/06/2008. TWEEDIE, Stephen C. Journaling the Linux ext2fs Filesystem. Disponível em: <http://donner.cs.uni-magdeburg.de/bs/lehre/wise0001/bs2/journaling/journal-design.pdf>. Acesso em 14/06/2008. MOTA FILHO,João Eriberto. Palestra intitulada "Filesystems: Você realmente sabe instalar o GNU/Linux?", apresentada no Fórum Internacional do Software Livre 9.0. Disponível em: <http://www.eriberto.pro.br/palestras/fisl_2008/>. Acesso em: 15/06/2008.