sistema de arquivos para arquivamento

Eu tenho alguns dados complexos somente leitura no meu sistema de arquivos. Ele contém milhares de instantâneos de determinadas revisões de um repositório svn e a saída de testes de regressão. Arquivos idênticos entre instantâneos já são desduplicados usando links físicos. Dessa forma, a capacidade de armazenamento não precisa ser grande, mas ainda consome muitos inodes, e isso torna o fsck dolorosamente longo para o meu sistema de arquivos principal.

Gostaria de mover esses dados para outro sistema de arquivos, para que não afetem muito o sistema de arquivos principal. Você tem sugestões? O Squashfs parece ser uma opção possível, mas vou ter que verificar se ele consegue lidar com links físicos de forma eficiente.

Se é uma lentidão abs fsck, você tentou o ext4? Eles adicionaram alguns recursos que tornam o fsck realmente rápido , sem olhar para inodes não utilizados :

Fsck é uma operação muito lenta, especialmente o primeiro passo: verificar todos os inodes no sistema de arquivos. No Ext4, no final da tabela de inodes de cada grupo, será armazenada uma lista de inodes não utilizados (com uma soma de verificação, por segurança), para que o fsck não verifique esses inodes. O resultado é que o tempo total de fsck melhora de 2 a 20 vezes, dependendo do número de inodes usados ​​(http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4). Deve-se notar que é o fsck, e não o Ext4, quem criará a lista de inodes não utilizados. Isso significa que você deve executar o fsck para criar a lista de inodes não utilizados, e apenas a próxima execução do fsck será mais rápida (você precisará passar um fsck para converter um sistema de arquivos Ext3 em Ext4 de qualquer maneira). Há também um recurso que participa dessa aceleração do fsck - "grupos de blocos flexíveis"

O Btrfs possui suporte nativo para instantâneos, portanto você não precisaria usar links físicos para deduplicação. Você pode recriar sua configuração atual criando um sistema de arquivos btrfs e carregando-o com a primeira revisão necessária, tirando um instantâneo e, em seguida, acelerando o repositório para cada momento em que você precisar de um instantâneo e tirá-lo em cada degrau. Isso deve ser mais eficiente do que links físicos e também mais simples de configurar.

Também acho (embora não tenha certeza disso) que o squashfs deduplica arquivos de forma transparente; portanto, mesmo que não lide com links físicos, você ainda verá benefícios. Se você nunca precisar alterar os dados no sistema de arquivos, o squashfs provavelmente é o caminho a seguir, pois o fsck pode ser substituído pelo md5sum;)

Eu preferiria o XFS, pois tenho experiências muito boas com esse sistema de arquivos. Mas eu realmente recomendo que você faça um teste com seus dados e todos os sistemas de arquivos sugeridos.

Conheço várias lojas que usam um DataDomain exatamente para esse fim.

Seu script de arquivamento pode ser muito simples (tar ou rsync e cron, por exemplo), e você não precisa se preocupar em gerenciar links físicos ou diretórios que não podem ser vinculados na maioria dos sistemas de arquivos. Não há necessidade de cópias incrementais, exceto para economizar largura de banda. Toda a magia acontece embaixo da camada de blocos. Não é incomum hospedar dados virtuais de 15 a 20 TB, usando apenas 1-2 TB de espaço em disco real. Você ainda terá muito para seus backups de disco.

Os dados seriam veiculados por NFS ou iSCSI, mas não tenho certeza se isso é um problema

Quando o FreeBSD obtiver o ZFS v23, a desduplicação estará disponível para o resto de nós.