![尽管 btrfs 上有足够的空间,但仍出现“设备上没有剩余空间”错误](https://linux22.com/image/694391/%E5%B0%BD%E7%AE%A1%20btrfs%20%E4%B8%8A%E6%9C%89%E8%B6%B3%E5%A4%9F%E7%9A%84%E7%A9%BA%E9%97%B4%EF%BC%8C%E4%BD%86%E4%BB%8D%E5%87%BA%E7%8E%B0%E2%80%9C%E8%AE%BE%E5%A4%87%E4%B8%8A%E6%B2%A1%E6%9C%89%E5%89%A9%E4%BD%99%E7%A9%BA%E9%97%B4%E2%80%9D%E9%94%99%E8%AF%AF.png)
几乎在所有地方我都会收到日志抱怨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,并且命令执行成功。然后我再次重启了机器,似乎问题已经解决了
答案1
欢迎来到 BTRFS 的世界。它有一些诱人的功能,但也有一些令人恼火的问题。
首先,关于您的设置,看起来您在 BTRFS“raid 10”卷中有四个驱动器(因此所有数据都存储在不同的磁盘上两次)。然后,此 BTRFS 卷被划分为不同挂载点上的子卷。子卷共享一个磁盘空间池,但具有单独的 inode 编号,并且可以挂载在不同的位置。
BTRFS 以“块”的形式分配空间,每个块分配给特定类型的数据或元数据。可能发生的情况(在您的案例中似乎已经发生)是所有可用空间都分配给数据块,没有空间分配给元数据
而且似乎(出于我不完全理解的原因)在元数据空间使用比例指标达到 100% 之前,BTRF 就“耗尽”了元数据空间。
这似乎就是您遇到的情况,有大量可用数据空间,但没有未分配给块的可用空间,并且现有元数据块中的可用空间不足。
修复方法是运行“重新平衡”。这将移动数据,以便一些块可以返回到“全局”空闲池,在那里它们可以重新分配为元数据块
btrfs fi balance start -dusage=5 /mnt/durable
后面的数字-dusage
设置重新平衡的积极程度,即块必须接近空块才能重写。如果平衡表明它重写了 0 个块,请使用更高的值重试-dusage
。
如果平衡失败,那么我会尝试重新启动和/或通过删除文件来释放一些空间。
答案2
由于您正在使用 RAID 设置运行 btrfs,请尝试运行平衡操作。
btrfs balance start /var/opt/gitlab
如果出现空间不足的错误,请使用以下语法重试:
btrfs balance start -musage=0 -dusage=0 -susage=0 /var/opt/gitlab
对每个出现空间错误的 btrfs 文件系统重复此操作。如果空间问题是由于元数据未分布在镜像磁盘上造成的,则此操作可能会为您释放一些空间。
答案3
在我的系统上,我在 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
如果由于空间不足而无法重新平衡,建议在重新平衡期间向卷临时添加另一个块设备(或另一个磁盘上的环回设备),然后将其删除。
答案4
这并不是 btrfs 的问题,而是这个系统所做的事情。这看起来像是从“单一”分配策略到“raid 10”分配策略的不完整重新平衡的结果,大量单一分配的块就是明证。它可能一开始是单一的,然后转换被中断。具有如此不一致分配的池必然会出现...嗯,分配问题。
假设您已消耗了 61% 的池。您的分配策略是 RAID10,因此在达到满池之前,池消耗最多为 50%,因为所有内容都是复制 2。这就是您从单一到 RAID 10 的转换失败(并且继续失败)的原因。我只能猜测,但它可能是在重新平衡的过程中分配的。您的设备上没有剩余空间可以使用您拥有的磁盘重新平衡到 RAID 10。您达到 61% 的唯一原因是您的磁盘分配不一致,一些是线性分配的单一分配,大多数是 RAID 10。
如果您想在不做太多更改的情况下获得空间,您可以重新平衡到单一分配策略。您还可以添加更多磁盘或增加磁盘大小。或者,您可以像本例中所做的那样,删除一堆文件,这样您的池就可以真正平衡到 RAID 10(因为总体消耗量将低于 50%)。请确保在删除文件后重新平衡,否则您仍然会遇到这种不稳定的分配策略。
具体来说,在删除这些文件后重新平衡时强制执行 RAID 10,以确保您摆脱那些单个分配的块,如下所示:
btrfs fi balance start -dconvert=raid10 -mconvert=raid10 /home