主页 / server / 问题 / 817751
Accepted
Austin
Asked: 2016-11-30 12:22:03 +0800 CST

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

  • 772

几乎所有地方我都在抱怨日志中遇到失败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，并执行了命令。然后我再次重新启动我的机器以获得良好的效果，它似乎已经解决了这个问题

hard-drive disk-space-utilization filesystems

4 个回答

  1. Best Answer

    欢迎来到 BTRFS 的世界。它有一些诱人的功能，但也有一些令人愤怒的问题。

    首先，关于您的设置的一些信息，看起来您在 BTRFS“raid 10”卷中有四个驱动器（因此所有数据都存储在不同的磁盘上两次）。然后这个 BTRFS 卷被分割成不同挂载点上的子卷。子卷共享一个磁盘空间池，但具有单独的 inode 编号，并且可以安装在不同的位置。

    BTRFS 在“块”中分配空间，块被分配给特定类的数据或元数据。可能发生的事情（并且在您的情况下看起来已经发生了）是所有可用空间都分配给数据块，没有为元数据留下空间

    似乎（由于我不完全理解的原因）BTRF 在使用的​​元数据空间比例指标达到 100% 之前“耗尽”了元数据空间。

    这似乎是您的情况发生的情况，有很多可用数据空间，但没有未分配给块的可用空间，并且现有元数据块中的可用空间不足。

    解决方法是运行“重新平衡”。这将移动数据，以便一些块可以返回到“全局”空闲池，在那里它们可以作为元数据块重新分配

    btrfs fi balance start -dusage=5 /mnt/durable

    后面的数字-dusage设置了重新平衡的积极程度，即需要多接近清空块才能被重写。如果余额说它重写了 0 个块，请使用更高的值重试-dusage。

    如果余额失败，那么我会尝试重新启动和/或通过删除文件来释放一些空间。

    • 20

  2. 由于您使用 RAID 设置运行 btrfs，因此请尝试运行平衡操作。

    btrfs balance start /var/opt/gitlab

    如果这给出了关于没有足够空间的错误，请使用以下语法重试：

    btrfs balance start -musage=0 -dusage=0 -susage=0 /var/opt/gitlab

    对您看到有关空间错误的每个 btrfs 文件系统重复此操作。如果您的空间问题是由于元数据没有分布在镜像磁盘上，这可能会为您腾出一些空间。

    • 4

  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

    如果您因为空间不足而无法重新平衡，建议在重新平衡期间临时向您的卷添加另一个某种块设备（或另一个磁盘上的环回设备），然后去掉它。

    • 2

  4. 这不是 btrfs 的问题，而是这个系统已经完成的事情。这看起来像是从“单个”分配策略到“raid 10”分配策略的不完全重新平衡的结果，大量的单个分配块证明了这一点。它可能从单一开始，然后转换被中断。分配如此不一致的池肯定会有……分配问题。

    考虑到您消耗了 61% 的池。您的分配策略是 RAID10，因此在达到满之前应该会导致最多 50% 的池消耗，因为所有内容都是复制 2。这就是您从单一到 RAID 10 的转换失败（并且继续失败）的原因。我只能猜测，但它可能是在重新平衡过程中分配的。您的设备上没有剩余空间可用于使用您拥有的磁盘重新平衡到 RAID 10。你达到 61% 的唯一原因是因为你的磁盘分配不一致，有些是线性分配的，大多数是 RAID 10。

    如果您想在不更改任何内容的情况下获得空间，您可以重新平衡到单个分配策略。您还可以添加更多磁盘或增加磁盘的大小。或者，您可以像在本例中所做的那样，只删除一堆文件，以便您的池实际上可以平衡到 RAID 10（因为总体消耗量将低于 50%）。请确保在删除文件后重新平衡，否则您仍然会有这个 janky 分配策略。

    具体来说，在删除这些文件后重新平衡时强制执行 RAID 10，以确保您摆脱那些单个分配的块，如下所示：

    btrfs fi balance start -dconvert=raid10 -mconvert=raid10 /home

    • 2

相关问题