Entendendo o Extended File System

MinixFS

Em 1991, o Linux teve por seu primeiro sistema de arquivos o Minix. Ele teve algumas características e componentes interessantes para um sistema de arquivos para a época. Ele tinha a possibilidade de inicialização armazenada sempre para o primeiro bloco onde estão os carregadores de boot, algo fácil de ver ate nos sistemas atuais, tais como o ext?fs. Era definido tanto para partições de boot (em primária) com o flag-boot ”inicializavel”, ativo com no mínimo 720 kb em disquetes atraves do dispositivo /dev/fd0 e em partições de boot, para acontecer o mínimo do mínimo, um boot operacional. Apenas uma observação, no caso do proprio sistema MINIX, era necessário voce ter o s0 como partição primária para ser o seu root-fs e o s1 para conter o seu swap (área de troca com a memória). Mas na verdade mesmo, ele pedia era 2MB para arrancar um boot, o que na versão que acompanha o sistema MINIX3, ja exige que esta partição primária seja de 700MB no mínimo “para funcionar”.

O sistema de arquivos possui também o superbloco, que contem todos os principais dados sobre o filesystem e esta centralizado na memória conforme o computador é inicializado ou quando o sistema é utilizado. O superbloco contém informações detalhadas do dado, sistemas de informações do [inode] e a sua área de [data], onde todos os dados são armazenados. Bom para quem não sabe o que é um inode (inodo), ele é responsável por endereçar e relacionar os atributos no blocos do arquivo. Eles ocupam outro arranjo de informações, armazenando em listas encadeando todos os blocos do disco e suas associaçoes a arquivos e conforme os dados crescem no disco em bytes, este espaço cresce proporcionalmente, fazendo-se necessário numero de entradas conforme o numero de blocos, melhor dizendo, conforme os dados vão aumentando no disco essa listagem de armazenamento cresce linearmente. Ou seja, simplesmente pode ter falta de espaço desta área, mesmo com muitos MBs livres.

Extended File System
Tudo isso que eu comentei acima é recorrente a um sistema de arquivo qualquer, porem o Minix tinha um grande problema de desempenho e isso foi bastante significativo a ponto do Linux receber o extended file system, ou ext1 (vou chamar de ext1 ok?),  foi intruzido no Linux em 1992 recebendo o VFS (virtual file system) que tenta integrar diferentes sistemas de arquivos em uma estrutura bem organizada (ou ordenada), ou seja, ponteiro A sendo movimentado para o ponteiro B, independente da camada superficial do sistema de arquivos. Ele foi implementado na versão 0.96c do kernel e tinha um alongamento de dados em até 2GB, muito próximo o que existia no fat16 (msdos-fs), com a diferença que no fat16 cada processo tem seu próprio cache de buffer.

ext2fs
Depois veio o ext2fs em 1993 que trazia compatibilidade e os mesmos recursos de outros sistemas de arquivos da época, embora ele tenha sido criado especificamente para Linux, ele recebeu recursos do FFS do BSD. De acordo com a lenda o ext2fs suporta ate 2TB no total de armazenamento do filesystem, mas no kernel 2.6 isso foi extendido para 32TB, mas o tamanho máximo de alongamento do arquivo é de 16GB, que no kernel 2.6 isso cresceu para 2TB (na verdade no final do kernel 2.4). Com o lançamento do ext3fs com suporte ao journaling (logs), o ext2fs passou a ser recomendado para setores de boot, para aumento de performance e principalmente para dispositivos externos como pendrives e discos externos, ja que estes não necessitam *teoricamente* de journaling.

Journaling
Mas o que é journaling? O ext3fs veio com um [ PLUS ] do ext2fs, porem ele é dependente do sistema de arquivo ext2, tanto que se torna uma obrigatoriedade na sua compilação do kernel, pois é necessário marcar ambos ativos em [ module ] ou [ built-in ].

O jornaling (ou registros de log do sistema de arquivo), é um processo em que ele registra todas as atividades por meio de logs internos. Quando há um registro de dados no sistema as modificações são primeiramente gravadas nos registros de log, quando a atualização do dado é completada ele realiza o commit record e é gravado definidamente finalizando a operação. Como ja comentei, Isso fica em uma região interno do sistema de arquivo ao ser implementado no disco. Então para garantir a integridade dos dados e sua consistência, todos os dados registrados no sistema de  arquivo com suporte ao journaling somente são registrados quando ocorre o registro nos logs ou metadados, então se ocorre um [ crash ] no seu sistema de arquivos,ele simplesmente não perderá o dado. Bom, diz a lenda e realmente funciona. Antes no ext2 os dados perdidos eram armazenados no diretório lost+found e era uma bosta recuperar. O ext3fs separa uma área do disco para o arquivo de journal. Este procedimento ocorre tanto por journaling (registros normais), ordenado ( com maior segurança ) e o writeback ( mais rápido mas tornando menos confiável )

No caso do ext2 para o ext3 era necessário realizar uma conversão com o comando tune2fs com a opção -j. (exemplo: tune2fs -j /dev/seu_dispositivo)

ACL
Os sistemas de arquivos ext2fs, ext3fs e ext4fs. tambem suportam o uso de ACL, o que é praticamente um padrão nas especificações POSIX e o ACL geralmente trabalha com o modelo de 9 bits tradicional do UNIX e podem ser ativadas manualmente pelo “mount -o acl” ao montar o sistema, ou adicionado no /etc/fstab (e caso utilize o systemd, especificamente no .mount, lembrando que o fstab ainda funciona ).

ext4fs
Em 2008 (pelo que lembro), o ext4 foi adicionado definitivamente no kernel na versão 2.6.28, com melhorias significativas na compatibilidade com as versões anteriores como o ext3fs e um uma melhora absurda nos registros de alto desempenho, principalmente se tratando de arquivos largos e escalonáveis.  Você pode converter uma partição que utiliza o sistema de arquivos ext3 para ext4fs com o comando: tune2fs -O extents,uninit_bg,dir_index /dev/seu_dispositivo
Um dos grandes fatores do ext4fs é o aprimoramento de registros de data e hora, pois até o ext3fs fazia os registros em cálculos baseado em segundos e devido a capacidade e a escalongabilidade (palavra bonita) de discos e os demais, fez com que o desenvolvedores utilizassem de registros baseado em [ data e hora ], baseado nos padrões de nanossegundo (ai ja é loucura demais).
A escabilidade no ext4fs é algo bastante melhorado e supera sem duvidas o ext3fs.
O ext4fs também possui um alto nível de armazenamento e registros, ele inicialmente forneceu suporte a 1 EXABYTE e arquivos alcançando 16 TEBIbytes (TIB), levando em consideração blocos de 4kb o que é beeeemmmm mais que o ext3fs.

Extensões são a grande vantagem junto ao ext3fs, os arquivos eram armazenados em meio a mapa de bits livre e isso não é muito escalável. Ja no ext4fs através de suas extensões para aprimorar o armazenamento através de sua arvore, dando suporte separado a arquivos pequenos e a arquivos grandes porque um inode em ext4fs tem espaço suficiente para fazer referencia a extensões conforme o sistema de arquivo esta trabalhando.

Desempenho do ext4fs é algo muito melhor do que o ext3, pois fornece desempenho no quesito escalabilidade e confiabilidade, o que aprimora os registros mais ainda. Mas isso não foi uma maravilha total, inicialmente surtiu uma grande duvida na questão de acesso a algumas determinadas áreas de registros, justamente pela dificuldade que se tem de desenvolver um sistema de arquivos com alto desempenho e que atende diversas arquiteturas. Existe uma regra clara, desempenho vs comprometimento dos dados. Mas isso é algo vencido pelo ext4fs.

Há também a pré-locação persistente de registro de arquivos, pois o ext. usa uma técnica de performance conhecida como [ allocate-on-flush ], que possui um efeito no processamento, reduzindo a fragmentação do disco especialmente para arquivos que crescem conforme o seu uso ao mesmo tempo.

O ext4fs possui o recurso de dir_index automático e não tem limitações de 32.000 diretórios (especificamente 31998) e 32 mil links. Permitindo alocar vários blocos.
O ext4fs possui confiabilidade e o mesmo possui mecanismos de auto-repair para problemas com arquivos largos.

Também inclui o suporte a desfragmentação ONLINE, que evita a fragmentação do mesmo por um espaço de tempo enorme. Se engana quem acha que ext2, ext3 e ext4fs não fragmenta com a necessidade de desfragmenta o sistema de arquivos, isso é um mito. No ext3fs você desfragmentava o sistema de arquivos com o utilitário e2defrag, pois o sistema de arquivos no decorrer do seu uso intenso, pode informar através da ferramenta fsck, informar arquivos e diretórios em “non-contiguous”. Caso existe um valor alto conforme o numero de inodes utilizados, há sim uma necessidade de desfragmentação. No caso do ext4fs existe a ferramenta “e4defrag” que permite “reparar”estes arquivos com um custo de tempo bem menor.

O ext4fs também possui integrado ao seu recurso de journaling uma verificação por checksum, onde qualquer alteração nos registros de logs/metadados. Isso confirma ainda mais a integridade com segurança dos registros de log.

Para verificar seus pontos de montagens e quais são seus respectivos sistemas de arquivos, digite: df -hT, sendo o -h para o modo mais humano e o -T para exibir qual o filesystem da partição. Outro detalhe, é quando existe algum sistema de arquivo “ativo”no kernel, aqueles em funcionamento no momento, eles são apresentados no arquivo /proc/filesystems.

A materia é dedicada aos meus ex-alunos que me pediram.

[ ],
Aprigio
@aprigiosimoes

Powered by Moblie Video for WordPress + Daniel Watrous