尽pipe在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,然后执行该命令。 然后,我再次重新启动我的机器,好的措施,似乎已经解决了这个问题

欢迎来到BTRFS的世界。 它有一些诱人的特点,但也有一些令人生气的问题。

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

BTRFS在“块”中分配空间,块分配给数据或元数据的特定类。 可能发生的事情(看起来像是发生在你的情况)是,所有的空闲空间被分配给数据块,没有元数据的空间

也似乎(由于我不完全理解的原因)BTRF在元数据空间使用比例的指标达到100%之前“已经用完了”元数据空间。

这似乎是你的情况发生了什么,有大量的免费数据空间,但没有可用空间没有被分配到块和现有的元数据块空间不足。

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

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

数后的数字-dusage了重新平衡的积极性,也就是说,重新平衡块的空置程度有多接近。 如果余额表示重写了0块,则使用更高的-dusage值重-dusage

如果天平失败,我会尝试通过删除文件重新启动和/或释放一些空间。

由于您使用RAID设置运行btrfs,请尝试运行平衡操作。

 btrfs balance start /var/opt/gitlab 

如果这给出了没有足够空间的错误,请尝试使用以下语法:

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

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

在我的系统上,我在cron.monthly中添加了以下作业。

clear_cache重新挂载是由于btrfs与免费地图有关的一些腐败问题。 (我想他们终于find了这个问题,但是这个问题太讨厌了,我愿意花钱每月重build一次地图。)

我增加了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 

如果由于空间不足而无法重新平衡,build议在重新平衡期间临时将另一个块设备(或另一个磁盘上的环回设备)添加到您的卷中,然后去掉它。

这与btrfs不是一个问题,而是这个系统已经完成的事情。 这看起来像是从“单一”分配策略到“RAID 10”分配策略的不完全重新平衡的结果,如大量单个分配的块所certificate的。 它可能是从单一开始,然后转换被中断。 这种分配不一致的池必然会有…分配问题。

考虑你有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