☰

“设备没有剩余空间”还有其他原因吗？

tag-icon • tag-icon linux ubuntu filesystems rsync
“设备没有剩余空间”还有其他原因吗？

我在 Ubuntu 服务器系统上使用 Dirvish 将硬盘备份到外部 USB 3.0 驱动器。几天前，一切都运行正常，但现在每次备份都会失败，并显示“设备 (28) 上没有剩余空间”和“文件系统已满”。不幸的是，事情没那么简单：设备上有 > 500 GB 的可用空间。

细节：

rsync_错误：

rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename1>.eDJiD9": No space left on device (28)
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename2>.RHuUAJ": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename3>.9tVK8Z": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename4>.t3ARSV": No space left on device (28)
[... some more files ...]
rsync: connection unexpectedly closed (2712185 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

日志看上去和平常没什么不同，直到它出现：

<SomeFilename1>
<SomeFilename2>
<SomeFilename3>
<SomeFilename4>
<PartOfAFilename>filesystem full
write error, filesystem probably full
broken pipe
RESULTS: warnings = 0, errors = 1

但是，如上所述，设备上有很多空间：

df -h
/dev/sdg1       2.7T  2.0T  623G  77% /mnt/backupsys/shd

并且还剩余大量 inode：

df -i
/dev/sdg1      183148544 2810146 180338398    2% /mnt/backupsys/shd

该设备被挂载为rw：

mount
/dev/sdg1 on /mnt/backupsys/shd type ext3 (rw)

该进程以 root 身份运行。

我本来想说我没有改变任何东西，但事实并非如此：我已经为正在备份的驱动器打开了 acl：

/dev/md0 on /mnt/md0 type ext4 (rw,acl)

这可能是问题所在吗？如果是，怎么办？root 仍然具有对文件的完全访问权限。

编辑：

我刚刚检查了临时目录：

  • /tmp 仅包含一个空的 .webmin 文件夹
  • /var/tmp 是空的

这些目录所在的文件系统有足够的可用空间和 inode：

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       289G   55G  220G  20% /

df -i
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/sda1       19202048  167644  19034404    1% /

编辑2：

这些目录相当大，但不超过 2 GB。备份失败的目录甚至不是最大的目录之一，它包含 7530 个文件。

编辑3：

在发布此问题时，我认为有一个信息不相关：

在备份开始失败的前一天，我已在备份的文件系统上激活了 acl。我现在假设这触发了 Dirvish（或 rsync）认为所有文件都已更改，因此要复制而不是硬链接的文件列表非常大。这可能意味着某些缓冲区太小。

今天，对空磁盘进行完整备份非常顺利。接下来我将尝试增量备份。这将显示激活 acl 是否是导致问题的原因。

答案1

我的怀疑（参见 EDIT3）显然是正确的：在文件系统中添加 acl 支持使 rsync/dirvish 认为所有文件都已更改。因此，它没有进行增量备份并仅创建指向现有文件的硬链接，而是尝试创建完整备份，这当然会失败，因为硬盘没有足够的空间。

因此错误信息实际上是正确的。

使用空的备份磁盘重新启动后，增量备份像以前一样工作。

答案2

看到剩下的 2% 的 inode，我就开始思考 EXT 文件系统所施加的根保留空间。你可能需要查看这些内容：

  1. “文件系统上为根保留的空间-为什么？“
  2. “非操作系统磁盘的“文件系统保留块”的合理大小是多少？“

我会尝试将一些较旧的备份压缩为 .tar.gz，希望这样可以减少正在使用的 inode 数量。

答案3

我看到 dummzeuch 找到了解决他的问题的方法，但实际上我发现还有一种情况，磁盘可以有足够的 inode/可用空间，但在尝试传输某些目录时仍然显示“设备上没有剩余空间”。

这是由使用 ext4 文件系统格式化的块设备上的哈希冲突引起的，其中目录索引也已启用，特别是当单个目录中包含超过 100k 个文件并且文件的名称由相同算法生成（缓存文件、md5sum 文件名等）时

解决方案是尝试另一种目录索引算法：

tune2fs -E "hash_alg=tea" /dev/blockdev_name

或者完全禁用该块设备的目录索引（可能会影响性能）

tune2fs -O ^dir_index /dev/blockdev_name

另一个解决方案是查看目录中填充了哪些此类文件，然后修复该软件。

可能的解决方案是将包含大量文件的文件夹内容拆分到多个单独的子文件夹中。

Axel Wagner 在此处提供了该问题的完整描述

http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

干杯。

答案4

在 sysctl 中增加 Inotify 观察者限制：

fs.inotify.max_user_watches=100000

然后重新启动，或者sysctl -w也执行该版本。

通常这样就可以了。某些程序在内核中打开了太多文件，错误完全是误导性的。Dropbox 就是一个典型的例子。

相关内容