Ubuntu认为Btrfs磁盘已满，但事实并非如此
$ cat /etc/fstab # 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-errors，无法安装程序，我的mysql服务器无法启动，因为它。
而且我知道不要依赖于df我只是为了完整而包含它。
我认为Ubuntu使用已知在内部错误报告Btrfs的df并因此失败。 对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和文件系统。 驱动器分为子卷，每个子卷都动态resize并进行复制：
|--files--| |--files--| |files| | | |----@raid1----|------@raid1-------|-----@home-----|metadata| | |------------------------drive partition-------------------------------|
该图显示了分区分为两个子卷和元数据。 其中一个子卷是重复的（RAID1），因此设备上的每个文件都有两个副本。 现在我们不仅有文件系统层有多少空间可用的概念，而且还有它下面的块层（驱动器分区）有多少空闲空间。 空间也被元数据占用。
在考虑Btrfs中的可用空间时，我们必须澄清我们正在讨论的空闲空间 – 块层或文件层？ 在块层，数据以1GB块的forms分配，因此值非常粗糙，并且可能与用户实际使用的空间量无关。 在文件层，无法报告可用空间量，因为空间量取决于它的使用方式。 在上面的示例中，存储在复制子卷@ raid1上的文件占用的空间是@home子卷中存储的同一文件的两倍。 快照仅存储随后修改的文件的副本。 用户看到的文件与存储在驱动器上的文件之间不再存在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子卷，则使用的原始存储量是此处可以看到的值的两倍。
第一列显示了要存储的项目类型（数据，系统，元数据）。 第二列显示是存储每个项目的单个副本（单个），还是存储每个项目的两个副本（DUP）。 两个副本用于敏感数据，因此如果一个副本已损坏，则存在备份。 对于DUP行，必须将使用的值加倍以获得实际驱动器上使用的空间量（因为btrfs fs df报告存储的数据，而不是使用的驱动器空间）。 第三和第四列显示总空间和已用空间。 没有自由列，因为“可用空间”的数量取决于它的使用方式。
关于这个驱动器的突出之处在于，你已经为你使用过9.46GiB的普通文件分配了9.47GiB的空间 – 这就是为什么你没有在设备错误上留下空间的原因。 您为重复的元数据分配了13.88GiB的空间，其中您使用了1.13GiB。 由于此元数据是DUP重复，这意味着已在实际驱动器上分配了27.76GiB空间，其中您使用了2.26GiB。 因此，25.5GiB的驱动器未被使用，但同时无法存储的文件。这是“Btrfs巨大的元数据分配”问题。 要尝试更正此问题，请运行btrfs balance start -m / 。 -m参数告诉btrfs仅重新平衡元数据。
类似的问题是元数据空间不足。 如果输出显示元数据实际已满（ 使用值接近总数 ），则解决方案是尝试使用命令btrfs balance start -dusage=5 /释放几乎为空（<使用率<5％）的数据块。 然后可以重用这些空闲块来存储元数据。
有关详细信息，请参阅Btrfs常见问题解答：
-
我得到“设备上没有剩余空间”错误，但是df说我有很多空间
-
Btrfs声称我没有太空，但看起来我应该剩下很多 。
简短回答：Btrfs分区元数据显示为标准磁盘实用程序（如df）的“已使用”。
-
检查问题量。 例如： /
btrfs subvolume list / -
很可能快照正在填充卷。 删除不需要的快照。 保持一个从最后的日期，你确定系统工作正常。
btrfs subvolume delete其中path来自上一个命令子卷列表“snapshot”。
-
重新启动，你就完成了
问题的原因可能是您的发行版或包管理器每次更新系统时都会生成快照。
注意：如果磁盘已满，则balance命令会失败，因为没有可用的空间。
在我的情况下，即使删除文件和快照，磁盘使用率也不会下降。
btrfs balance（数据和元数据）没有错误“设备上没有剩余空间”
btrfs balance start -m / ERROR: error during balancing '/': No space left on device There may be more info in syslog - try dmesg | tail
RAID1显示两个磁盘上的完全使用，即使实际数据使用率低于三分之一。
# 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以查看重定位块）
之后resize：
btrfs filesystem resize 1:450g / btrfs filesystem resize 2:450g /
之后，btrfs balance（元数据）再次起作用：
btrfs balance -m /
然后btrfs数据平衡（重新定位使用率低于33％的数据块）：
btrfs balance -dusage=33 /
归功于@ignis和@bain。 只是在没有所有讲座的情况下直接点到点参考答案，并分享我实际做的事情，以使系统再次运行。
btrfs balance start -m /mountpoint
是解决这类问题的神奇路线。
我遇到了一些麻烦，我不想厌倦你，我不知道有必要从现场CD运行这个，但我最后做的事情是系统搞砸了没有启动后运行btrfsck on设备（解锁的加密映射器）实际上发现了错误，然后在没有任何选项的情况下将根btrfs文件系统挂载到/mnt ，而不是在我安装的系统上，其中/是唯一挂载的@subvolume。 所以我还有所有的快照和其他子卷。 我不知道这有什么不同。
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% /
所以我觉得现在一切都很好。