FSArchiver com suporte ao XFS V5

Meus agradecimentos ao Francois Dupoux pela presteza em modificar o FSArchiver de modo a torná-lo compatível com XFS V5.

A partir do FSArchiver 0.6.20 fica assim:

- Imagens contendo XFS criadas com FSArchiver ≤ 0.6.19 são sempre restauradas como XFS V4.
- XFS V4 sempre é criado com -n ftype=0 para garantir ampla compatibilidade.
- Imagens criadas com FSArchiver ≥ 0.6.20 armazenam a versão do XFS. Dependendo da versão da suíte xfsprogs usada no momento da restauração, o comportamento é o seguinte:
- Se a imagem contiver XFS V4, é idem acima.
- Se a imagem contiver XFS V5, é restaurado mantendo a versão 5 se xfsprogs ≥ 4.3.0, porque apenas a partir dessa versão o mkfs.xfs permite definir o UUID no momento da criação do sistema de arquivos. Como em todos os blocos de metadados do XFS V5 o UUID está estampado, trocá-lo depois de ter sido criado (possível a partir de xfsprogs ≥ 4.2.0) joga o kernel mínimo necessário para o 4.3. Sem contar que o sistema de arquivos continua usando o UUID antigo para identificar os metadados. A única solução limpa é defini-lo via mkfs.xfs, que também mantém o kernel mínimo no 3.15 (-m crc=1,finobt=0) ou 3.16 (-m crc=1,finobt=1).
- Se a imagem contiver XFS V5 e tivermos xfsprogs < 4.3.0, o programa faz downgrade para XFS V4 e emite um aviso. Assim o administrador não fica na mão num caso de emergência.
- A imagem armazena se o sistema de arquivos XFS V5 original tinha finobt habilitado ou não. A configuração é respeitada ao restaurar o volume (pressupondo xfsprogs ≥ 4.3.0).

Parte da empreitada foi o trabalho de pesquisar quais recursos eram suportados por cada versão das ferramentas. Francois desenvolveu a lógica e programou-a em C, cujo resultado testei usando diferentes combinações de imagens (V4-0.6.19, V4, V4-com-ftype, V5, V5-sem-finobt) e versões da suíte xfsprogs (3.1.9, 3.2.0, 3.2.2, 4.3.0). Ganhei até uma menção no arquivo THANKS. ☺

Feliz 2016 a todos os leitores!