Error "No queda espacio en el dispositivo" a pesar de tener mucho espacio, en btrfs

Casi en todas partes tengo fallas en los registros quejándome No space left on device

Registros de 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)

Dovecot registros de correo electrónico:

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

Salida 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 también hay mucho espacio de inodo. Salida 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

Salida 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

Salida 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

¿Cuál podría ser la causa de esto? Estoy usando una versión básica de Linux AMI ec2 kernel 4.4.5-15.26.amzn1.x86_64

Actualizar

Ejecutar el comando sugerido a continuación btrfs fi balance start -dusage=5 /mnt/durableme devolvió un error de lo siguiente:

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

Después de eliminar manualmente un montón de archivos más grandes que suman un total de ~ 1 GB, reinicié la máquina e intenté nuevamente, asegurándome de que estaba usando sudo, y ejecuté el comando. Luego reinicié mi máquina una vez más por si acaso y parece haber resuelto el problema

Bienvenido al mundo de BTRFS. Tiene algunas características tentadoras pero también algunos problemas exasperantes.

En primer lugar, algo de información sobre su configuración, parece que tiene cuatro unidades en un volumen BTRFS "raid 10" (por lo que todos los datos se almacenan dos veces en diferentes discos). Este volumen BTRFS se divide en subvolúmenes en diferentes puntos de montaje. Los subvolúmenes comparten un grupo de espacio en disco pero tienen números de inodo separados y se pueden montar en diferentes lugares.

BTRFS asigna espacio en "fragmentos", un fragmento se asigna a una clase específica de datos o metadatos. Lo que puede suceder (y parece que sucedió en su caso) es que todo el espacio libre se asigna a fragmentos de datos sin dejar espacio para metadatos

También parece que (por razones que no entiendo completamente) que los BTRF "se quedan sin espacio de metadatos" antes de que el indicador de la proporción de espacio de metadatos utilizado alcance el 100%.

Esto parece ser lo que sucedió en su caso, hay mucho espacio libre de datos pero no hay espacio libre que no se haya asignado a fragmentos y espacio libre insuficiente en los fragmentos de metadatos existentes.

La solución es ejecutar un "reequilibrio". Esto moverá los datos para que algunos fragmentos puedan devolverse al grupo libre "global" donde pueden reasignarse como fragmentos de metadatos.

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

El número después -dusageestablece cuán agresivo es el reequilibrio, es decir, qué tan cerca del vacío deben estar los bloques para reescribirse. Si la balanza dice que reescribió 0 bloques, intente nuevamente con un valor más alto de -dusage.

Si el equilibrio falla, intentaría reiniciar y / o liberar espacio eliminando archivos.

Como está ejecutando btrfs con una configuración RAID, intente ejecutar una operación de equilibrio.

btrfs balance start /var/opt/gitlab

Si esto da un error acerca de no tener suficiente espacio, intente nuevamente con esta sintaxis:

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

Repita esta operación para cada sistema de archivos btrfs donde vea errores sobre el espacio. Si su problema de espacio se debe a que los metadatos no se distribuyen entre los discos duplicados, esto podría liberarle algo de espacio.

En mi sistema, agregué el siguiente trabajo en cron.monthly.

El clear_cachemontaje se debe a algunos problemas de corrupción que btrfs tenía con los mapas gratuitos. (Creo que finalmente encontraron el problema, pero el problema es tan molesto que estoy dispuesto a pagar para reconstruir los mapas una vez al mes).

Aumento las usageopciones para liberar espacio gradualmente para balances cada vez más grandes.

#!/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

Si llega al punto en el que no puede reequilibrar porque no tiene espacio suficiente, la recomendación es agregar temporalmente otro dispositivo de bloqueo (o dispositivo de bucle invertido en otro disco) de algún tipo a su volumen durante la duración del reequilibrio, y luego eliminarlo

Esto no es tanto un problema con btrfs, sino algo que se le ha hecho a este sistema. Esto parece el resultado de un reequilibrio incompleto de una política de asignación 'única' a una política de asignación 'incursión 10', como lo demuestra la gran cantidad de bloques asignados individuales. Probablemente comenzó como único y luego se interrumpió una conversión. Un grupo con una asignación tan inconsistente seguramente tendrá ... bueno, problemas de asignación.

Considera que tienes el 61% de tu piscina consumida. Su política de asignación es RAID10, por lo que debería dar como resultado un consumo máximo del 50% del grupo antes de que se llene por completo, ya que todo es replicado 2. Es por eso que su conversión de un solo a RAID 10 ha fallado (y continúa). Solo puedo adivinar, pero probablemente fue asignado en medio de un reequilibrio. No queda espacio en su dispositivo para reequilibrar a un RAID 10 con los discos que tiene. La única razón por la que llegó al 61% es porque sus discos tienen inconsistencia asignada, algunos linealmente con asignación única, y la mayoría en RAID 10.

Podría reequilibrar a una política de asignación única si desea ganar espacio sin cambiar mucho de nada. También puede agregar más discos o aumentar el tamaño de los discos. O bien, como lo ha hecho en este caso, simplemente puede eliminar un montón de archivos para que su grupo pueda equilibrarse a RAID 10 (ya que sería menos del 50% consumido en general). Asegúrese de reequilibrar después de eliminar archivos, o aún tendrá esta política de asignación irregular.

Específicamente, aplique RAID 10 al reequilibrar después de eliminar esos archivos para asegurarse de deshacerse de esos bloques asignados individuales, de esta manera:

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