我在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仍然具有对文件的完全访问权限。
编辑：
我只是检查了临时目录：
这些目录所在的文件系统有足够的可用空间和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% /
EDIT2：
目录是相当大的，但不是> 2 GB。 备份失败的甚至不是最大的一个，它包含7530个文件。
EDIT3：
发表这个问题时我不认为有关的一个信息：
在备份开始失败的前一天，我已经在备份的文件系统上激活了acls。 我现在假设这触发了Dirvish（或rsync）认为所有的文件已经改变，所以复制而不是硬链接的文件列表非常大。 这可能意味着一些缓冲区太小了。
今天，一个完整的备份到一个空的磁盘工作完美无瑕。 我会尝试下一个增量备份。 这将显示是否激活acls是导致问题的原因。
看看左边的inode的2％，让我想到了EXT文件系统强加的根保留。 你可能想要检查这些：
我会尝试.tar.gz一些较旧的备份，希望它会减lessinode使用的数量。
我的怀疑（见EDIT3）显然是正确的：添加acl支持文件系统rsync / dirvish认为所有的文件已经改变。 因此，不是创build增量备份，而是创build硬链接到已经存在的文件，而不是创build一个完整的备份，当然因为硬盘没有足够的空间而失败。
所以错误信息实际上是正确的。
在用空的备份磁盘重新启动后，增量备份像以前一样工作。
我发现dummzeuchfind了解决问题的办法，但实际上还有一个例子，我发现磁盘可以拥有足够多的inode /可用空间，并在尝试传输某些目录时仍然显示“设备上没有剩余空间”。
这是由于使用ext4文件系统格式化的块设备上的哈希冲突导致的，其中目录索引也被启用，特别是在单个目录托pipe超过100k个文件的情况下，文件的名称由相同algorithm生成（caching文件，md5sum文件名等。）
解决方法是尝试使用另一个目录索引algorithm：
tune2fs -E "hash_alg=tea" /dev/blockdev_name
或者完全禁用该块设备的目录索引（可能会影响性能）
tune2fs -O ^dir_index /dev/blockdev_name
另一个解决scheme是查看用这些文件填充目录并修复软件。
可能的解决scheme是将具有大量文件的文件夹的内容拆分为多个单独的子文件夹。
Axel Wagner在这里详细描述了这个问题
http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
干杯。
目录本身有一个2GB的大小限制，即如果目录大小大于2GB的文件（不是目录中的文件的大小），则会遇到问题。 话虽如此，只有2.8M的inode使用，这不应该是一个问题。 通常发生在15M左右的节点。
所以这可能没有太大的帮助 – 但是在备份设备上试试ext4？
在sysctl中增加Inotify观察者限制：
fs.inotify.max_user_watches = 100000
并重新启动，或执行sysctl -w版本也。
这通常会做到这一点。 内核中打开的文件太多，错误是完全误导的。 Dropbox就是一个典型的例子。
我build议你检查一下其他的东西：