ext4

Sistema de arquivo grande O sistema de arquivo ext4 pode suportar volumes com tamanhos de até 1 exbibyte (EiB) e arquivos simples com tamanhos de até 16 tebibytes (TiB) com o tamanho padrão de bloco de 4 KiB. Os limites máximos de arquivo, diretório e tamanho do sistema de arquivos crescem pelo menos proporcionalmente com o tamanho do bloco do sistema de arquivos até o tamanho máximo de 64 blocos KiB disponíveis nas CPUs ARM e PowerPC/Power ISA. Extensões As extensões substituem o esquema tradicional de mapeamento de blocos usado por ext2 e ext3. Uma extensão é uma gama de blocos físicos contíguos, melhorando o desempenho de arquivos grandes e reduzindo a fragmentação. Uma única extensão em ext4 pode mapear até 128 MiB de espaço contíguo com um tamanho de bloco de 4 KiB. Podem existir quatro extensões armazenadas directamente no inode. Quando há mais de quatro extensões num ficheiro, o resto das extensões são indexadas numa árvore. A compatibilidade com ext4 é compatível com ext3 e ext2, tornando possível a montagem de ext3 e ext2 como ext4. Isto irá melhorar ligeiramente o desempenho, porque certas novas funcionalidades da implementação de ext4 também podem ser usadas com ext3 e ext2, como o novo algoritmo de alocação de blocos, sem afetar o formato em disco. ext3 é parcialmente compatível com ext4. Praticamente, ext4 não será montado como um sistema de arquivos ext3 fora da caixa, a menos que certas novas funcionalidades sejam desabilitadas ao criá-lo, tais como ^extent, ^flex_bg, ^huge_file, ^uninit_bg, ^dir_nlink, e ^extra_isize. A pré-alocação persistente ext4 pode pré-alocar espaço em disco para um arquivo. Para fazer isso na maioria dos sistemas de arquivo, os zeros seriam escritos no arquivo quando criado. No ext4 (e alguns outros sistemas de ficheiros como o XFS) fallocate(), pode ser usada uma nova chamada de sistema no kernel do Linux. O espaço alocado seria garantido e provavelmente contíguo. Esta situação tem aplicações para streaming de mídia e bancos de dados. A alocação retardada ext4 usa uma técnica de performance chamada alocação em fluxo, também conhecida como alocação retardada. Ou seja, o ext4 atrasa a alocação de blocos até que os dados sejam enviados para o disco. (Em contraste, alguns sistemas de arquivos alocam blocos imediatamente, mesmo quando os dados vão para um cache de gravação). A alocação retardada melhora o desempenho e reduz a fragmentação, alocando efetivamente maiores quantidades de dados de cada vez. O número ilimitado de subdiretórios ext4 não limita o número de subdiretórios em um único diretório, exceto pelo limite inerente ao tamanho do próprio diretório. (Em ext3 um diretório pode ter no máximo 32.000 subdiretórios.) Para permitir diretórios maiores e desempenho contínuo, ext4 no Linux 2.6.23 e mais tarde ativa índices HTree (uma versão especializada de uma árvore B) por padrão, o que permite que diretórios de até aproximadamente 10-12 milhões de entradas sejam armazenados no índice HTree de 2 níveis e limite de tamanho de diretório de 2 GB para blocos de 4 KiB, dependendo do comprimento do nome do arquivo. No Linux 4.12 e posteriores o recurso largedir permitiu um HTree de 3 níveis e tamanhos de diretórios acima de 2 GB, permitindo aproximadamente 6 bilhões de entradas em um único diretório. O journal checksums ext4 usa checksums no diário para melhorar a confiabilidade, já que o diário é um dos arquivos mais usados do disco. Este recurso tem um benefício lateral: ele pode evitar com segurança uma espera de E/S do disco durante o diário, melhorando ligeiramente o desempenho. O journal checksumming foi inspirado em um artigo de pesquisa da Universidade de Wisconsin, intitulado IRON File Systems (especificamente, seção 6, chamada “transaction checksums”), com modificações dentro da implementação de transações compostas realizadas pelo sistema de arquivos IRON (originalmente proposto por Sam Naghshineh no cume do RedHat). Metadata checksumming Desde o kernel Linux 3.5 lançado em 2012 Faster file-system checking In ext4 unallocated block groups and sections of the inode table are marked as such as. Isto permite ao e2fsck saltá-los completamente e reduz muito o tempo que leva para verificar o sistema de ficheiros. O Linux 2.6.24 implementa esta funcionalidade.

fsck time dependent on inode count (ext3 vs. ext4)

Multiblock allocator Quando ext3 se junta a um arquivo, ele chama o alocador de blocos, uma vez para cada bloco. Conseqüentemente, se houver vários escritores simultâneos, os arquivos podem facilmente se fragmentar em disco. Entretanto, o ext4 utiliza alocação atrasada, o que lhe permite armazenar dados em buffer e alocar grupos de blocos. Consequentemente, o alocador multibloco pode fazer melhores escolhas sobre a alocação de arquivos contíguos em disco. O alocador multibloco também pode ser usado quando os arquivos são abertos no modo O_DIRECT. Este recurso não afeta o formato do disco. Melhoria dos timestamps à medida que os computadores se tornam mais rápidos em geral, e à medida que o Linux se torna mais utilizado para aplicações de missão crítica, a granularidade dos timestamps de segunda base torna-se insuficiente. Para resolver isto, ext4 fornece carimbos de data/hora medidos em nanossegundos. Além disso, 2 bits do campo de timestamp expandido são adicionados aos bits mais significativos do campo de segundos dos timestamps para adiar o problema do ano 2038 por mais 408 anos. ext4 também adiciona suporte para timestamps de tempo de criação. Mas, como Theodore Ts’o aponta, embora seja fácil adicionar um campo de data de criação extra no inode (permitindo assim tecnicamente o suporte para estes timestamps no ext4), é mais difícil modificar ou adicionar as chamadas de sistema necessárias, como stat() (que provavelmente requereria uma nova versão) e as várias bibliotecas que dependem deles (como glibc). Estas mudanças vão exigir a coordenação de muitos projetos. Portanto, a data de criação armazenada por ext4 está atualmente disponível apenas para programas de usuários no Linux através da APIstatx(). Cotas de projetos O suporte a cotas de projetos foi adicionado no kernel Linux 4.4 em 8 de janeiro de 2016. Esta funcionalidade permite atribuir limites de quotas de disco a um determinado ID de projeto. O ID do projeto de um arquivo é um número de 32 bits armazenado em cada arquivo e é herdado por todos os arquivos e subdiretórios criados sob um diretório pai com um ID de projeto atribuído. Isso permite atribuir limites de quotas a uma determinada árvore de subdiretórios independentemente das permissões de acesso ao arquivo, tais como quotas de usuários e projetos que dependem do UID e do GID. Embora isso seja semelhante a uma quota de diretório, a principal diferença é que o mesmo ID de projeto pode ser atribuído a vários diretórios de nível superior e não é estritamente hierárquico. Criptografia transparente O suporte para criptografia transparente foi adicionado ao kernel 4.1 do Linux em junho de 2015. Inicialização preguiçosa O recurso lazyinit permite limpar tabelas inode em segundo plano, acelerando a inicialização ao criar um novo sistema de arquivos ext4. Ele está disponível desde 2010 na versão 2.6.37 do kernel Linux. Write barriers ext4 permite a escrita de barreiras por padrão. Ele garante que os metadados do sistema de arquivos sejam escritos corretamente e ordenados no disco, mesmo quando os caches de gravação perdem energia. Isto vai com um custo de performance especialmente para aplicações que usam fsync fortemente ou criam e excluem muitos arquivos pequenos. Para discos com uma cache de gravação com bateria, a desactivação das barreiras (opção ‘barreira=0’) pode melhorar o desempenho de forma segura.

Deixe uma resposta

O seu endereço de email não será publicado.