UbuntuはBtrfsディスクがいっぱいであると考えていますが、そうではありません
$ cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=a168d1ac-4e13-4643-976d-6e47ea1732b1 /boot ext2 defaults 0 1
/dev/mapper/sda4_crypt / btrfs defaults,autodefrag,compress=lzo,inode_cache,space_cache,subvol=@ 0 2
/dev/mapper/sda4_crypt /tmp btrfs defaults,autodefrag,compress=lzo,inode_cache,space_cache,subvol=@tmp 0 2
/dev/mapper/sda4_crypt /run btrfs defaults,autodefrag,compress=lzo,inode_cache,space_cache,subvol=@run 0 2
/dev/mapper/sda4_crypt /var/crash btrfs defaults,autodefrag,compress=lzo,inode_cache,space_cache,subvol=@var-crash 0 2
/dev/mapper/sda4_crypt /var/tmp btrfs defaults,autodefrag,compress=lzo,inode_cache,space_cache,subvol=@var-tmp 0 2
/dev/mapper/sda4_crypt /var/log btrfs defaults,autodefrag,compress=lzo,inode_cache,space_cache,subvol=@var-log 0 2
/dev/mapper/sda4_crypt /var/spool btrfs defaults,autodefrag,compress=lzo,inode_cache,space_cache,subvol=@var-spool 0 2
/dev/mapper/sda5_crypt /home btrfs defaults,autodefrag,compress=lzo,inode_cache,space_cache,subvol=@home 0 3
/dev/mapper/750er /media/750er ext4 defaults 0 4
/dev/mapper/cswap none swap defaults 0 5
➜ ~ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sda4_crypt 38G 12G 13M 100% /
none 4,0K 0 4,0K 0% /sys/fs/cgroup
udev 2,0G 4,0K 2,0G 1% /dev
tmpfs 396M 1,3M 394M 1% /run
none 5,0M 0 5,0M 0% /run/lock
none 2,0G 208K 2,0G 1% /run/shm
none 100M 36K 100M 1% /run/user
/dev/mapper/sda4_crypt 38G 12G 13M 100% /tmp
/dev/sda2 231M 44M 175M 21% /boot
/dev/mapper/sda4_crypt 38G 12G 13M 100% /var/crash
/dev/mapper/sda4_crypt 38G 12G 13M 100% /var/tmp
/dev/mapper/sda4_crypt 38G 12G 13M 100% /var/log
/dev/mapper/sda4_crypt 38G 12G 13M 100% /var/spool
/dev/mapper/sda5_crypt 3,7T 2,4T 1,2T 67% /home
/dev/mapper/750er 688G 276G 377G 43% /media/750er
/dev/mapper/2tb 1,8T 1,7T 141G 93% /media/2tb
➜ ~ Sudo btrfs fi df /
Data, single: total=9.47GiB, used=9.46GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=13.88GiB, used=1.13GiB
Metadata, single: total=8.00MiB, used=0.00
➜ ~
かなりの数のスナップショットがある40GBのパーティションです。しかし、圧縮されているため、9,46GB/40GBは正確だと思います。しかし、私のUbuntuはディスクスペースがないと言っているので失敗します。 aptエラーが発生し、プログラムをインストールできず、mysqlサーバーが起動に失敗しました。
そして、dfに依存しないことを知っています。完全を期すためにそれを含めただけです。
Ubuntuはdfを使用していると思いますが、これはBtrfsで内部的に誤って報告し、そのために失敗することが知られています。 APTがスペースをチェックするとき、それは理にかなっています。しかし、実際にはディスクへの書き込みに失敗します。
$ Sudo time dd if=/dev/zero of=large bs=2G count=1
dd: error writing ‘large’: No space left on device
0+1 records in
0+0 records out
11747328 bytes (12 MB) copied, 1,29706 s, 9,1 MB/s
Command exited with non-zero status 1
0.00user 1.40system 0:01.44elapsed 97%CPU (0avgtext+0avgdata 2098028maxresident)k
160inputs+23104outputs (0major+383008minor)pagefaults 0swaps
Btrfsは従来のファイルシステムとは異なります。ブロックデバイス上のファイル名をオフセットに変換するだけのレイヤーではなく、従来のファイルシステムとLVMおよびRAIDを組み合わせたレイヤーです。また、LVMと同様に、基盤となるデバイスにスペースを割り当てるという概念がありますが、実際にファイルに使用するわけではありません。
従来のファイルシステムは、ファイルと空き領域に分かれています。どのくらいのスペースが使用されているか、無料であるかを計算するのは簡単です：
|--------files--------| |
|------------------------drive partition-------------------------------|
Btrfsは、LVM、RAID、およびファイルシステムを組み合わせたものです。ドライブはサブボリュームに分割され、それぞれが動的にサイズ設定および複製されます。
|--files--| |--files--| |files| | |
|----@raid1----|------@raid1-------|-----@home-----|metadata| |
|------------------------drive partition-------------------------------|
この図は、パーティションが2つのサブボリュームとメタデータに分割されていることを示しています。サブボリュームの1つが複製されている（RAID1）ため、デバイス上のすべてのファイルのコピーが2つあります。これで、ファイルシステムレイヤーの空き容量だけでなく、その下のブロックレイヤー（ドライブパーティション）の空き容量も把握できました。スペースもメタデータによって占有されます。
Btrfsの空き領域を検討する場合、ブロック層とファイル層のどちらの空き領域を使用するかを明確にする必要がありますか？ブロック層では、データは1GBのチャンクで割り当てられるため、値は非常に粗く、ユーザーが実際に使用できるスペースの量とは関係がない場合があります。ファイル層では、空き容量は使用方法に依存するため、空き容量を報告することはできません。上記の例では、複製されたサブボリューム@ raid1に保存されたファイルは、@ homeサブボリュームに保存された同じファイルの2倍のスペースを占有します。スナップショットには、後で変更されたファイルのコピーのみが保存されます。ユーザーに表示されるファイルと、ドライブに保存されているファイルとの間に1対1のマッピングはなくなりました。
btrfs filesystem show /を使用してブロックレイヤーの空き容量を確認し、btrfs filesystem df /を使用してサブボリュームレイヤーの空き容量を確認できます。
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sda4_crypt 38G 12G 13M 100% /
このマウントされたサブボリュームの場合、dfは、合計サイズが38Gで、12Gが使用され、13Mが空きのドライブを報告します。使用可能なスペースの100％が使用されています。合計サイズ38Gは異なるサブボリュームとメタデータに分割されることに注意してください-これはこのサブボリューム専用ではありません。
# btrfs filesystem df /
Data, single: total=9.47GiB, used=9.46GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=13.88GiB, used=1.13GiB
Metadata, single: total=8.00MiB, used=0.00
各行は、異なるデータタイプとレプリケーションタイプの合計スペースと使用スペースを示しています。表示される値は、ドライブに未加工バイトではなく保存されたデータです。したがって、RAID-1またはRAID-10サブボリュームを使用している場合、使用される未加工ストレージの量は、ここで確認できる値の2倍です。
最初の列には、保存されているアイテムのタイプ（データ、システム、メタデータ）が表示されます。 2番目の列は、各アイテムの単一のコピーが保存されるか（単一）、各アイテムの2つのコピーが保存されるか（DUP）を示します。機密データには2つのコピーが使用されるため、1つのコピーが破損した場合のバックアップがあります。 DUP行の場合、実際のドライブで使用されている容量を取得するには、sed値を2倍にする必要があります（btrfs fs df使用されたドライブ容量ではなく、保存されたデータを報告するため） 。 3番目と4番目の列は、合計スペースと使用済みスペースを示しています。 free列はありません。「空き領域」の量は使用方法に依存するためです。
このドライブで際立っているのは、9.46GiBを使用している通常のファイルに9.47GiBのスペースが割り当てられていることです。これがデバイスに空きスペースがありませんエラーが発生する理由です。重複したメタデータに割り当てられた13.88GiBのスペースがあり、そのうち1.13GiBを使用しています。このメタデータは複製されたDUPであるため、実際のドライブには27.76GiBのスペースが割り当てられており、そのうち2.26GiBを使用しています。したがって、25.5GiBのドライブは使用されていませんが、同時にファイルを保存することはできません。これは "Btrfs huge metadata allocate" の問題です。これを試して修正するには、btrfs balance start -m /を実行します。 -mパラメーターは、メタデータのみを再調整するようにbtrfsに指示します。
同様の問題は、メタデータ領域が不足していることです。出力でメタデータが実際にいっぱいであることが示されていた場合（sedtotalに近い値）、解決策はほとんど空（<5％使用済み）を解放することです）コマンドbtrfs balance start -dusage=5 /を使用したデータブロック。これらの空きブロックは、メタデータを保存するために再利用できます。
詳細については、Btrfs FAQを参照してください。
簡単な答え：Btrfsパーティションメタデータは、dfなどの標準ディスクユーティリティで「使用済み」として表示されます。
問題のあるボリュームを確認してください。例えば： /
btrfs subvolume list /最も可能性の高いスナップショットがボリュームを埋めています。不要なスナップショットを削除します。システムが正常に機能していたと確信できる最後の日付から1つを保持します.
btrfs subvolume delete <path>パスは、「スナップショット」という前のコマンドサブボリュームリストからのものです。
再起動すると完了です
問題の理由は、システムを更新するたびにスナップショットを作成するディストリビューションまたはパッケージマネージャーである可能性があります。
注意：ディスクがいっぱいの場合、バランスを取るための空き領域がないため、balanceコマンドは失敗します。
私の場合、ファイルやスナップショットを削除しても、ディスク使用量は減りません。
エラー「デバイスにスペースが残っていません」でbtrfsのバランス（データとメタデータ）が機能しませんでした
btrfs balance start -m /
ERROR: error during balancing '/': No space left on device
There may be more info in syslog - try dmesg | tail
RAID1は、実際のデータ使用量がその3分の1を下回っていたにもかかわらず、両方のディスクで完全に使用されていました。
# btrfs fi sh
Label: none uuid: 61a20f1a-c133-11e6-964b-d3bac0c48bbd
Total devices 2 FS bytes used 153.94GiB
devid 1 size 455.76GiB used 455.76GiB path /dev/sda2
devid 2 size 455.76GiB used 455.76GiB path /dev/sdb2
# btrfs filesystem df /
Data, RAID1: total=452.73GiB, used=151.51GiB
System, RAID1: total=32.00MiB, used=80.00KiB
Metadata, RAID1: total=3.00GiB, used=2.42GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
解決策：空のチャンクを破棄、追加のスペースは不要：
btrfs balance start -dusage=0 /
btrfs balance start -musage=0 /
ソース： https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-balance#ENOSPC
代替手段：私の解決策はディスクを縮小することでした参照： https://unix.stackexchange.com/questions/239765/how-to -fix-btrfs-superblock-error-after-resize-shrink-btrfs-couldnt-get-super
btrfs filesystem resize 1:430g /
btrfs filesystem resize 2:430g /
（コマンドには時間がかかります。syslogでブロックの再配置を確認してください）
サイズ変更後：
btrfs filesystem resize 1:450g /
btrfs filesystem resize 2:450g /
その後、btrfs balance（metadata）が再び機能しました：
btrfs balance -m /
次に、データのbtrfsバランス（使用率が33％未満のデータチャンクを再配置）：
btrfs balance -dusage=33 /
クレジットは@ignisと@bainになります。すべての講義をせずに、ここでポイントリファレンスの答えを簡単にストレートにして、システムを再び動作させるために私が実際に行ったことを共有します。
btrfs balance start -m /mountpoint
このような問題を解決する魔法のラインです。
私はあなたと一緒に退屈したくないといういくつかのトラブルに遭遇し、ライブCDからこれを実行する必要があることはわかりませんが、システムが台無しになって混乱した後に私がやったことはbtrfsckを実行していましたデバイス（ロック解除された暗号マッパー）で実際にエラーが見つかったため、/mntのみがマウントされた/サブボリュームである私のインストール済みシステムではなく、@にオプションなしでルートbtrfsファイルシステムをマウントしました。そこで、すべてのスナップショットと他のサブボリュームもそこにありました。私はこれが違いをもたらすことを知りません。
btrfs balance start -m /mnt
メタデータを取得しました
Metadata, DUP: total=13.88GiB, used=1.13GiB
に
Metadata, DUP: total=1.38GiB, used=1.05GiB
そしてさわやかな：
$ Sudo df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sda4_crypt 38G 12G 26G 31% /
だから私はすべてが今は大丈夫だと思う。