filesystem para arquivamento

Question

Eu tenho alguns dados somente leitura complexos no meu sistema de arquivos. Ele contém milhares de instantâneos de certas 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 isso não afete muito o sistema de arquivos principal. Você tem sugestões? O Squashfs parece ser uma escolha possível, mas vou ter que verificar se ele pode lidar com links de forma eficiente.

    

Answer 1

Se for lentidão do fsck do abot, você tentou o ext4? Eles adicionaram alguns recursos a ele que tornam o fsck muito rápido não observando os inodes não usados :

Fsck is a very slow operation, especially the first step: checking all the inodes in the file system. In Ext4, at the end of each group's inode table will be stored a list of unused inodes (with a checksum, for safety), so fsck will not check those inodes. The result is that total fsck time improves from 2 to 20 times, depending on the number of used inodes (http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4). It must be noticed that it's fsck, and not Ext4, who will build the list of unused inodes. This means that you must run fsck to get the list of unused inodes built, and only the next fsck run will be faster (you need to pass a fsck in order to convert a Ext3 filesystem to Ext4 anyway). There's also a feature that takes part in this fsck speed up - "flexible block groups" - that also speeds up filesystem operations.

    

Answer 2

O Btrfs tem suporte nativo a instantâneos, para que você não precise usar links físicos para a duplicação. Você pode recriar sua configuração atual criando um sistema de arquivos btrfs e carregando-o com a revisão mais antiga de que precisa, obtendo um instantâneo e acelerando o repositório para cada ponto no tempo em que precisa de um instantâneo e tirando um instantâneo em cada degrau. Isso deve ser mais eficiente que hard links e mais simples de configurar também.

Eu também acho (embora esteja longe de ter certeza disso) que o squashfs desduplica os arquivos de forma transparente, por isso, mesmo que não manipule links físicos, você ainda verá benefícios. Se você nunca precisar alterar os dados no sistema de arquivos, então o squashfs provavelmente é o caminho a seguir, já que o fsck poderia ser substituído pelo md5sum;)

    

Answer 3

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

    

Answer 4

Conheço várias lojas que usam um DataDomain exatamente com esse objetivo.

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

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

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