Erro "Não resta espaço no dispositivo", apesar de ter bastante espaço, no btrfs

Em quase todos os lugares, estou recebendo falhas nos logs reclamando 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 email Dovecot:

Nov 29 20:28:32 aws-management dovecot: imap(email@www.sitename.com): 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 no inode. Saída dedf -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 uma versão básica do Linux AMI ec2 kernal 4.4.5-15.26.amzn1.x86_64

Atualizar

A execução do comando sugerido abaixo btrfs fi balance start -dusage=5 /mnt/durableretornou um erro do seguinte:

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 ~ 1 GB, reiniciei a máquina e tentei novamente, certificando-me de estar usando o sudo, e o comando executado. Reiniciei minha máquina novamente por uma boa medida e parece ter resolvido o problema

Bem-vindo ao mundo do BTRFS. Ele tem alguns recursos tentadores, mas também alguns problemas irritantes.

Primeiramente, com algumas informações sobre sua configuração, parece que você tem quatro unidades em um volume "BIDFS" raid 10 "(para que todos os dados sejam armazenados duas vezes em discos diferentes). Esse volume BTRFS é dividido em subvolumes em diferentes pontos de montagem. Os subvolumes compartilham um conjunto de espaço em disco, mas têm 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 para os blocos de dados, sem deixar espaço para metadados

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

Parece que foi o que aconteceu no seu caso, há muito espaço livre de dados, mas nenhum espaço livre que não foi alocado para os blocos e espaço livre insuficiente nos blocos de metadados existentes.

A correção é executar um "reequilíbrio". Isso moverá os dados para que alguns fragmentos possam ser retornados ao pool gratuito "global", onde podem ser realocados como fragmentos de metadados

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

O número depois -dusagedefine o quão agressivo é o reequilíbrio, ou seja, o quão perto do vazio os blocos precisam estar para serem reescritos. Se o saldo indicar que reescreveu 0 bloco, tente novamente com um valor maior de -dusage.

Se o saldo falhar, eu tentaria reiniciar e / ou liberar algum espaço removendo arquivos.

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 der um erro por 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 em que você está vendo erros sobre espaço. Se o seu problema de espaço se deve ao fato de os metadados não serem distribuídos pelos discos espelhados, isso pode liberar algum espaço para você.

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

A clear_cacheremontagem é devido a alguns problemas de corrupção que a btrfs estava tendo com os mapas gratuitos. (Acho que finalmente encontraram o problema, mas o problema é tão irritante que estou disposto a pagar para reconstruir os mapas uma vez por mês.)

Amplio as usageopções para liberar espaço gradualmente para balanças 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 poderá reequilibrar porque não possui espaço suficiente, a recomendação é adicionar temporariamente outro dispositivo de bloco (ou dispositivo de auto-retorno em outro disco) de algum tipo ao seu volume durante o reequilíbrio e, em seguida, remova.

Isso não é tanto um problema com o btrfs, mas é algo que foi feito nesse sistema. Isso parece 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 únicos. Provavelmente começou como único e, em seguida, uma conversão foi interrompida. Um pool com essa alocação inconsistente provavelmente terá ... bem, problemas de alocação.

Considere que você consome 61% da sua piscina. Sua política de alocação é RAID10, portanto, isso deve resultar em um consumo máximo de 50% do pool antes de atingir o total, pois tudo é replicado 2. É por isso que sua conversão de único para RAID 10 falhou (e continua). Só posso adivinhar, mas provavelmente foi alocado no meio de um reequilíbrio. Não há espaço no seu dispositivo para reequilibrar para um RAID 10 com os discos que você possui. O único motivo para você chegar a 61% é porque seus discos são alocados por inconsistência, alguns linearmente com alocação única e a maioria no RAID 10.

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

Especificamente, imponha o RAID 10 ao reequilibrar após excluir esses arquivos para garantir que você se livre desses blocos únicos alocados, como:

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