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

我在Ubuntu服务器系统上使用Dirvish将HD备份到外部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

而且还有很多索引节点：

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）以为所有文件都已更改，因此要复制而不是硬链接的文件列表很大。这可能意味着某些缓冲区太小。

如今，完全备份到空磁盘的工作已完美进行。接下来，我将尝试增量备份。这将显示激活acls是否是问题的原因。

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

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

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

看一下剩下的2％的inode，我想到了EXT文件系统强加的根储备。您可能需要检查以下内容：

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

我会尝试对一些较旧的备份进行.tar.gz备份，以期减少使用中的inode数量。

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

这是由使用ext4文件系统格式化的块设备上的哈希冲突导致的，其中还启用了目录索引功能，特别是在单个目录中包含超过10万个文件并且文件名由相同算法生成的情况下（缓存文件，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

干杯。

目录本身有2GB的大小限制-即，如果您有太多文件，而目录大小大于2GB（而不是目录中文件的大小），则会遇到问题。话虽如此，仅使用280万个inode，这不应该成为问题。通常发生在1500万个inode附近。

因此，这可能不会有太大帮助-但是在备份设备上尝试使用ext4吗？

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

fs.inotify.max_user_watches = 100000 

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

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

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

1. 查看您的临时目录是否未满。有时，它用于中间存储，并且很容易装满。
2. 检查是否有一个进程仍在保存已删除文件的描述符。由于df报告大小合适，因此可能性较小，但仍然不会受到伤害。

我在寻找问题的解决方案时才发现此主题。

的确，至少有其他原因导致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).

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