Simples: você está procurando por mhddfs .
Ele finge ser um sistema de arquivos grande, grava nos discos na ordem em que foram mencionados e, eventualmente, move arquivos grandes para um dispositivo diferente, se o primeiro estiver cheio demais. Na verdade, ele também pode usar subpastas nos discos, permitindo a mesma funcionalidade.
Os discos individuais devem ser montados primeiro e permanecer acessíveis. Ele não altera os sistemas de arquivos e não se importa com o sistema de arquivos existente (desde que o espaço livre seja relatado corretamente pelo sistema de arquivos). Caso um disco seja perdido, você precisará remontar seus mhddfs novamente (em tempo real) e os dados nesse disco serão removidos.
Uso:
mhddfs /dir1,/dir2[,/path/to/dir3] /path/to/mount [-o options]
ou em /etc/fstab
mhddfs#/path/to/dir1,/path/to/dir2 /mnt/point fuse defaults 0 0
Complexo e poderoso: Você quer o unionfs .
Embora o mhddfs seja agradável e extremamente simples, tive problemas com as permissões de arquivo ao conceder acesso a outras pessoas via SSH. Não encontrei nenhuma solução, mas encontrei o unionfs.
O Unionfs também permite que você monte várias pastas em diferentes sistemas de arquivos em um, mas é mágico nas permissões. Você pode mesclar várias pastas somente leitura e uma gravável juntas, para que apareça como uma. As pessoas com quem você compartilhou sua pasta mesclada podem gravar em uma pasta somente leitura - como parece a elas - mas os arquivos acabam na única pasta gravável. Os CDs de inicialização do Linux funcionam assim, o disco gravável é um ramdisk. As pessoas podem até excluir arquivos em pastas somente leitura, o que realmente não exclui o arquivo, mas cria um arquivo de lista de permissões oculto em seu diretório de gravação. Se você pegar todas as opções, poderá basicamente usar seu sistema de arquivos como um SVN pobre .
Se você usar demais as opções do tipo SVN, poderá perder os dados existentes duas vezes (improvável no seu cenário, mas possível), enquanto a pasta gravável é preenchida com pequenos arquivos ocultos da lista de permissões. Fora isso, mantém seus discos limpos e utilizáveis individualmente. O que acontece se um arquivo for muito grande para um disco, ainda não sei.
Uso:
unionfs-fuse -o cow,max_files=32768 \
-o allow_other,use_ino,suid,dev,nonempty \
/path/to/dir1=rw:/path/to/dir2=ro:/dir3
/u/union/etc
onde =rwtorna a pasta lida e gravável e =rosomente leitura, mesmo que as permissões indiquem o contrário. Nisso etc/fstabé
unionfs-fuse#/path/to/dir1=rw:/path/to/dir2=ro:dir3 /path/to/mount fuse cow,allow_other 0 0
Se você estiver apenas conectando vários dispositivos, não haverá redundância e poderá perder os dados. Mas se você estiver usando um servidor de mídia / arquivo para uma empresa, não perca nada, porque você fez o backup de tudo em um servidor de backup / unidade de fita.
Por que você está evitando o RAID? O ponto do RAID é a disponibilidade; se você não quiser perder tempo devido a falha no disco, pode usar uma configuração RAID 1, que também pode acelerar suas leituras. Eles não são muito caros, pagam a si mesmos na primeira vez em que houver uma falha no disco e, se você REALMENTE evitar pagar por um cartão, poderá configurar o Linux para usar o RAID de software, embora seja necessário um pouco mais de cuidado na configuração e solução de problemas para garantir a substituição da unidade correta.
Caso contrário, você teria que pular algumas etapas para tentar recuperar quais dados você pode dos discos restantes. Seria possível, mas você está meio que pedindo muito mais problemas do que deveria. Obtenha um bom backup e reconsidere o RAID.
fonte
Se você estiver usando um sistema de arquivos que abrange todos os volumes LVM, todo o sistema de arquivos será danificado, pois o FS não conhece os volumes físicos subjacentes e não criará estruturas alinhadas a ele. Pode ser possível resgatar algumas das peças nos discos de trabalho, mas não há garantia para isso.
E apenas recuperar os arquivos do disco danificado também não funcionará pelo mesmo motivo.
fonte
Eu acho que uma rota muito mais simples seria configurar o mdadm para sua partição de mídia. Se você não possui o hardware para "RAID real", a rota mdadm seria consideravelmente mais fácil e parece atender aos seus requisitos de redundância e substituição simples de disco.
Para mais informações: http://en.wikipedia.org/wiki/Mdadm
Se você usar o mdadm e o RAID 5, poderá perder uma unidade e manter a matriz funcional, mas sofrerá uma degradação no desempenho.
fonte
Eu acho que o importante para entender o que não foi mencionado é que um arquivo em um sistema de arquivos não está necessariamente sentado em um local do disco. É dividido em blocos que podem residir em qualquer lugar dentro dos sistemas de arquivos. O primeiro 4K, se o seu arquivo estiver no disco1, o próximo disco2, etc. Você pode imaginar a bagunça de tentar recuperar alguma coisa se perder um pedaço do sistema de arquivos.
fonte
Btrfs é uma boa escolha aqui; você pode ter metadados resilientes à perda de um disco (o perfil do fragmento "raid1"); os dados nos outros discos ainda estarão acessíveis (só para esclarecer, isso se traduz em arquivos cheios de falhas onde quer que o disco ausente seja referenciado). Isso é feito executando o btrfs balance com um filtro :
fonte