Quais são as possíveis conseqüências de enlouquecer com vdevs baseados em arquivos esparsos para uma migração do LVM para o ZFS?

Question

Eu tenho brincado com o ZFS depois de ter aceito que é maduro o suficiente, eu não deveria me queimar.

Agora, para migrar a caixa NAS doméstica, que atualmente é uma configuração LVM JBOD bastante completa, mas tenho um pouco de espaço não alocado em apenas uma unidade.

Eu tenho experimentado com o zfs usando zpools criados em arquivos esparsos. Substituir o arquivo vdevs baseado em partições físicas parece ser um caminho muito flexível.

Estou imaginando o que poderia acontecer se eu levasse essa ideia ao extremo, e criasse vdevs de arquivo esparso do mesmo tamanho que o hardware existente, dentro desse sistema de arquivos já muito completo, e movesse o conteúdo do LVM para dentro o array ZFS.

Em teoria, desde que o espaço livre no sistema de arquivos LVM permaneça o suficiente para acomodar o crescente ZFS, à medida que os arquivos forem removidos, ele deve continuar. Então, eventualmente, o sistema de arquivos LVM estaria vazio, além das imagens reais do ZFS, que poderiam ser substituídas por partições físicas.

Espero que haja um impacto sério no desempenho devido à fragmentação, no mínimo.

Isso soa totalmente maluco na superfície, por que copiar arquivos em outro contêiner no mesmo sistema de arquivos. Portanto, acredito que esse conjunto de dados se beneficiaria da alternância da desduplicação e da compactação, o que poderia resultar em muito mais espaço livre. O principal objetivo, porém, é ganhar a flexibilidade de ter os dados em um pool do ZFS que podem ter seus 'drives' atualizados, isto é, substituídos por hardware físico

Esta pergunta maluca foi inspirada por esta postagem do blog ao converter o nível de invasão de uma matriz usando um dispositivo de loopback como uma substituição temporária de disco rígido.

    

Answer 1

Colocar seu zpool como arquivos em um sistema de arquivos existente significa que você está contando com esse sistema de arquivos para fornecer consistência (o que parece ser perigoso, na melhor das hipóteses) e também que o ZFS não pode tirar proveito do armazenamento em cache. Não tenho certeza de quão bem o ZFS lidaria com a transferência de arquivos para dispositivos físicos; o próprio sistema de arquivos provavelmente não teria nenhuma queixa real, mas você pode se deparar com coisas como não gostar de vdevs indo para dispositivos menores (pelo que eu li, um número de pessoas tem sido por este ter definido autoexpand=on , então você pode querer ter cuidado com essa propriedade e seu primo autoreplace ). Como alternativa, você estaria executando o ZFS na parte superior do LVM, o que provavelmente é possível, mas não permite que o ZFS manipule os dispositivos de maneira inteligente, pois ele só verá um dispositivo grande. Lembre-se de que o ZFS não é apenas um sistema de arquivos, também é um gerenciador de volumes, portanto, substitui adequadamente ambos o sistema de arquivos regular e o LVM. Muitos de seus recursos, incluindo o posicionamento de metadados em vários discos e várias cópias de dados para redundância em um zpool, funcionam melhor quando o ZFS tem uma boa ideia do layout de armazenamento físico.

Eu estive pensando em migrar para o ZFS também, e a melhor opção que consegui criar para migração envolve mais um disco rígido. Instale outro disco rígido que tenha pelo menos o tamanho da menor unidade física que você possui atualmente na matriz, crie um pool de ZFS e um sistema de arquivos (configurado para JBOD, mas com apenas um dispositivo) e mova o máximo para ele. posso. (Como não estou executando o LVM, movo tudo na unidade menor para o ZFS fs.) Reduza o array do LVM removendo um disco físico dele, expanda o zpool do ZFS para esse disco agora livre, mova um pouco mais arquivos, enxaguar e repita até terminar. Com o uso inteligente de links simbólicos ou um bom manuseio de exportações, você pode até mesmo manter o processo transparente para qualquer pessoa que possa estar usando arquivos nessa caixa do NAS enquanto isso.