web-dev-qa-db-ja.com

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 protected]): 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
_

Inodeスペースもたくさんあるようです。 _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_

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

hard-drivefilesystemsdisk-space-utilization
17
Austin

BTRFSの世界へようこそ。いくつかの食欲をそそる機能だけでなく、いくつかの腹立たしい問題もあります。

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

BTRFSは「チャンク」でスペースを割り当てます。チャンクは、データまたはメタデータの特定のクラスに割り当てられます。起こり得ること（そしてあなたの場合に起こったように見えること）は、すべての空き領域がデータチャンクに割り当てられ、メタデータの余地を残さないことです

また、メタデータスペースの使用率が100％に達する前に、BTRFがメタデータスペースを「使い果たす」ことも（理由は完全にはわかりません）と思われます。

これはあなたの場合に起こったようです、多くの空きデータ領域がありますが、チャンクに割り当てられていない空き領域はなく、既存のメタデータチャンクには十分な空き領域がありません。

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

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

-dusageの後の数値は、リバランスの程度を設定します。つまり、ブロックを書き換えるまでに空にする必要がある間隔です。天びんが0ブロックを書き換えたと表示する場合は、-dusageの値を大きくして再試行してください。

バランスがうまくいかない場合は、ファイルを削除して、再起動したりスペースを解放したりします。

19
Peter Green

RAID設定でbtrfsを実行しているので、バランス操作を実行してみてください。

btrfs balance start /var/opt/gitlab

これにより、十分なスペースがないというエラーが発生する場合は、次の構文で再試行してください。

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

スペースに関するエラーが発生しているbtrfsファイルシステムごとに、この操作を繰り返します。メタデータがミラーリングされたディスク全体に分散されていないことが原因でスペースの問題が発生している場合、これによりスペースが解放される可能性があります。

4
virtex

私のシステムでは、cron.monthlyに次のジョブを追加しました。

clear_cache再マウントは、btrfsがフリーマップで発生していたいくつかの破損問題が原因です。 （最終的に彼らが問題を見つけたと思いますが、問題は非常に煩わしいので、月に1度マップを再構築するために支払うつもりです。）

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

スペースが足りないためにリバランスできないポイントに達した場合は、リバランスの期間中、ボリュームに何らかの種類の別のブロックデバイス（または別のディスク上のループバックデバイス）を一時的に追加することをお勧めします。それを除く。

2
rrauenza

これはbtrfsの問題ではなく、このシステムに対して行われたものです。これは、単一の割り当てブロックが大量にあることからもわかるように、「単一」の割り当てポリシーから「raid 10」の割り当てポリシーへの不完全なリバランスの結果のようです。おそらくシングルとして開始された後、変換が中断されました。このような一貫性のない割り当てを持つプールには、割り当ての問題があります。

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

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

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

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

1
Spooler