主页 / server / 问题 / 482173
Accepted
dummzeuch
Asked: 2013-02-26 00:54:33 +0800 CST

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

  • 772

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

细节：

rsync_error：

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 是空的

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

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：

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

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

今天，对空磁盘的完整备份完美无缺。接下来我将尝试增量备份。这将显示激活 acls 是否是问题的原因。

linux

7 个回答

  1. Best Answer

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

    所以错误信息实际上是正确的。

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

    • 5

  2. 看着剩下的 2% 的 inode 让我想到了 EXT 文件系统强加的根保留。你可能想看看这些：

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

    我会尝试 .tar.gz 一些较旧的备份，希望它能减少正在使用的 inode 数量。

    • 4

  3. 我看到 dummzeuch 找到了解决他的问题的方法，但实际上还有一个案例我发现磁盘可以有足够的索引节点/可用空间并且在尝试传输某些目录时仍然显示“设备上没有剩余空间”。

    这是由使用 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

  4. 目录本身有 2GB 的大小限制——也就是说，如果您有太多文件以至于目录大小大于 2GB（不是目录中文件的大小），您就会遇到问题。话虽如此，仅使用了 2.8M inode，这应该不是问题。通常发生在 15M inode 左右。

    所以这可能没有太大帮助 - 但在您的备份设备上尝试 ext4 吗？

    • 1

  5. 增加 sysctl 中的 Inotify 观察者限制：

    fs.inotify.max_user_watches=100000

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

    这通常会做到这一点。某些东西在内核中打开了太多文件，并且该错误完全是误导性的。Dropbox 就是一个典型的例子。

    • 1

  6. 我建议您检查其他几件事：

    1. 查看您的临时目录是否未满。有时它用于中间存储，很容易装满。
    2. 检查是否有一个进程仍然持有已删除文件的描述符。由于 df 报告了适当的大小，所以机会不太可能，但它仍然不会受到伤害。
    • 0

  7. 我只是在寻找问题的解决方案时发现了这个主题。

    事实上，ENOSPC 至少还有其他原因。在从 ZFS 文件系统复制到 EXT4 文件系统时，我也用 rsync 发现了它：

    rsync: rsync_xal_set: lsetxattr(""/my/file/path"","example.xattr.attribute") failed: No space left on device (28)

    在这种情况下：

       ENOSPC - There is insufficient space remaining to store the extended attribute.

    man 7 xattr解释：

       In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes
   must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).

    就我而言，这意味着我必须重新格式化整个文件系统。:-(

    • 0

相关问题