web-dev-qa-db-ja.com

btrfs、ディスクスペースが残っていません

Btrfsボリュームのディスク容量に問題があります。 dfは、十分なディスク容量があることを示しています。しかし、10GBのテストファイルシステムをコピーしようとすると、このデバイスにディスク容量がないと言います。

df -h | grep /mnt/ssd：

/dev/sda 448G 135G 313G 31% /mnt/ssd

こっちも一緒：

btrfs filesystem df /mnt/ssd：

Data, RAID1: total=446.12GiB, used=133.29GiB
System, RAID1: total=8.00MiB, used=80.00KiB
Metadata, RAID1: total=1.00GiB, used=609.05MiB
GlobalReserve, single: total=405.53MiB, used=0.00B

これの出力を読み取る方法がわかりません：

Sudo btrfs filesystem show：

Label: none  uuid: aba64e21-69d1-46c1-b3f2-dfda832b67fd
    Total devices 2 FS bytes used 133.88GiB
    devid    1 size 447.13GiB used 447.13GiB path /dev/sda
    devid    2 size 447.13GiB used 447.13GiB path /dev/sdb

では、133.88GiBまたは447.13GiBが使用されていますか？とても紛らわしい。

linuxssdbtrfs
3
Kristopher

ここで何が起こっているのかを理解するには、BTRFSが2段階のアロケーターを使用していることを最初に理解する必要があります。最初の段階では、データ（ファイル内のデータにのみ使用）、メタデータ（ファイル名、ディレクトリなど）のいずれか1つのタイプの割り当てに使用される大きなスペースのチャンク（実際には、ほとんどのドキュメントでは「チャンク」と呼ばれます）を割り当てます。構造、アクセス時間、所有権、アクセス許可など）、またはシステム（チャンク割り当てに関するデータを格納するためにのみ使用されます）。チャンクが割り当てられると、そのチャンク内のスペースは、すべてのデータをチャンクから移動することによってのみ解放できます。

では、これはファイルシステムに関して正確に何を意味するのでしょうか？

さて、btrfs filesystem dfからの出力は次のようになります。

Data, RAID1: total=446.12GiB, used=133.29GiB
System, RAID1: total=8.00MiB, used=80.00KiB
Metadata, RAID1: total=1.00GiB, used=609.05MiB
GlobalReserve, single: total=405.53MiB, used=0.00B

total値は、そのタイプのチャンクに割り当てられているスペースの量を示し、used値は、それらのチャンク内で使用されているスペースの量を示します。あなたの場合、データチャンクに割り当てられた446.32GBのスペース（通常のdfおよびbtrfs filesystem show出力に基づくディスク全体）がありますが、実際に使用されているのはそのスペースの133.29GBのみです。これと説明されている症状を考えると、BTRFSはメタデータチャンクを割り当てようとしていますが、そのためのスペースがありません（すべての空きスペースがすでに割り当てられたチャンク内にあるため）。そのため、代わりにエラーが発生します。

これから回復するには、バランスを実行する必要があります。天びんは文字通り、選択したチャンクからのすべてのデータ（またはオプションを渡さない場合はすべて）をアロケーターに送り返します。これは、部分的に完全なチャンクにパックして戻すため、空またはほとんど空のチャンクを解放するという正味の効果があります。

私はから始めます：

btrfs balance start -dusage=0 /mnt/ssd

これにより、実際のデータが含まれていないすべてのデータチャンクが削除されます。これは、今のところ再び機能させるのに十分な場合がありますが、将来的には同じ問題に対して脆弱なままになります。

物事を完全に圧縮するために、-dusageオプションの値を増やして上記のコマンドを繰り返します。私は通常それを約50まで毎回5ずつ上げます（過去50、あなたは通常時間を無駄にしています）。使用量フィルター（データチャンクのみを処理するために上記で指定）は、最大でそのパーセンテージのみがいっぱいであるチャンクを選択するようにバランスを指示します。したがって、ビットごとに段階的にステップアップすることで、他の問題に遭遇することなく、より簡単に圧縮できます。

次のようなものを定期的に実行することで、将来このような問題を回避するのに役立ちます（私は通常、システムで毎日実行しています）。

btrfs balance start -dusage=25 -dlimit=10 -musage=25 -mlimit=10 /mnt/ssd

これにより、いっぱいになった4分の1未満の最初の10個のデータチャンクとメタデータチャンクのバランスがとれ、ほとんどの場合、数秒で完了します。

5
Austin Hemmelgarn

HDD上のBtrfsファイルシステムでこのタイプの問題が発生したことはありませんが、SSDでも同じ問題が発生しました。 SSDは、どのブロックが実際に空いているかを認識していません。トリミングする必要があります。

しかし、問題が発生すると、fstrim -v /mnt/ssdは、トリミングされているスペースがほとんどないことを示します。私の解決策：

btrfs balance start /mnt/ssd
  #  you can monitor its progress by 'btrfs balance status /mnt/ssd'
fstrim -v /mnt/ssd

2番目のコマンドは、今回は多くのスペースをトリミングする必要があります。この後、私の空き領域は本当に利用可能になります。

ただし、注意：私は単一のSSDでBtrfsを使用していますが、私の場合はno RAIDがあり、それが違いを生むかどうかはわかりません（フィードバックを頼りにしています）。

紛らわしい部分について：ファイルシステムとしてのBtrfsは、割り当てられた1つまたは複数のデバイス内でそれ自体を拡大または縮小できます。今のところ、ファイルシステムは肥大化しています。すべてのデバイスで447.13GiB全体を使用します。 fstrimに関する限り、このスペース全体が「使用中」だと思います。ただし、ファイルシステム内では133.29GiBが実際のデータによって使用されます。ファイルシステムのバランスをとることでファイルシステムを縮小する必要があり、そうして初めてfstrimがその仕事をすることができます。

ファイルシステムは時間とともに再び膨張します。そのため、特にapt-get upgradeの前に、上記のメンテナンスを定期的に実行することを学びました。

1
Kamil Maciorowski