Вы находитесь на странице: 1из 14

A evoluo dos sistemas de arquivos: Do Ext ao Ext4

Ext Inicialmente, Linus Torvalds adaptou o sistema de arquivos do MINIX, de Andrew Tanembaum, para o Linux. Porm, por possuir vrias limitaes, como tamanho limite para o nome do arquivo (14 caracteres) e para o tamanho de um arquivo ou uma partio (64 MB), acabou sendo substitudo pelo Ext2, desenvolvido em 1993 por Rmy Card. Ext2 O 2nd Extended File System, Ext2, foi projetado para corrigir as deficincias de seu antecessor, que era simplismente uma adaptao de outro sistema de arquivos, e procurou seguir a semntica do UNIX. Melhoras em relao ao Ext: 1. O tamanho limite para o nome de um arquivo foi aumentado para 255 caracteres; 2. O tamanho mximo de um arquivo passa de 64MB para uma faixa entre 16GB e 2TB (o tamanho varia de acordo com o tamanho dos blocos, que varivel); 3. O tamanho mximo de uma partio passa a ser entre 2 e 32 TB. Bloco a menor unidade de alocao do Ext2. Constitui vrios setores (cada um possui 512 bytes) e pode ter tamanho de 1, 2 ou at 4KB. Super-bloco a estrutura bsica do Ext2. Ocupa 1024 bytes e inicia no terceiro setor da partio pois os primeiros 1024 bytes de cada partio so sempre reservados para o boot. O quadro a seguir mostra todos os atributos existentes no super-bloco:

I-nodes

Um arquivo descrito por um i-node. O i-node uma estrutura de dados com tamanho padro de 128 bytes(o tamanho definido na formatao). A tabela seguinte mostra seus atributos:

Grupos de blocos Cada partio dividida em grupos de blocos de mesmo tamanho. Com um tamanho de bloco de 4 KB, um grupo contm 32768 blocos. Cada grupo de blocos possui uma tabela de descritores que endeream os mapas de bits dos blocos e dos i-nodes e a tabela de i-nodes. O primeiro grupo contm o superbloco, que possui cpia em alguns outros grupos. No mapa de bits de blocos, cada byte mapeia 8 blocos (um por bit). O bit menos significativo identifica o bloco de menor nmero. O mapa de bits de i-nodes anlogo. Os grupos de blocos so representados pela seguinte estrutura:

Mapa de bits de blocos Em cada grupo de blocos, um bloco alocado para indicar se os restantes esto ocupados ou livres. Quando o bloco possui tamanho 4 KB, possvel mostrar 32768 blocos (4096 * 8). Se est alocado, marcado com o bit '1', e caso contrrio, com o bit '0'. Mapa de i-nodes De forma anloga ao mapa de bits de blocos, um bloco utilizado para indicar a alocao dos i-nodes. Geralmente o bloco no totalmente utilizado pois o nmero de i-nodes menor que o nmero de blocos. Tabela de i-nodes A tabela de i-nodes formada por blocos consecutivos aps os mapas de bits. Cada entrada na tabela um i-node. Portanto, para um bloco de tamanho 4 KB, possvel conter at 32 i-nodes. Alocao de blocos Quando feita a operao de escrita em um arquivo, o Ext2 tenta sempre que possvel alocar blocos de dados no mesmo grupo de blocos que contm o i-node. Este comportamento reduz o movimento da cabea de leitura-gravao da unidade de disco. Em um sistema de arquivos podemos encontrar dois tipos de fragmentao: A fragmentao interna, que ocorre quando o tamanho do arquivo no mltiplo do tamanho do bloco, ocorrendo uma perda de espao no ltimo bloco; fragmentao externa, que ocorre quando o arquivo possui blocos alocados no contiguamente, prejudicando seu desempenho. Para a fragmentao interna, a soluo diminuir o tamanho padro do bloco. Porm, ao fazermos isto, possuiremos um nmero maior de blocos para serem gerenciados, prejudicando o desempenho. Outra soluo aplicar o tail packing, ou

seja, utilizar fragmentos de vrios arquivos, menores que um bloco, em um bloco s. Porm, o Ext2 no implementa esta funcionalidade. Para a fragmentao externa, o Ext2 reserva at 8 blocos quando um arquivo aberto para gravao. Esses blocos reservados, quando possvel, so adjacentes ao ltimo bloco utilizado pelo arquivo. Ext3 O Ext3 (ou third extended filesystem) baseado em journaling, que comumente usado pelo kernel do Linux. Sua maior vantagem sobre o antigo Ext2 justamente o uso do journaling, que aumenta a confiabilidade e elimina a necessidade de checar o sistema de arquivos depois de um desligamento inesperado do sistema. Vantagens Apesar de sua performance (velocidade) ser menos atrativa em comparao com outros sistema de arquivos Linux como o JFS, ReiserFS e o XFS, o Ext3 tem uma importante vantagem, que a de ser possvel um upgrade direto do ext2 sem a necessidade de backup e restaurao de dados. Em relao ao Ext2, possui as seguintes melhorias: 1. Journaling; 2. Crescimento do sistema de arquivos de forma online; 3. Indexao por H-tree para diretrios com muitos arquivos. Uma H-tree uma verso especial de uma B-tree. Sem estes elementos, qualquer sistema Ext3 se torna um Ext2 vlido. Isto permitiu que ferramentas de manuteno e reparao de sistemas de arquivos Ext2 j bem testadas e maduras pudessem ser usadas para sistemas Ext3 sem grandes modificaes. Ambos usam o mesmo conjunto de ferramentas padro, o e2fsprogs, que inclui um fsck. A estreita relao permite a converso direta entre os sistemas, em ambas as direes (tanto Ext2 para Ext3, quanto o caminho inverso). Enquanto que em algumas situaes a falta de caractersticas de sistemas de arquivos modernos, como a alocao dinmica de i-nodes, pode ser considerada uma desvantagem. Quando se trata de recuperao de dados o Ext3 tem uma significativa vantagem sobre seus concorrentes. Os metadados do sistema ficam todos armazenados em localizaes fixas e bem conhecidas, e h uma certa redundncia inerente nas estruturas de dados que permitem que Ext2 e Ext3 sejam recuperveis face a uma corrupo de dados significativa, onde sistemas baseados

em rvores de arquivos podem no ser. Journaling H trs nveis de journaling no Ext3: 1. Journal (risco mais baixo): Tanto metadados quanto o contedo dos arquivos so escritos no journal antes de serem submetidos ao sistema de arquivos principal. Por o journal ser relativamente contnuo no disco, isto aumenta a performance em algumas circunstncias. Em outros casos, a performance pode piorar, em razo de os dados serem escritos duas vezes (uma vez no journal, e outra para o parte principal do sistema de arquivos). 2. Ordenado (risco mdio): Apenas os metadados so escritos no journal, e o contedo dos arquivos no, mas garantido que este contedo seja escrito no disco antes que os metadados correspondentes sejam marcados como submetidos no journal. Isto o padro em muitas distribuies Linux. Se houver falta de energia ou kernel panic enquanto um arquivo est sendo escrito ou modificado, o journal vai mostrar que o novo arquivo no foi submetido , portanto ele ser limpado pelo processo de cleanup (portanto arquivos novos e modificados tm o mesmo tratamento que no nvel journal). No entanto, arquivos sendo sobrescritos podem ser corrompidos porque a verso original do arquivo no foi guardada. Isto permite que um arquivo fique em um estado entre novo e velho, sem informao suficiente para restaurar completamente nenhum dos dois estados (os novos dados nunca sero gravados totalmente no disco, e os velhos no esto guardados em lugam algum). Pior ainda, este estado intermedirio pode misturar dados novos e velhos, porque a ordem da escrita controlada pelo prprio hardware do disco. 3. Writeback (risco mais alto): Somente metadados so escritos no journal; o contedo dos arquivos no. O contedo pode ser escrito antes ou depois que o journal atualizado. Como consequncia, arquivos modificados logo antes de uma pane podem ser corrompidos. Por exemplo, um arquivo com dados sendo anexados pode ser marcado no journal como sendo maior do que ele realmente , causando inconsistncias. Verses antigas de arquivos podem aparecer inesperadamente depois de uma recuperao do journal. A falta de sincronizao entre dados e journal rpida em muitos casos. Desvantagens 1. Funcionalidade: pelo Ext3 primar por ser retroativamente compatvel com o antigo ext2, ele procura ser parecido com este. Por causa disto, muitas caractersticas presentes em sistemas mais recentes faltam nele, como extents, alocao dinmica de inodes, e subalocao de blocos. H um limite de 31998 subdiretrios por diretrios, vindo do fato do limite de 32.000 links por i-node.

2.

3.

4.

5.

O Ext3, assim como muitos sistemas de arquivos correntes de Linux, no pode ser checado por fsck enquanto o sistema est montado. Tentando-se fazer isso pode causar deteco de erros em dados modificados que ainda no foram escritos no disco, e o arquivo pode ser corrompido numa tentativa de consertar estes erros. Desfragmentao: No h uma ferramenta de desfragmentao online que funcione em um nvel do sistema de arquivos. Existe um desfragmentador de Ext2 offline, o e2defrag, mas necessrio que o sistema Ext3 seja convertido para ext2 anteriormente. Entretanto, dependendo dos bits de funcionalidade ativados no filesystem, o e2defrag pode vir a destruir dados, pois no sabe como tratar muitas das novas caractersticas do Ext3. H ferramentas de desfragmentao em userspace como o Shake e o Defrag. O Shake aloca espao para um arquivo inteiro como uma nica operao, o que geralmente faz com que o alocador encontre um espao de disco contguo, e tambm tenta gravar arquivos utilizados ao mesmo tempo de uma forma que fiquem prximos entre si. O Defrag sobrescreve um arquivo sobre ele mesmo. Contudo, ambos somente funcionam caso o sistema de arquivos esteja relativamente vazio. Uma ferramenta de desfragmentao verdadeira para o Ext3 no existe. Neste aspecto, h uma observao no Guia do Administrador de Sistemas Linux em que diz: Sistemas de arquivos Linux modernos mantm a fragmentao em um nvel mnimo ao deixar todos os blocos de um arquivo dispostos de forma prxima, ainda que no seja possvel o armazenamento em setores consecutivos. Alguns filesystems, como o Ext3, efetivamente alocam os blocos livres que esto mais prximos dos outros blocos do arquivo. Logo, no necessrio preocupar-se com fragmentao em um sistema Linux. Ainda que o Ext3 seja mais resistente fragmentao que o FAT (File Allocation Table), possvel que ocorra fragmentao com o tempo ou com o uso de padres de escrita especficos, como na gravao de arquivos grandes de forma lenta. Recuperao: No h suporte para a recuperao de arquivos deletados. Ext3 ativamente deleta os arquivos eliminando seus inodes, por razes de segurana contra crashes. Por isso um rm rf ...acidental pode causar perda permanente de dados. H algumas ferramentas comerciais que tentam recuperar dados perdidos pela anlise do journal, no entanto elas no garantem nada. No h nenhuma chance de recuperao de arquivos aps uma formatao de disco. Compresso: O suporte compresso de forma transparente disponibilizado na forma de um patch no-oficial. Este patch um port direto do e2compr, e ainda precisa ser melhor desenvolvido; a compilao e o boot ocorre sem problemas comos upstream kernels**, mas o journaling ainda no foi implementado. O patch atual chama-se e3compr. Incapacidade de obter snapshots: Diferente de muitos sistemas de arquivos modernos, o Ext3 no tem suporte nativo aos snapshots a habilidade de se capturar rapidamente o estado do sistema de arquivos em momentos arbitrrios,

ao invs de depender nos snapshots em nvel de volume que so menos eficientes em termos de espao, fornecidos pelo LVM** do Linux. O sistema de arquivos Next3 uma verso modificada do Ext3 que oferece suporte aos snapshots, que ainda retm a compatibilidade com o formato do disco do Ext3. 6. Ausncia de checksum no journal: O Ext3 no realiza checksums ao escrever no journal. Se a flag barrier=1 no for passada na hora do mount (em /etc/fstab), e o hardware estiver fazendo o caching de uma escrita fora de ordem, h o risco de um corrompimento srio do sistema de arquivos durante um travamento. Considere o seguinte cenrio: Se o disco rgido realizar as operaes de escrita fora de ordem (pois os caches dos discos rgidos modernos so feitas em ordem para se amortizar a velocidade de escrita), possvel que um commit block de uma operao seja feito antes que outros blocos relevantes sejam escritos. Na eventualidade de uma interrupo no fornecimento de energia eltrica ou de um travamento irrecupervel antes dos outros blocos serem escritos, o sistema ter de ser reiniciado. Neste processo, o file system verificar o log como normal, e autorizar as operaes com o commit block, incluindo aquela que foi marcada como tal. A escrita inacabada acima ento proceder, utilizando porm dados do journal corrompido. O file system ento ir acidentalmente sobrescrever dados normais com dados corrompidos ao conferir o journal. Existe um programa de teste disponvel para acionar este comportamento problemtico. Se checksums fossem utilizados, onde os blocos da transao supostamente valida fossem marcados com um checksum mtuo, o sistema de arquivos teria maiores informaes e no tentaria reescrever os dados corrompidos no disco. O checksumming de journal foi adicionado ao Ext4. Sistemas de arquivos que passem pela interface de mapeamento de dispositivos (incluindo RAID via software e implementaes do Logical Volume Manager) podem no suportar barreiras, e geraro um alerta caso tal opo de mount seja utilizada. H tambm alguns discos que no implementam propriamente a extenso de flushing do cache de escrita necessria para que as barreiras funcionem, o que causa um alerta similar. Nestas situaes, em que as barreiras no tm suporte ou no so prticas, um ordenamento de escrita confivel possvel ao se desligar o cache de escrita do disco e usando tambm a opo de montagem data=journal. Desligar o cache de escrita do disco pode ser necessrio mesmo quando as barreiras esto disponveis. Aplicativos como bancos de dados esperam uma chamada ao fsync(), que far o flush de escritas pendentes ao disco, e a implementao de barreira nem sempre limpa o cache de escrita do disco em resposta a tal chamada. Existe tambm o problema potencial com a implementao de barreira relacionada manipulao de erros durante eventos como uma falha de disco. Ext4

O sucessor do Ext3 foi criado como uma srie de extenses retrocompatveis para remover os limites de armazenamento em 64 bits, e adicionar outras melhorias de performanc. Entretanto, alguns desenvolvedores do kernel do Linux mostraram-se contrrios em aceitar extenses no Ext3 por razes de estabilidade, e propuseram criar um fork do cdigo fonte do Ext3, renome-lo de Ext4, e fazer todo o desenvolvimento desta forma, sem afetar os atuais usurios do Ext3. Tal proposta foi aceita, e em 28 de junho de 2006, Theodore Ts'o, o mantenedor do Ext3 na poca, anunciou o novo plano de desenvolvimento para o Ext4. Uma verso preliminar do Ext4 foi includa na verso 2.6.19 do kernel. Em 11 de outubro de 2008, os patches que determinavam que o Ext4 tornou-se stable code foi integrado aos repositrios do cdigo fonte do Linux 2.6.28, denotando o fim da fase de desenvolvimento e conseqente recomendao da adoo do Ext4. O kernel 2.6.28 contendo o Ext4 foi finalmente lanado no dia 25 de dezembro de 2008. Em 15 de janeiro de 2010, o Google anunciou que atualizaria sua infraestrutura de armazenamento de Ext2 para Ext4. Caractersticas 1. Sistema de arquivos para grandes capacidades: o Ext4 d suporte para volumes de at 1 exabyte de arquivos de at 16 terabytes. O atual e2fsprogs consegue lidar com um sistema de arquivos de at 16TB, entretanto o suporte para discos maiores est em desenvolvimento. 2. Extents: foram introduzidos para substituir o tradicional esquema de mapeamento de blocos usado pelo Ext2 e Ext3. Um extent um srie de blocos fsicos contguos, melhorando a performance em arquivos grandes e reduzindo a fragmentao. Um nico extent no Ext4 pode mapear at 128MB de espao contguo com um tamanho de bloco de 4KB. Pode haver at 4 extents armazenados em um nico inode. Quando h mais que 4 extents para um arquivo, o restante dos extents so indexados em uma Htree (uma especializao da rvore B). 3. Retrocompatibilidade: o Ext4 retrocompatvel com o Ext3 e o Ext2, tornado possvel a montagem de sistemas de arquivos Ext3 e Ext2 como Ext4. Isso melhorar ligeiramente a performance graas a algumas novas caractersticas do Ext4 que podem ser usadas com o Ext3 e o Ext2, como o novo algoritmo de alocao de blocos.O Ext3 parcialmente compatvel antecipadamente com o Ext4, ou seja, uma partio Ext4 pode ser montada como Ext3. Entretanto, se a tal partio utilizar extents, tal operao no ser possvel. 4. Pr-alocao persistente: o Ext4 permite a pr-alocao de espao no disco para um arquivo. O mtodo atual para realizar esta operao na maioria dos file systems escrever um arquivo cheio de zeros para reservar aquele espao quando o arquivo for criado. Isto no mais necessrio no Ext4, pois uma nova

chamada de sistema fallocate() foi adicionada ao kernel para uso pelos arquivos de sistema, incluindo o Ext4 e o XFS, que tem capacidade para realizar este tipo de operao. O espao alocado para arquivos como estes garantido e provavelmente ser contguo, o que pode ter aplicaes em streaming de mdia e em banco de dados. 5. Alocao atrasada: o Ext4 utiliza uma tcnica chamada allocate-on-flush, tambm chamada de delayed allocation (alocao atrasada), que consiste em atrasar a alocao de blocos at que os dados estejam prontos para serem escritos em disco, ao contrrio de outros sistemas de arquivos, que podem alocar os blocos necessrios antes disso. Verifica-se uma melhoria na performance e reduo de fragmentao ao melhorar as decises da alocao de blocos baseadas no tamanho real do arquivo. 6. Remoo do limite de 32.000 subdiretrios: no Ext3 o nmero de subdiretrios que um diretrio pode conter est limitado em 32.000. Este limite foi aumentado para 64.000 no Ext4 e com a funcionalidade "dir_nlink" possvel ir alm (embora a contagem de subdiretrios na pasta-pai congele). Para garantir a performance dada a possibilidade de diretrios muito maiores, ndices da Htree so habilitados por padro no Ext4. Esta caracterstica foi implementada no kernel 2.6.23. A Htree tambm est disponvel no Ext3 quando o dir_index habilitado. 7. Journal checksumming: utiliza checksums no journal para melhorar a confiabilidade, j que o journal um dos arquivos mais utilizados no disco. Esta funcionalidade tem um benefcio colateral: evita-se uma espera de I/O durante o processo de journaling, melhorando ligeiramente a performance. A tcnica de journal checksumming foi inspirada em um paper da Universidade de Wisconsin entitulada IRON File Systems (especificamente, seo 6, chamada "transaction checksums"). 8. Checagem do sistema de arquivos mais rpida: no Ext4, grupos de blocos no-alocados e sees da tabela de inode so marcadas como tal. Isso permite que o e2fsck pule estes inteiramente em uma checagem, o que reduz enormemente o tempo que levaria para um file system do tamanho que o Ext4 foi projetado para suportar. Esta funcionalidade foi implementada na verso 2.6.24 do kernel. O grfico abaixo nos d uma viso mais ntida disto.

9. Alocador multi-bloco: quando um arquivo est sofrendo uma operao de append, o Ext3 chama o alocador de blocos para cada bloco individualmente. Com mltiplos escritores concorrentes, os arquivos podem se tornar fragmentados facilmente. Com a alocao atrasada, entretanto, o Ext4 armazena uma quantidade grande de dados em um buffer, e ento aloca um grupo de blocos em lote. Isso significa que o alocador tem mais informaes sobre o que est sendo escrito e pode fazer escolhas melhores para alocar arquivos no disco de forma contgua. O alocador multiblocos usado quando outra alocao atrasada habilitada para um file system, ou quando arquivos so abertos no modo O_DIRECT (diretamente no dispositivo de I/O). Esta funcionalidade no afeta o formato do disco. 10. Timestamps melhorados: como os computadores tornam-se mais velozes em geral, e como o Linux tem sido utilizado com mais freqncia para aplicativos de misso crtica, a granularidade de timestamps baseados em segundos torna-se insuficiente. Para solucionar este problema, o Ext4 fornece timestamps medidos em nanosegundos. Alm disso, 2 bits do campo expandindo do timestamp so adicionados aos bits mais significativos do campo de segundos para adiar o problema no ano 2038* por mais 204 anos. * O problema do ano 2038 (conhecido tambm como o Bug do Milnio do Unix, Y2K38 em analogia ao problema do Y2k, ano 2000) pode causar a falha de alguns softwares de computadores antes ou no ano de 2038. O problema afeta todos os softwares

e sistemas que armazenam o horrio do sistema como um inteiro de 32 bits com sinal, e interpretam este nmero como o nmero de segundos desde s 00:00:00 UTC na tera, dia 1 de janeiro de 1970. O maior tempo de representao possvel desta forma 03:14:07 UTC na tera, 19 de janeiro de 2038. Horrios aps este momento "fecharo o ciclo" e sero armazenados internamente como um nmero negativo aps o overflow, onde estes sistemas interpretaro a data como 1901 ao invs de 2038. Isto muito provavelmente causar problemas para usurios destes sistemas dado ao resultado errneo do clculo. J que a maioria dos sistemas de 32 bits baseados em Unix armazenam e manipulam o tempo neste formato, este denominado "tempo do Unix", e por este motivo o problema do ano 2038 chamado de Bug do milnio do Unix. Entretanto, qualquer outro sistema operacional no-Unix que armazene e manipule o tempo desta mesma forma estar igualmente vulnervel. O Ext4 tambm passa a dar suporte para date-created timestamps. Entretanto, assim como Theodore Ts'o aponta, enquanto algo trivial adicionar um campo extra para a data de criao no inode (tecnicamente permitindo ento o suporte a date-created timestamps no Ext4), mais difcil modificar ou adicionar os system calls necessrios, como stat() (que provavelmente necessitaria de uma nova verso), e vrias bibliotecas dependem destas funes (como o glibc). Estas mudanas requeririam a coordenao de muitos projetos, portanto mesmo que os desenvolvedores do Ext4 implementem o suporte inicial para timestamps de data de criao, esta caracterstica no ficar disponvel aos usurios de programas por enquanto. Desvantagens - Alocao atrasada e potencial perda de dados: devido ao fato da alocao atrasada modificar o comportamento em que programadores estavam acostumados no Ext3, esta caracterstica traz algum risco adicional de perda de dados em casos onde o sistema trava ou tem seu suprimento de energia cortado antes que todos os dados tenham sido escritos em disco. Outros file systems do Linux como o XFS nunca ofereceram um comportamento similar ao do Ext3. Por isso, o Ext4 nas verses do kernel 2.6.30 e posteriores automaticamente detectam estes casos e revertem o funcionamento para o modo anterior de operao. O cenrio tpico em que isso pode ocorrer quando um programa tenta sobrescrever o contedo de um arquivo sem forar a escrita ao disco via fsync. H dois meios comuns de se sobrescrever o contedo de um arquivo em um sistema Unix: open("file", O_TRUNC); write(fd, data); close(fd): Neste caso, um arquivo existente truncado no momento de sua abertura (por causa da flag O_TRUNC), ento dados novos so escritos. J que a escrita pode levar algum

tempo, possvel que haja uma oportunidade em que contedo seja perdido mesmo com o Ext3, que no entanto seria pequeno. No entanto, como o Ext4 pode atrasar a alocao dos dados de arquivo por um perodo extenso, esta ocasio pode ocorrer com muito mais freqncia. open("file.new"); write(fd, data); close(fd); rename("file.new", "file"): Um novo arquivo temporrio ("file.new") criado, no qual h o novo contedo. Ento este novo arquivo renomeado. A substituio de arquivos pela chamada rename garantidamente atmica pelos padres POSIX - ou seja, ou o arquivo antigo permanece intacto, ou sobrescrito pelo novo. Pelo fato do modo padro de journalling "ordenado" no Ext3 garantir que os dados de arquivo sejam escritos em disco antes dos metadados, esta tcnica garante que ou o contedo antigo ou o novo persistiro em disco. A alocao atrasada do Ext4 quebra tal expectativa, pois a escrita do arquivo pode ser adiada por um longo tempo, e o rename normalmente feito antes que o contedo do novo arquivo chegue ao disco. Usar o fsync com mais freqncia para reduzir tal risco no Ext4 pode levar a quedas acentuadas de performance em sistemas Ext3 montados com a flag data=ordered (padro na maioria das distribuies). Dado que ambos os file systems estaro em uso por algum tempo, cria-se complicaes enormes para os desenvolvedores de aplicaes para usurios finais. Por isso, o Ext4 no kernel 2.6.30 e posteriores detectam este tipo de ocorrncia, e fora os arquivos a serem alocados imediatamente. Pagando um custo pequeno em performance, prov-se uma semntica similar ao modo ordenado do ext3, e melhora-se a chance de que alguma das verses do arquivo sobrevivero ao travamento. Este novo comportamento ativado por padro, mas pode ser desativado com a opo de montagem "noauto_da_alloc". Os novos patches passaram a fazer parte do kernel principal 2.6.30, mas vrias distribuies optaram por fazer um backport para os kernels 2.6.28 ou 2.6.29. Como exemplo citamos o Ubuntu, que aplicou o patch no kernel na verso 9.04 ("Jaunty Jackalope"). E2fsprogs O e2fsprogs (chamado por vezes de e2fs programs) um conjunto de utilitrios para manuteno de sistemas de arquivos Ext2, Ext3 e Ext4. J que estes file systems so normalmente o padro para as distribuies Linux, normalmente considerado como um software essencial. Esto inclusos no e2fsprogs:

1. 2. 3. 4. 5. 6.

e2fsck, um programa fsck que checa e corrige inconsistncias; mke2fs, usado para criar sistemas de arquivos Ext2, Ext3 e Ext4; resize2fs, que pode expandir e reduzir sistemas de arquivos Ext2, Ext3 e Ext4; tune2fs, usado para modificar parmetros do sistema de arquivos; dumpe2fs, que imprime informaes de superblocos e de grupos de blocos; debugfs, usado para visualizar manualmente ou modificar estruturas internas do sistema de arquivos.

Referncias: -http://book.opensourceproject.org.cn/kernel/kernel3rd/opensource/0596005652/ understandlk-chp-18-sect-2.html -http://en.wikipedia.org/wiki/Ext2 -http://en.wikipedia.org/wiki/Ext3 -http://en.wikipedia.org/wiki/Comparison_of_file_systems

Вам также может понравиться