☰

日常备份时 rsync 出现 IO 错误

tag-icon • tag-icon rsync linux-kernel
日常备份时 rsync 出现 IO 错误

我有一个示例 NAS 服务器 (QNAP TS-210)，其板载 Linux 非常有限（尽管使用 Optware/IPKG 进行了一些加强）。我是一个 Linux 新手。在浏览互联网后，我能够编写自己的备份脚本，使用 rsync 在 NAS 硬盘驱动器和外部 USB 驱动器之间同步文件，并使用 CRON 定期运行该脚本。

直到几天前一切都很好。备份脚本生成的电子邮件开始包含IO error encountered -- skipping file deletion许多正在备份的资源（文件夹）的信息。当我通过 SSH 运行相同的脚本时，我收到很多错误行，上面写着“ cannot send file with empty name in...”，后面跟着“ rsync error: some files/attrs were not transferred (see previous errors)”。

我备份的内容 100% 来自 Windows（我仅使用 NAS 来备份自己的计算机）。该系统不允许创建空名称的文件。这个问题只存在几天，而且我已经有几个星期（假期）没有修改我的备份了。所以这一定是 Linux（我的 NAS 上的）问题。

问题是：什么会导致文件显示为空名称？我怎样才能摆脱它们（当我cd到 rsync 报告中提到的文件夹并执行操作时ls -ls，我看不到任何类似“名称为空的文件”之类的内容），因此下一个 rsync 传递最终将不会出现此类错误。最后——如何避免将来获得此类文件？

答案1

我不认为这是 rsync 的错。我认为您已正确地将其标记为内核级问题，因为相关代码来自 rsync 的flist.c来源内容如下：

1729         for (errno = 0, di = readdir(d); di; errno = 0, di = readdir(d)) {
1730                 unsigned name_len;
1731                 char *dname = d_name(di);
...
1746                 if (dname[0] == '\0') {
1747                         io_error |= IOERR_GENERAL;
1748                         rprintf(FERROR_XFER,
1749                                 "cannot send file with empty name in %s\n",
1750                                 full_fname(fbuf));

事实上，这行代码是rsync开发者添加的早在2007年8月特别针对这种情况：

If readdir() gives us an empty name, reject it.

换句话说，readdir()它本身（返回目录中文件列表的内核函数）返回一个带有空字符串的条目。根据规则，这种事永远不应该发生。引用自开放组规格:

The readdir() function shall not return directory entries containing empty names.

听起来这是某种暂时性问题，因为当您ls在该目录中执行 an 操作时，它已经消失了（也可以使用readdir()，它已经消失了）。

所以回答你的问题：

  1. 原因似乎是文件系统损坏 - 从内核驱动程序错误到硬件故障都可能是原因。还可能值得检查您正在同步的目录是否通过符号链接访问或跨越可能存在问题的网络边界本身。

  2. 要摆脱它们：通常的文件系统修复清单：fsck 等。

  3. 为了避免将来：我想你可以告诉你的脚本预先强制递归列表 - 但由于你已经引起注意（并且你从假期回来），似乎正确的做法是密切关注如果再次发生这种情况，就跳到盒子上。

希望这有用，祝你好运！

相关内容