O que faz com que um conjunto de dados ZFS pareça vazio depois de ser montado com êxito?
Um dataset ZFS pode indicar que está montado e, ainda assim, parecer vazio quando os dados esperados estão num dataset filho, num ponto de montagem oculto ou noutra raiz de importação.
A indicação de montagem confirma que um dataset está associado a um caminho, mas não prova que esse caminho é o esperado por uma aplicação ou utilizador, que os datasets filhos foram montados abaixo dele, ou que um descendente encriptado foi desbloqueado. Um dataset pai vazio pode estar completamente saudável, enquanto todos os ficheiros reais se encontram nos filhos. Comece por comparar as propriedades do dataset, o espaço referenciado, as tabelas de montagem e a vista do diretório antes de copiar dados ou alterar a estrutura do pool.
Compare o espaço do dataset com o diretório que abriu
Registe o nome do dataset e os valores de USED, REFER, AVAIL, MOUNTPOINT e MOUNTED. Em seguida, liste o diretório exato apresentado ao utilizador ou à aplicação.
Se o dataset indicar quase nenhum dado referenciado, os ficheiros podem pertencer a um dataset filho, snapshot, clone ou a outro dataset com um nome semelhante. O manual do ZFS do FreeBSD descreve os datasets como sistemas de ficheiros geridos separadamente, pelo que a utilização ao nível do pool e um diretório aberto não representam necessariamente o mesmo dataset.
Não conclua que houve perda de dados apenas com base no navegador gráfico de ficheiros. Compare a vista das propriedades ZFS, a tabela de montagem do sistema operativo e uma shell local com privilégios de root no anfitrião, fora de qualquer contentor ou espaço de nomes restrito de uma aplicação.
Verifique em conjunto mountpoint, mounted e canmount
Confirme se o ponto de montagem do dataset é explícito ou herdado, se está realmente montado nesse caminho e se canmount está definido como on, off ou noauto.
A documentação da Oracle sobre as propriedades do ZFS explica que mountpoint e canmount determinam se um dataset é montado automaticamente, apenas quando solicitado ou utilizado somente para transmitir propriedades aos descendentes.
Um dataset pode fornecer propriedades herdadas aos seus filhos e permanecer intencionalmente desmontado. Por outro lado, um dataset que utilize um ponto de montagem legacy pode parecer correto nas propriedades ZFS, mas depender de uma entrada de montagem separada do sistema que não foi executada.
Inspecione as montagens dos datasets pai e filho
Liste a árvore completa de datasets abaixo do pool e ordene-a por ponto de montagem. Compare o dataset pai com todos os filhos que deveriam conter ficheiros de utilizadores, dados de aplicações, cópias de segurança ou multimédia.
É comum um pai estar vazio quando existe apenas para organizar propriedades e pontos de montagem. O espaço de nomes de datasets ZFS do FreeBSD trata cada filho como um dataset gerido individualmente, pelo que pool/data pode estar vazio enquanto pool/data/photos contém os ficheiros reais.
Se o pai for montado, mas um filho não, diagnostique o filho separadamente. Verifique canmount, as chaves de encriptação, pontos de montagem em conflito, importações que falharam e se um serviço foi iniciado antes de a montagem do filho estar concluída.
Verifique se a montagem ocultou ficheiros que já existiam no diretório
Podem existir ficheiros no diretório normal antes de um dataset ser montado sobre ele. Depois de o dataset ZFS ser montado, esses ficheiros subjacentes ficam ocultos nesse caminho, embora continuem no sistema de ficheiros raiz.
Desmonte o dataset apenas durante uma janela de manutenção controlada e inspecione o diretório subjacente a partir do anfitrião. O manual de montagem do Linux afirma que os conteúdos preexistentes do ponto de montagem ficam invisíveis enquanto o sistema de ficheiros montado ocupa esse caminho.
Também pode ocorrer o problema inverso: uma montagem ZFS esperada falha, deixando visível aos utilizadores e contentores o diretório subjacente vazio. Isso pode fazer com que um dataset saudável pareça vazio, quando simplesmente não está associado ao caminho disponibilizado.
Exclua uma raiz alternativa e o comportamento de montagens legacy
Verifique se o pool foi importado com uma raiz alternativa, uma opção de recuperação, um caminho de montagem temporário ou um nome de pool diferente. Um dataset pode ter sido montado com sucesso sob um caminho de recuperação com prefixo, em vez da sua localização normal de produção.
A importação de um pool com uma raiz alternativa reescreve as localizações de montagem dos datasets relativamente a essa raiz temporária. A referência do zpool import do Ubuntu documenta que -R define altroot, enquanto -N pode importar sem montar os sistemas de ficheiros.
Inspecione também os datasets cujo ponto de montagem é legacy. Nesse modo, o ZFS não gere automaticamente a montagem, pelo que a configuração de montagem do sistema operativo passa a ser a fonte de verdade.
Verifique os filhos encriptados e os espaços de nomes de montagem dos contentores
Um dataset filho encriptado pode permanecer indisponível depois de o pai ser montado se a chave não tiver sido carregada ou se a montagem do filho tiver falhado. O diretório pai parece então vazio ou incompleto, embora o pool esteja online.
Verifique o estado da chave e da montagem de cada descendente encriptado e compare o caminho no anfitrião com o caminho apresentado ao contentor. A documentação do LXD da Canonical explica que os dispositivos de disco dos contentores associam origens do anfitrião a caminhos de instância separados, pelo que um dataset filho visível no anfitrião pode continuar ausente de uma montagem antiga do contentor.
Se o anfitrião vir os dados, mas um contentor não, inspecione a origem da montagem bind do contentor e a propagação da montagem. Um contentor criado antes de o filho ZFS ser montado pode continuar a ver o diretório subjacente vazio até o serviço ser recriado ou a montagem ser propagada corretamente.
Restaure a vista correta sem copiar o dataset
Corrija a propriedade ou o caminho mínimo comprovadamente responsável: monte o filho em falta, corrija um ponto de montagem herdado, remova uma raiz alternativa não intencional, repare a entrada de montagem legacy, carregue a chave de encriptação ou recrie o contentor com a origem bind correta.
A lista de verificação de recuperação de servidores domésticos da ZimaSpace apresenta a regra complementar: confirme a camada de armazenamento e o estado das montagens antes de executar ferramentas de reparação ou restaurar dados.
O diagnóstico está concluído quando os datasets esperados e as montagens dos filhos aparecem nos caminhos pretendidos, o espaço referenciado corresponde aos ficheiros visíveis, as aplicações veem a mesma árvore que o anfitrião e a disposição se mantém após exportar, importar, reiniciar o serviço e reiniciar o sistema.
Produtos recomendados
Suporte e Dicas
Mais para Ler
Guia de armazenamento para gravação de TV em direto: capacidade, retenção e limpeza
Meça gravações reais, reserve margem de segurança, combine limites de idade e capacidade e confirme que o programa elegível mais antigo é removido antes...
Fluxo de recuperação de metadados de multimédia doméstica após o restauro de uma base de dados
Proteja o estado restaurado, verifique a identidade e os caminhos dos ficheiros multimédia e, em seguida, corrija as capas ou correspondências em falta numa...
Lista de verificação de compatibilidade do cliente Jellyfin para áudio, vídeo e legendas
Teste ficheiros representativos, uma variável de cada vez, e registe Direct Play, remux, conversão de áudio, transcodificação de vídeo ou falha para cada cliente.
