XFS está ganhando tração

Que bom o XFS estar ganhando tração ultimamente depois da Red Hat decidir usá-lo como sistema de arquivos padrão no RHEL 7. Comentei tempos atrás que não faz sentido rodar o fsck.xfs pois é um shell script inócuo. A alternativa para ter uma linha a menos no journal (e uma invocação a menos de shell) é colocar fsck.mode=skip nas opções de boot. Para quem só usa sistemas de arquivos XFS, tudo bem. Para quem tem outros tipos de sistemas de arquivos, é um remédio forte demais.

Distribuir fsck.xfs e fsck.btrfs falsificados, que não servem para nada, era algo que fazia sentido em épocas passadas quando os inits estavam no tempo da pedra e o fsck (util-linux) não sabia contornar a falta deles. Como Tom comenta, o fsck ≥ 2.25 não retorna erro caso não existam. Ou os desenvolvedores das suítes xfsprogs e btrfs-progs os linkam a /usr/bin/true, condição que reflete o que cada comando (não) faz e é considerada implementação inexistente pelo systemd ≥ 215, ou não distribuem fsck.<sistema> nenhum! Infelizmente, estamos amaldiçoados pelo velho chavão sobre "escolha" e, para manter compatibilidade com motores a vapor, é mais uma questão que pode acabar não sendo resolvida tão cedo em sua raiz.

Zbigniew propôs uma lista negra que faria o systemd pular a verificação com XFS e Btrfs. Não fez muito sucesso. Concordo com Lennart. Seria quebra-galho, não condizente com a natureza estruturante do projeto. Vamos aguardar para ver o que resulta disso.

Aproveitando o assunto, mudança recente no systemd-fsck apareceu na versão 213. É possível passar a opção de boot fsck.repair=preen|yes|no, que traduz-se em -a, -y e -n, respectivamente, na execução do fsck. Caso a opção não seja especificada, preen é assumido, mantendo o comportamento anterior.

A partir do systemd 209, a forma como a última coluna do fstab (fs_passno) é interpretada foi alterada. A ordem numérica não tem mais importância e o campo é tratado como um boleano. Se for zero, o volume não é verificado. Se for maior do que zero, é verificado. O volume do diretório raiz sempre é verificado primeiro. Nos demais, o fsck sabe serializar a verificação em volumes presentes no mesmo disco. Na versão 213, o udev ganhou uma API para suprimir o processamento de seus eventos em dispositivos de armazenamento através de locks BSD (útil para programas de particionamento), que foi aprimorada na versão 214. A nova API, contudo, conflita com o fsck, que usa a mesma lógica quando invocado com -l.

Por isso, foi desabilitado temporariamente o uso de -l no systemd 214 até a versão 2.25 da suíte util-linux, contendo a correção, ser lançada (deve ser um backport simples de fazer).

Apesar do formato V5 do XFS estar em teste há mais de um ano e ter sido considerado estável no kernel 3.15 e xfsprogs 3.2.0, é depois de entrar no campo de batalha que a sintonia fina do código começa.

Uma adição que o kernel 3.16 e xfsprogs 3.2.1 trarão é o free inode btree index, apenas disponível no formato V5 e não criado automaticamente (precisa de -m finobt=1). Separa o índice de inodes livres numa nova árvore B+ em cada allocation group (AG). Antes, os inodes livres e alocados eram indexados na mesma árvore.

No próximo openSUSE, volumes XFS criados pelo YaST serão V5 por padrão. Improvável o SLES 12 não herdar tal característica. A SUSE está confiante no Btrfs, que tende a ser o futuro sistema de arquivos padrão da distribuição do camaleão. Porém, o XFS contina sendo o sistema para large or lots com sua escalabilidade provada. Isso corrobora com esta apresentação onde claramente os EXT são deixados de lado. Veja que, em "New filesystem? → Yes", não são citados.

Relacionado:
Nem tudo da Apple é a quinta-essência