Błąd „Brak miejsca na urządzeniu” pomimo dużej ilości miejsca na btrfs

Niemal wszędzie dostaję błędy w logach narzekających No space left on device

Dzienniki 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)

Dzienniki e-mail 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

Wyjście z 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

Wygląda na to, że jest też dużo miejsca na i-węzły. Wyjście zdf -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

Wyjście z 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

Wyjście z 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

Co może być przyczyną tego? Używam bazowego linux AMI ec2 kernal w wersji 4.4.5-15.26.amzn1.x86_64

Aktualizacja

Uruchomienie polecenia sugerowanego poniżej btrfs fi balance start -dusage=5 /mnt/durablezwróciło mi następujący błąd:

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

Po ręcznym usunięciu kilku większych plików o łącznej wielkości ~ 1 GB ponownie uruchomiłem komputer i spróbowałem ponownie, upewniając się, że korzystam z sudo i że polecenie zostało wykonane. Następnie ponownie uruchomiłem maszynę, aby rozwiązać problem. Wygląda na to, że problem został rozwiązany

Witamy w świecie BTRFS. Ma pewne kuszące cechy, ale także irytujące problemy.

Po pierwsze, kilka informacji na temat konfiguracji, wygląda na to, że masz cztery dyski w woluminie „raid 10” BTRFS (więc wszystkie dane są przechowywane dwa razy na różnych dyskach). Ten wolumin BTRFS jest następnie rzeźbiony w podwolumny w różnych punktach montażu. Podwoluminy dzielą pulę miejsca na dysku, ale mają osobne numery i-węzłów i mogą być montowane w różnych miejscach.

BTRFS przydziela miejsce w „porcjach”, porcja jest przydzielana do określonej klasy danych lub metadanych. To, co może się zdarzyć (i wygląda na to, że stało się w twoim przypadku), polega na tym, że całe wolne miejsce jest przydzielane do fragmentów danych, nie pozostawiając miejsca na metadane

Wydaje się również, że (z powodów, których nie do końca rozumiem), że BTRF „wyczerpuje się” przestrzeń metadanych, zanim wskaźnik proporcji użytej przestrzeni metadanych osiągnie 100%.

Wygląda na to, że tak się stało w twoim przypadku, jest dużo wolnego miejsca na dane, ale nie ma wolnego miejsca, które nie zostało przydzielone na porcje i niewystarczająca ilość wolnego miejsca w istniejących porcjach metadanych.

Rozwiązaniem jest uruchomienie „ponownego równoważenia”. Spowoduje to przeniesienie danych, aby niektóre fragmenty mogły zostać zwrócone do „globalnej” wolnej puli, gdzie można je ponownie przydzielić jako fragmenty metadanych

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

Liczba po -dusageustawia, jak agresywna jest równowaga, czyli jak blisko pustych bloków musi być napisane. Jeśli waga mówi, że przepisała 0 bloków, spróbuj ponownie z wyższą wartością -dusage.

Jeśli saldo się nie powiedzie, spróbuję ponownie uruchomić komputer i / lub zwolnić trochę miejsca, usuwając pliki.

Ponieważ używasz btrfs z konfiguracją RAID, spróbuj uruchomić operację równoważenia.

btrfs balance start /var/opt/gitlab

Jeśli pojawi się błąd związany z brakiem wystarczającej ilości miejsca, spróbuj ponownie, stosując następującą składnię:

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

Powtórz tę operację dla każdego systemu plików btrfs, w którym występują błędy dotyczące miejsca. Jeśli problem z miejscem jest spowodowany brakiem metadanych na dyskach lustrzanych, może to zwolnić miejsce dla Ciebie.

W moim systemie dodałem następujące zadanie w cron.monthly.

clear_cacheRemount jest ze względu na pewne problemy korupcji Btrfs został mających z wolnymi mapach. (Myślę, że w końcu znaleźli problem, ale problem jest tak irytujący, że jestem gotów zapłacić za odbudowę map raz w miesiącu).

Zwiększam usagemożliwości stopniowego zwalniania miejsca dla coraz większych sald.

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

Jeśli dojdziesz do punktu, w którym nie możesz ponownie zbalansować, ponieważ nie masz wystarczającej ilości miejsca, zaleca się tymczasowe dodanie innego rodzaju urządzenia blokowego (lub urządzenia sprzężenia zwrotnego na innym dysku) do swojego wolumenu na czas ponownego równoważenia, a następnie usunąć to.

Nie jest to tak duży problem z btrfs, jak to, co zostało zrobione z tym systemem. Wygląda to na wynik niepełnego ponownego zrównoważenia polityki „pojedynczej” alokacji na politykę alokacji „nalotu 10”, o czym świadczy duża liczba pojedynczych alokowanych bloków. Prawdopodobnie zaczął się jako singiel, a następnie konwersja została przerwana. Pula z takim niespójnym przydziałem będzie musiała ... no cóż, problemy z przydziałem.

Weź pod uwagę, że wykorzystałeś 61% swojej puli. Twoją zasadą alokacji jest RAID10, więc powinno to spowodować maksymalnie 50% zużycie puli przed pełnym wykorzystaniem, ponieważ wszystko jest replikowane 2. Z tego powodu konwersja z pojedynczego na RAID 10 nie powiodła się (i nadal występuje). Mogę tylko zgadywać, ale prawdopodobnie zostało to przydzielone w trakcie przywracania równowagi. W urządzeniu nie ma już miejsca na ponowne zrównoważenie macierzy RAID 10 za pomocą posiadanych dysków. Jedynym powodem, dla którego osiągnąłeś 61%, jest to, że dyski są alokowane niespójnie, niektóre liniowo z pojedynczą alokacją, a większość w RAID 10.

Możesz przywrócić równowagę do pojedynczej zasady alokacji, jeśli chcesz zyskać miejsce bez zmiany dużej części czegokolwiek. Możesz także dodać więcej dysków lub zwiększyć ich rozmiar. LUB możesz, tak jak w tym przypadku, po prostu usunąć kilka plików, aby twoja pula mogła faktycznie zrównoważyć RAID 10 (ponieważ byłoby to mniej niż 50% zużywane ogółem). Upewnij się, że przywrócisz równowagę po usunięciu plików, w przeciwnym razie nadal będziesz mieć tę dziwną zasadę alokacji.

W szczególności wymuszaj RAID 10 podczas ponownego równoważenia po usunięciu tych plików, aby upewnić się, że pozbyłeś się tych pojedynczych przydzielonych bloków:

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