Um NAS pode mostrar capacidade livre e, ainda assim, rejeitar um ficheiro grande quando a quota, os metadados, o limite de ficheiros ou a alocação disponível no destino se esgotam.
O painel pode apresentar o espaço disponível de todo o pool, enquanto a partilha pertence a um conjunto de dados mais pequeno, a um volume thin, a uma quota de utilizador, a um sistema de ficheiros reservado ou a um perfil de metadados quase esgotado. Um carregamento grande também pode exigir espaço temporário, uma segunda cópia ou um tamanho de ficheiro individual que o sistema de ficheiros de destino não consegue representar. Comece pelo caminho exato que falha e pelo código de erro, em vez de presumir que o número geral de espaço livre descreve a operação.
Identifique o sistema de ficheiros e o limite efetivamente utilizados pela partilha
Resolva a partilha SMB ou da aplicação para obter o caminho no anfitrião, o ponto de montagem, o conjunto de dados, o subvolume, o volume thin e o pool subjacente. Registe os blocos livres, os inodes livres, a identidade do utilizador e o tamanho do ficheiro rejeitado.
A GNU explica que o df comunica o sistema de ficheiros montado associado a um caminho, não todos os pools, quotas, snapshots ou limites ao nível da aplicação acima e abaixo dele.
Se a partilha escrever numa partição do sistema ou num conjunto de dados montado mais pequeno, o espaço livre de todo o pool é irrelevante. Corrija o caminho ou a montagem antes de eliminar dados da camada de armazenamento errada.
Verifique as quotas de utilizador, grupo, conjunto de dados e partilha
Compare a vista de espaço livre do administrador com a quota aplicada ao utilizador SMB, grupo, conjunto de dados, projeto ou pasta partilhada efetivos. Faça o teste com a mesma conta que recebe o erro.
A Oracle documenta que as quotas e reservas do ZFS podem limitar um conjunto de dados, mesmo quando ainda existe espaço não utilizado no pool, ou reservar capacidade disponível para outro conjunto de dados.
Não remova quotas globalmente. Aumente apenas o limite comprovadamente responsável ou mova o ficheiro para um conjunto de dados cuja política de capacidade corresponda à carga de trabalho.
Compare o espaço de dados com os metadados e o espaço de trabalho de alocação
Inspecione os dados, os metadados, a alocação do sistema, os grupos de blocos e os contadores de reserva específicos do sistema de ficheiros. A criação de ficheiros grandes pode exigir atualizações de metadados e espaço de trabalho copy-on-write, além dos bytes do conteúdo.
A documentação do Btrfs explica que este pode devolver ENOSPC apesar do espaço livre visível quando os requisitos de alocação e copy-on-write não podem ser satisfeitos.
Se os metadados estiverem limitados, utilize diagnósticos suportados do sistema de ficheiros e ações de recuperação restritas. Não preencha o espaço restante com outro ficheiro de teste grande nem inicie um balanceamento sem filtros sem medir primeiro o espaço de trabalho.
Verifique os inodes e os limites de registos de ficheiros
Registe os inodes ou registos de ficheiros livres e conte os ficheiros pequenos em caches, repositórios de correio, miniaturas, pacotes extraídos e diretórios de aplicações. Uma grande capacidade em bytes não garante que seja possível alocar outra entrada de diretório ou registo de metadados.
A visão geral dos sistemas de ficheiros da Red Hat explica que o XFS aloca inodes dinamicamente e que as implementações dos sistemas de ficheiros têm limites distintos de inodes e registos de ficheiros.
Se os inodes estiverem esgotados, remova ou arquive uma cache com muitos ficheiros depois de a verificar, através da aplicação que a gere. Eliminar um único ficheiro grande não resolve uma escassez de registos de ficheiros.
Confirme o tamanho máximo de ficheiro e o formato do destino
Identifique o sistema de ficheiros de destino e compare o tamanho máximo de um único ficheiro com o carregamento tentado. Inclua discos amovíveis, destinos de cópia de segurança USB e pastas temporárias das aplicações.
A visão geral do NTFS da Microsoft mostra que o tamanho máximo do ficheiro depende do desenho do sistema de ficheiros e dos parâmetros de alocação, pelo que o espaço livre agregado não ultrapassa o limite de um único ficheiro imposto pelo formato.
Se a falha ocorrer perto de um limite consistente, como 4 GB, inspecione todos os sistemas de ficheiros intermédios e o caminho de carregamento. A reformatação destrói dados; por isso, migre primeiro os ficheiros verificados para outro local antes de alterar o formato do destino.
Meça os requisitos temporários, esparsos e de pré-alocação
Verifique se o carregador escreve um ficheiro temporário, pré-aloca todo o destino, mantém a versão antiga até à mudança de nome ou extrai um arquivo para ficheiros adicionais. Registe a alocação máxima, não apenas o tamanho final do ficheiro.
A chamada de sistema fallocate reserva espaço em disco para que as gravações posteriores não falhem por falta de capacidade, o que significa que uma aplicação pode rejeitar um ficheiro grande antes de transferir todos os seus dados.
Escolha um diretório temporário no pool de dados pretendido ou desative a pré-alocação apenas quando a aplicação o suportar de forma segura. Mantenha margem suficiente para o original, a cópia temporária, os metadados e os snapshots durante a substituição.
Reproduza o erro exato com um ficheiro controlado
Crie ficheiros de teste abaixo e acima do tamanho que provoca a falha, utilizando o mesmo utilizador, protocolo, caminho e aplicação. Registe o erro do cliente e o registo do servidor sem repetir continuamente as tentativas com o ficheiro de produção.
O guia da ZimaSpace sobre como encontrar utilizações inesperadas de espaço no NAS apresenta o método complementar para reconciliar as pastas visíveis com a alocação real do sistema de ficheiros.
O problema está resolvido quando o limite comprovado de quota, metadados, inodes, formato ou espaço temporário é corrigido e um ficheiro acima do tamanho que anteriormente falhava é gravado, fechado, reaberto e verificado com êxito. Pare as gravações se o sistema de ficheiros passar para o modo só de leitura ou comunicar corrupção ou erros de hardware.
Suporte e Dicas
Mais para Ler

O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...

Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...

Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...

