partição raiz thin provisioned no Centos 7

2

Parece que minha partição raiz (desconhecida para mim) thinly provisioned era um pouco magra demais. O sistema foi totalmente sem resposta, intermináveis mensagens no console:

kernel: Buffer I/O error on device dm-3, logical block 2449799
kernel: lost page write due to I/O error on dm-3

No começo eu suspeitava de discos defeituosos, mas o controlador RAID parecia feliz com eles. Após a reinicialização forçada, desenterre essa joia em / var / log / messages:

Jan 22 02:31:31 server kernel: device-mapper: thin: 253:2: reached low water mark for data device: sending event.
Jan 22 02:31:31 server kernel: device-mapper: thin: 253:2: switching pool to out-of-data-space mode
Jan 22 02:32:31 server kernel: device-mapper: thin: 253:2: switching pool to read-only mode

Parece que o / root é thinly provisioned e ficou sem espaço (chutando-me por aceitar a idéia de partições do assistente de instalação do Centos). Eu não estou muito familiarizado com o provisionamento thin, então o que me deixa perplexo é:

# lvs
  LV     VG     Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00 centos twi-aotz-- 41.66g               100.00 46.82                           
  root   centos Vwi-aotz-- 50.00g pool00        83.33                                  
  swap   centos -wi-ao---- 16.00g

Eu entendi que há um pool00 em 50GB vg "centos" que inclui volumes lógicos "swap" e "root"? Em caso afirmativo, por que um pool de 50 GB fica sem espaço se o root usa apenas 14 GB de dados de acordo com o df e o swap é de 16 GB no total?

edite: Em uma tentativa de aliviar as restrições de espaço, eu removi completamente a partição swap e a criei em outro lugar. Então agora:

  #lvs
  LV     VG     Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00 centos twi-aotzM- 41.66g               100.00 46.82                           
  root   centos Vwi-aotz-- 50.00g pool00        83.33

#df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   50G   10G   41G  20% /
devtmpfs                 7.8G     0  7.8G   0% /dev
tmpfs                    7.8G     0  7.8G   0% /dev/shm
tmpfs                    7.8G   17M  7.8G   1% /run
tmpfs                    7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/sda2                497M  154M  343M  31% /boot

De alguma forma, eu ainda alcanço "marca d'água baixa" em um pool 41G com uma partição que tem 10 GB de dados.

    
por Xfzr 22.01.2017 / 20:48

2 respostas

2

No caso de alguém se deparar com o mesmo problema, respondo a mim mesmo:

fstrim -v -a

ou

fstrim -v /

é o que ajuda. O sistema de arquivos não retorna blocos não utilizados ao conjunto, para que possam ser reutilizados (pelo mesmo sistema de arquivos, neste caso).

    
por 13.04.2017 / 12:54
0

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.

    
por 17.03.2018 / 17:13

Tags