Помилка "Не залишається місця на пристрої", незважаючи на те, що на btrfs достатньо місця

Майже скрізь я отримую збої в журналах, на які скаржиться No space left on device

Журнали 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:

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

Вихід 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

Схоже, також є достатньо місця для введення. Вихід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

Вихід 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

Вихід 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

Що може бути причиною цього? Я використовую базовий Linux ядро ​​AMI ec2 версії 4.4.5-15.26.amzn1.x86_64

Оновлення

Виконання запропонованої нижче команди призвело btrfs fi balance start -dusage=5 /mnt/durableдо помилки з наступного:

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

Після видалення вручну купи більших файлів на обсяг ~ 1 Гб я перезавантажив машину і спробував ще раз, переконавшись, що я використовую sudo, і команда виконана. Потім я перезавантажив свою машину ще раз для гарної міри і, здається, вирішив проблему

Ласкаво просимо у світ BTRFS. Він має деякі заплутані риси, але також певні проблеми.

По-перше, якась інформація про налаштування, схоже, у вас є чотири диски в BTRFS "raid 10" томі (тому всі дані зберігаються двічі на різних дисках). Цей об'єм BTRFS потім вирізається на підтомники в різних точках кріплення. Підтомники розділяють пул дискового простору, але мають окремі номери номерів і можуть бути встановлені в різних місцях.

BTRFS виділяє простір у "фрагментах", фрагмент виділяється конкретному класу або даних, або метаданих. Що може статися (і схоже, що трапилося у вашому випадку) - це те, що весь вільний простір виділяється на груди даних, не залишаючи місця для метаданих

Також здається, що (з причин я не повністю розумію), що BTRF "закінчується" простором метаданих до того, як показник частки використовуваного простору метаданих досягне 100%.

Це, мабуть, трапилось у вашому випадку, є багато вільного простору даних, але немає вільного простору, який не був розподілений на шматки, і недостатньо вільного місця в існуючих фрагментах метаданих.

Виправлення полягає у виконанні "перебалансу". Це перемістить дані, щоб деякі фрагменти можна було повернути у "глобальний" безкоштовний пул, де їх можна перерозподілити як фрагменти метаданих

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

Число після -dusageзадає, наскільки агресивним є баланс, тобто наближення до порожніх блоків, щоб їх переписати. Якщо баланс каже, що він переписав 0 блоків, спробуйте ще раз з більшим значенням -dusage.

Якщо баланс не вдається, я б спробував перезавантажити та / або звільнити деякий простір, видаливши файли.

Оскільки ви запускаєте btrfs з установкою RAID, спробуйте виконати операцію балансу.

btrfs balance start /var/opt/gitlab

Якщо це дає помилку щодо недостатнього місця, спробуйте ще раз із цим синтаксисом:

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

Повторіть цю операцію для кожної файлової системи btrfs, де ви бачите помилки щодо місця. Якщо проблема з простором пов’язана з тим, що метадані не поширюються на дзеркальні диски, це може звільнити для вас місце.

У своїй системі я додав наступну роботу в cron.monthly.

clear_cacheПеремонтування пов'язані з деякими проблемами корупції Btrfs була , має з безкоштовними картами. (Я думаю, що нарешті вони знайшли проблему, але питання настільки дратує, я готовий платити за відновлення карт раз на місяць.)

Я збільшую usageваріанти, щоб поступово звільняти місце для більших і великих залишків.

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

Якщо ви дістанетесь до точки, коли ви не можете перебалансувати, оскільки у вас недостатньо місця, рекомендується тимчасово додати до свого обсягу ще один блок-пристрій (або пристрій зворотного зв'язку на іншому диску), а потім видали це.

Це не стільки проблема з btrfs, скільки це було зроблено для цієї системи. Це виглядає як результат неповного перебалансу від "єдиної" політики розподілу до політики розподілу "рейд 10", про що свідчить велика кількість одиничних виділених блоків. Це, ймовірно, почалося як одиничне, а потім конверсія була перервана. Пул з таким непослідовним розподілом повинен мати ... ну, проблеми з розподілом.

Подумайте, що у вас споживається 61% вашого басейну. Ваша політика розподілу - RAID10, і це повинно призвести до максимуму 50% споживання пулу, перш ніж досягти повного, оскільки все повторюється 2. Ось чому ваше перетворення з одного в RAID 10 не вдалося (і продовжує). Я можу лише здогадуватися, але це, ймовірно, було виділено посеред ребалансу. На вашому пристрої не залишилося місця для відновлення балансу на RAID 10 з вашими дисками. Єдина причина, на яку ви набрали 61%, - це те, що ваші диски розподілені непослідовно, деякі лінійно з одним розподілом, а більшість у RAID 10.

Ви можете переосмислити єдину політику розподілу, якщо хочете отримати місце, не змінюючи нічого. Ви також можете додати більше дисків або збільшити розмір дисків. АБО ви могли, як і в цьому випадку, просто видалити купу файлів, щоб ваш пул міг фактично врівноважуватися до RAID 10 (як це було б менше 50% споживаних). Переконайтеся, що ви повторно врівноважуєтесь після видалення файлів, інакше ви все одно будете мати цю прискіпливу політику розподілу.

Зокрема, застосуйте RAID 10 під час відновлення балансу після видалення цих файлів, щоб переконатися, що ви позбудетесь від цих окремих виділених блоків, наприклад:

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