Adiciona um sistema de arquivos inteiro de 300 GB ao repositório Git Annex?

Question

Por padrão, recebo um erro dizendo que tenho muitos arquivos abertos do processo. Se eu levantar o limite manualmente, recebo um erro dizendo que estou sem memória. Por alguma razão, parece que o Git Annex em seu estado atual não está otimizado para esse tipo de tarefa (adicionando milhares de arquivos a um repositório de uma só vez).

Como uma possível solução, meu próximo pensamento foi fazer algo como:

cd /
find . -type d | xargs git annex add --$NONRECURSIVELY
find . -type f | xargs git annex add
    # Need to add parent directories of each file first or adding files fails

O problema com esta solução é que não parece que a documentação seja uma maneira de adicionar um diretório de forma não recursiva no Git Annex. Existe algo que está faltando ou uma solução para isso?

Se a minha solução proposta é um beco sem saída, existem outras maneiras pelas quais as pessoas resolveram esse problema?

    

Answer 1

Atualização pequena:

1. Todo esse problema foi totalmente erro do usuário. Minha unidade raiz é um SSD de 256 GB, enquanto uma das pastas que eu estava tentando adicionar foi mapeada para uma matriz RAID 1 de 1,5 TB. Não importa como eu tentei realizar isso, inevitavelmente teria tentado copiar mais arquivos para a pasta /.git do que a unidade poderia caber (duh). Não faço ideia do que pensei que ia acontecer: /.

2. É por isso que você não mexe com os diretórios do sistema ...

3. Inicializei o repositório Git Annex na unidade de 1,5 TB e copiei apenas os diretórios de nível raiz que eu queria fazer backup. O git annex add . normal funcionou de forma brilhante, e meu repositório esteve em processo de backup para o Glacier nos últimos cinco dias usando estes ganchos de geleira com anexo com poucos problemas.

Answer 2

Atualização: não faça isso.

Evidentemente, o Git Annex move cada arquivo adicionado a um repositório para alguma estrutura de diretórios em .git / annex / objects, e os substitui por links simbólicos para os arquivos reais em .git. Isso seria ótimo se eu não tivesse experimentado com a adição de / etc.

Escusado será dizer que servidor hosed. Felizmente, encontrei uma solução:

find /etc -type l | while read file ; do realpath='realpath "${file}"' ; rm "${file}" ; cp -rfa "${realpath}" "${file}" ; done

Editar: desconsiderar; Eu sou estúpido; o sistema ainda é lavado; esta vai ser uma noite longa.

Segunda edição: Gerenciado para descompactar o sistema. Envolveu muita reconstrução manual de / etc e reinstalar todos os pacotes, incluindo reconfigurar / desassociar um grande número deles e depurar / resolver muitos problemas com o APT. Não tentaria isso novamente.

Quanto ao problema da versão controlar 300 gigs de arquivos, eu voltarei com uma atualização sempre que eu decidir algo e fazê-lo funcionar (independentemente de estar ou não com o Git Annex).

    

Answer 3

Eu uso o anexo para gerenciamento de host assim:

• crie o repositório git anexo em / var / annex
• em / var / annex, tem um subdiretório para cada máquina - é para onde os arquivos são exclusivos dessa máquina. Por exemplo, /var/annex/mars.example.com/etc/default/krb5-kdc
• tem outro diretório comum para arquivos exclusivos do site, por exemplo, /var/annex/example.com/etc/resolv.conf
• use o gnu stow para gerenciar todos os links simbólicos em / apontando para / var / annex / *
• tem um script simples em /var/annex/example.com/usr/local/bin/ que executa gnu stow e git annex (o script é convertido em / usr / local / bin por todas as máquinas acima )

Isso tudo funciona como um "sistema de arquivos de administração" de baixa velocidade, distribuído, com controle de versão, teste e quaisquer verificações e balanços que você queira colocar em como você está usando git e git annex.

Se você está gerenciando suas máquinas de forma adequada, não precisa fazer o check-in do sistema de arquivos raiz inteiro - a maior parte não varia de uma máquina para outra. Você precisa ter alguma forma de gerenciar instalações e upgrades de pacotes, mas essas ferramentas podem ser verificadas no anexo, juntamente com os pacotes e outros blobs usados como dados de origem - novamente, todos com versão cortesia do git.