☰

尽管 btrfs 上有足够的空间，但仍出现“设备上没有剩余空间”错误

tag-icon • tag-icon hard-drive filesystems disk-space-utilization
尽管 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，并且命令执行成功。然后我再次重启了机器，似乎问题已经解决了

答案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

相关内容