"Não há espaço no dispositivo" apesar de ter muito espaço, no btrfs

Question

Quase em todos os lugares estou recebendo falhas nos registros reclamando sobre No space left on device

Logs do Gitlab:

==> /var/log/gitlab/nginx/current <==
2016-11-29_20:26:51.61394 2016/11/29 20:26:51 [emerg] 4871#0: open() "/var/opt/gitlab/nginx/nginx.pid" failed (28: No space left on device)

Registros de e-mail do Dovecot:

Nov 29 20:28:32 aws-management dovecot: imap([email protected]): Error: open(/home/vmail/emailuser/Maildir/dovecot-uidlist.lock) failed: No space left on device

Saída de df -Th

Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/xvda1     ext4      7.8G  3.9G  3.8G  51% /
devtmpfs       devtmpfs  1.9G   28K  1.9G   1% /dev
tmpfs          tmpfs     1.9G   12K  1.9G   1% /dev/shm
/dev/xvdh      btrfs      20G   13G  7.9G  61% /mnt/durable
/dev/xvdh      btrfs      20G   13G  7.9G  61% /home
/dev/xvdh      btrfs      20G   13G  7.9G  61% /opt/gitlab
/dev/xvdh      btrfs      20G   13G  7.9G  61% /var/opt/gitlab
/dev/xvdh      btrfs      20G   13G  7.9G  61% /var/cache/salt

Parece que também há muito espaço inode. Saída de df -i

Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/xvda1     524288 105031 419257   21% /
devtmpfs       475308    439 474869    1% /dev
tmpfs          480258      4 480254    1% /dev/shm
/dev/xvdh           0      0      0     - /mnt/durable
/dev/xvdh           0      0      0     - /home
/dev/xvdh           0      0      0     - /opt/gitlab
/dev/xvdh           0      0      0     - /var/opt/gitlab
/dev/xvdh           0      0      0     - /var/cache/salt

Saída de btrfs fi show

Label: none  uuid: 6546c241-e57e-4a3f-bf43-fa933a3b29f9
        Total devices 4 FS bytes used 11.86GiB
        devid    1 size 10.00GiB used 10.00GiB path /dev/xvdh
        devid    2 size 10.00GiB used 9.98GiB path /dev/xvdi
        devid    3 size 10.00GiB used 9.98GiB path /dev/xvdj
        devid    4 size 10.00GiB used 9.98GiB path /dev/xvdk

Saída de btrfs fi df /mnt/durable

Data, RAID10: total=17.95GiB, used=10.12GiB
Data, single: total=8.00MiB, used=0.00
System, RAID10: total=16.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, RAID10: total=2.00GiB, used=1.74GiB
Metadata, single: total=8.00MiB, used=0.00
unknown, single: total=272.00MiB, used=8.39MiB

Qual poderia ser a causa disso? Estou usando um linux base AMI ec2 kernal versão 4.4.5-15.26.amzn1.x86_64

Atualizar

A execução do comando sugerido abaixo btrfs fi balance start -dusage=5 /mnt/durable me devolveu um erro dos seguintes itens:

ERROR: error during balancing '/mnt/durable' - No space left on device There may be more info in syslog - try dmesg | tail

Depois de excluir manualmente um monte de arquivos maiores, totalizando ~ 1GB, reiniciei a máquina e tentei novamente, certificando-se de que estava usando o sudo, e o comando foi executado. Eu, então, reiniciei minha máquina novamente para uma boa medida e parece ter resolvido o problema

    

Answer 1

Bem-vindo ao mundo do BTRFS. Tem algumas características tentadoras, mas também algumas questões irritantes.

Em primeiro lugar, algumas informações sobre sua configuração, parece que você tem quatro unidades em um volume "RAID 10" do BTRFS (portanto, todos os dados são armazenados duas vezes em discos diferentes). Este volume BTRFS é então dividido em subvolumes em diferentes pontos de montagem. Os subvolumes compartilham um conjunto de espaço em disco, mas possuem números de inode separados e podem ser montados em locais diferentes.

O BTRFS aloca espaço em "pedaços", um pedaço é alocado para uma classe específica de dados ou metadados. O que pode acontecer (e parece que aconteceu no seu caso) é que todo o espaço livre é alocado a blocos de dados, não deixando espaço para metadados

Parece também que (por razões que não entendo completamente) que os BTRFs "esgotam" o espaço de metadados antes que o indicador da proporção de espaço de metadados utilizado atinja 100%.

Isso parece ser o que aconteceu no seu caso, há muito espaço livre para dados, mas nenhum espaço livre que não tenha sido alocado para blocos e espaço livre insuficiente nos fragmentos de metadados existentes.

A correção é executar um "rebalanceamento". Isso moverá dados para que alguns trechos possam ser retornados para o pool livre "global", onde eles podem ser realocados como partes de metadados

btrfs fi balance start -dusage=5 /mnt/durable

O número após -dusage define quão agressivo é o rebalanceamento, ou seja, quão perto de esvaziar os blocos devem ser para serem reescritos. Se a balança diz que reescreveu 0 blocos tente novamente com um valor maior de -dusage .

Se a balança falhar, eu tentaria reinicializar e / ou liberar algum espaço removendo os arquivos.

    

Answer 2

Como você está executando o btrfs com uma configuração de RAID, tente executar uma operação de balanceamento.

btrfs balance start /var/opt/gitlab

Se isso gerar um erro sobre não ter espaço suficiente, tente novamente com esta sintaxe:

btrfs balance start -musage=0 -dusage=0 -susage=0 /var/opt/gitlab 

Repita esta operação para cada sistema de arquivos btrfs onde você está vendo erros de espaço. Se o seu problema de espaço se deve ao fato de os metadados não estarem sendo distribuídos pelos discos espelhados, isso pode liberar algum espaço para você.

    

Answer 3

No meu sistema, adicionei o seguinte trabalho no cron.monthly.

O clear_cache remount é devido a alguns problemas de corrupção que o btrfs estava tendo com os mapas gratuitos. (Eu acho que eles finalmente encontraram o problema, mas a questão é tão chata, eu estou disposto a pagar para reconstruir os mapas uma vez por mês.)

Eu aumento as opções usage para liberar espaço gradualmente para balanços cada vez maiores.

#!/bin/sh

for mountpoint in 'mount -t btrfs | awk '{print $3}' | sort -u'
do
    echo --------------------------
    echo Balancing $mountpoint :
    echo --------------------------
    echo remount with clear_cache...
    mount -oremount,clear_cache $mountpoint
    echo Before:
    /usr/sbin/btrfs fi show $mountpoint
    /usr/sbin/btrfs fi df $mountpoint
    for size in 0 1 5 10 20 30 40 50 60 70 80 90
    do
        time /usr/sbin/btrfs balance start -v -musage=$size $mountpoint 2>&1
        time /usr/sbin/btrfs balance start -v -dusage=$size $mountpoint 2>&1
    done
    echo After:
    /usr/sbin/btrfs fi show $mountpoint
    /usr/sbin/btrfs fi df $mountpoint
done

Se você chegar ao ponto em que não pode reequilibrar porque não tem espaço suficiente, a recomendação é adicionar temporariamente outro dispositivo de bloco (ou dispositivo de loopback em outro disco) a seu volume durante o reequilíbrio e, em seguida, remova-o.

    

Answer 4

Isso não é tanto um problema com o btrfs, mas isso é algo que foi feito nesse sistema. Isso parece ser o resultado de um reequilíbrio incompleto de uma política de alocação 'única' para uma política de alocação 'raid 10', conforme evidenciado pela grande quantidade de blocos alocados individuais. Provavelmente começou como single e, em seguida, uma conversão foi interrompida. Um pool com essa alocação inconsistente está fadado a ter ... bem, problemas de alocação.

Considere que você tem 61% do seu pool consumido. Sua política de alocação é RAID10, portanto, isso deve resultar em um máximo de 50% de consumo de pool antes de ficar cheio, já que tudo é replicado 2. É por isso que sua conversão de single para RAID 10 falhou (e continua). Eu só posso imaginar, mas provavelmente foi alocado no meio de um reequilíbrio. Não há espaço disponível no seu dispositivo para rebalancear em um RAID 10 com os discos que você possui. A única razão pela qual você chegou a 61% é porque seus discos são alocados de inconsistência, alguns linearmente com alocação única e a maioria no RAID 10.

Você pode reequilibrar uma política de alocação única se quiser ganhar espaço sem alterar muita coisa. Você também pode adicionar mais discos ou aumentar o tamanho dos discos. Ou você poderia, como você fez neste caso, apenas excluir um monte de arquivos para que seu pool possa realmente balancear para o RAID 10 (como seria menos de 50% consumido no geral). Certifique-se de reequilibrar após a exclusão de arquivos, ou você ainda terá essa política de alocação simplista.

Especificamente, reforce o RAID 10 ao rebalancear após excluir esses arquivos para garantir que você se livre desses blocos alocados, assim:

btrfs fi balance start -dconvert=raid10 -mconvert=raid10 /home