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

iノードスペースも十分にあるように見えます。の出力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 kernalバージョン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

合計で最大1GBの大きなファイルを手動で削除した後、マシンを再起動して再試行し、sudoを使用していることを確認して、コマンドを実行しました。その後、適切な手段のためにマシンをもう一度再起動しましたが、問題は解決したようです

BTRFSの世界へようこそ。魅力的な機能がいくつかありますが、腹立たしい問題もあります。

まず、セットアップに関するいくつかの情報があります。BTRFSの「raid 10」ボリュームに4つのドライブがあるようです（したがって、すべてのデータは異なるディスクに2回保存されます）。このBTRFSボリュームは、異なるマウントポイントのサブボリュームに分割されます。サブボリュームはディスクスペースのプールを共有しますが、個別のiノード番号を持ち、異なる場所にマウントできます。

BTRFSはスペースを「チャンク」で割り当て、チャンクはデータまたはメタデータの特定のクラスに割り当てられます。発生する可能性のある（そしてあなたのケースで発生したように見える）ことは、すべての空き領域がデータチャンクに割り当てられ、メタデータ用のスペースがなくなることです。

また、使用されているメタデータスペースの割合のインジケータが100％に達する前に、BTRFがメタデータスペースを「使い果たし」ているようです（理由は完全には理解していません）。

これはあなたのケースで起こったことのように見えます。たくさんの空きデータスペースがありますが、チャンクに割り当てられていない空きスペースがなく、既存のメタデータチャンクに十分な空きスペースがありません。

修正は、「リバランス」を実行することです。これにより、データが移動され、一部のチャンクが「グローバル」空きプールに戻され、メタデータチャンクとして再割り当てされます。

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

後の数値-dusageは、リバランスがどれだけ積極的であるか、つまり、ブロックを書き換えるのにどれだけ空にする必要があるかを設定します。天びんが0ブロックを書き直したと言った場合、より高い値で再試行してください-dusage。

バランスが崩れた場合は、ファイルを削除して再起動および/または空き領域を増やしてみます。

RAIDセットアップでbtrfsを実行しているので、バランス操作を実行してみてください。

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の問題ではありません。これは、大量の単一割り当てブロックによって証明されるように、「単一」割り当てポリシーから「RAID 10」割り当てポリシーへの不完全なリバランスの結果のように見えます。おそらくシングルとして開始され、その後変換が中断されました。このような一貫性のない割り当てを持つプールには、割り当ての問題があります。

プールの61％が消費されていると考えてください。割り当てポリシーはRAID10であるため、すべてがレプリケート2であるため、フルに達する前に最大50％のプール消費が発生するはずです。これが、シングルからRAID 10への変換が失敗した理由です。推測しかできませんが、おそらくリバランスの最中に割り当てられました。お使いのディスクでRAID 10に再バランスするためのスペースがデバイスに残っていません。61％に達した唯一の理由は、ディスクの割り当てに一貫性がなく、一部は単一の割り当てで線形に、そしてほとんどがRAID 10にあるためです。

何も変更せずにスペースを確保したい場合は、単一の割り当てポリシーにリバランスできます。ディスクを追加したり、ディスクのサイズを大きくしたりすることもできます。または、この場合に行ったように、プールを実際にRAID 10にバランスできるようにファイルの束を削除することもできます（全体で50％未満しか消費されないため）。ファイルを削除した後は必ずバランスを取り直してください。そうしないと、このジャンキーな割り当てポリシーが残っています。

具体的には、これらのファイルを削除した後にリバランスするときにRAID 10を実施して、次のように単一の割り当てられたブロックを確実に削除してください。

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