Me deparei com isso enquanto procurava para ver se o sistema de arquivos raiz pode estar em um volume lógico provisionado thin. É útil saber que pode.
Para responder (e explicar ainda mais) sua pergunta, da saída lvs
, parece que seu grupo de volumes inicial foi originalmente alocado como um volume lógico padrão swap
usando 16G e um volume lógico de pool provisionado thin pool00
. Sem a saída de lvs -a
, o tamanho do volume lógico de metadados subjacente não pode ser determinado; o tamanho do volume de dados é de 41,66G.
O volume lógico root
foi então criado como um volume lógico provisionado thin em cima de pool00
, mas foi alocado em excesso (ou estendido mais tarde) para ser 50G em cima de um volume de dados 41.66G. Presumivelmente, o LVM permite isso assumindo que o volume do conjunto será estendido antes de ficar cheio, mas isso não aconteceu.
Como você encontrou corretamente, o sistema de arquivos não retorna blocos para o LVM quando eles não são mais usados, embora eles sejam reutilizados por si mesmos, embora você esteja usando apenas 14G em arquivos reais, outro 27.66G foi alocado do LVM em root
e, em seguida, removido do sistema de arquivos, mas na verdade não descartado e retornado ao LVM. Portanto, você ficou sem espaço no volume pool00
subjacente.
Como você determinou corretamente, executar fstrim
na verdade irá descartar blocos não utilizados no sistema de arquivos, notificando o LVM de que eles podem ser reutilizados e liberando espaço em pool00
.
Como você moveu swap
em outro lugar, provavelmente seria uma boa ideia usar lvextend
e aumentar o tamanho de pool00
para pelo menos 50G, o tamanho atual de root
.
Como alternativa, agende fstrim
para ser executado a cada poucas semanas ou mais para descartar blocos não utilizados.