Theodore Ts'o é um developers do kernel mais conhecidos com responsabilidades em file systems (ext3, etx4) e na organização das Linux Kernel Summit.
Coordenei a mesa da apresentação dele e foi muito interessante. O Ted apresentou os avanços no Ext 4.
Como é esperado, o Ext4 consiste no Ext3 com mudanças produndas. Ao deixar de existir a tree 2.7, fazer mudanças profundas no ext3 faria infeliz muitos kernel developers que o utilizam.
Copiou-se então a directoria ext3 para ext4 e começou a trabalhar-se a partir daí.


Algumas das principais mudanças do Ext4 que ele apresentou:
  • Nos inodes, trocar os mapas de indirecção (dupla, tripla) que indicam os blocos do disco onde se encontra o ficheiro por "extents maps". Os maps "extents" têm uma entrada para um bloco contíguo de dados. Algo como: início lógico, num. de blocos, localização física.
  • 64 bit block numbers: para permitir file systems com mais de 8TB. Em parte, já foi resolvido com o patch do Lustre para 48 bit block numbers.
  • Expanded inodes: para permitir mais atributos. Hoje são utilizados por indexadores como o Beagle ou para segurança como é feito pelo SE Linux. Hoje este problema é resolvido com a criação de file system com blocos de maior dimensão.
  • Delayed allocation: atrasa a escrita em disco para usufruir se entretanto não for preciso.
  • Persistent file: ou seja, permitir uma pré-alocação de espaço por aplicações como base de dados e video digital recorders. Ao estar contiguo garante melhor velocidade de acesso. Hoje é feito enchendo de 0.
  • Metadata checksumming: foi sugerido como prova de conceito no artigo "iron fs" por parte de uns alunos da Univ. de Wisconsin. A ideia é que apesar do tamanho médio dos ficheiros e dos discos estar a crescer, a  fiabilidade por MB dos discos mantém-se estável. O que significa que a probabilidade de problemas num ficheiro vai crescendo. A ideia é aqui é fazer checksums de extents, superblock, block group.. Tudo excepto os "data blocks". Tem a vantagem de apressar o e2fsk por escusa de verificar os checksums validados.
Foram mostrados alguns benchmarks, com o disclaimer de que alguns (como o dbench) não mapeiam bem a realidade.
Nos mostrados (sequential write), o desempenho era algo como:
  xfs > ext3 + extents > jfs > ext3 c/ delayed > ext3

O ext4 está em Alpha e, segundo o Ted Ts'o, e provavelmente no próximo RHEL estará pronto para produção. Mas, claro, depende do feedback que forem tendo...

Por fim, existe bastante abertura para a participação de developers no ext4. Seja para testar, patches,. .. Há mailing list , wiki e IRC para comunicar com a equipa.
publicado por Tintim às 22:54