☰

Rsync 抛出错误，但文件似乎没问题

tag-icon • tag-icon shell files rsync cifs smb
Rsync 抛出错误，但文件似乎没问题

我正在使用 rsync 进行 200TB 的大规模传输。我使用了从互联网上找到的 shell 脚本来生成一些进程，但这里是相关的 rsync 命令本身：

        rsync --recursive \
              --whole-file \
              --inplace \
              --sparse \
              --no-compress \
              --max-alloc=8GiB \
              --size-only \
              --human-readable \
              --info=progress2 \
              --log-file="$rsync_file_basename.log" \
              --log-file-format="%o=%-7'''b | total=%-7'''l [%i] => %f%L" \
           "/mnt/disk${disk_id}/$share_name/$share_subdir/" \
           "$target_path" \
        >> "$rsync_file_basename.out"

传输进展顺利，但在查看日志时，我发现偶尔会出现两种错误。

主要是这样的：

rsync：[接收方] ftruncate 在“/mnt/remotes/TS140_stuff/pictures/family_1/IMG345.jpg”上失败：资源暂时不可用 (11)

但也包括其中一些：

rsync: [receiver] 在“/mnt/remotes/TS140_stuff/shows/ep1.mp4”上写入失败：资源暂时不可用 (11) rsync 错误：receiver.c(380) 处的文件 IO（代码 11）中出现错误 [receiver= 3.2.7] rsync：[发送者]写入错误：管道损坏（32）rsync错误：io.c（1700）处的文件IO（代码11）错误[发送者= 3.2.7]

现在，目标目录是 SMB 挂载，这是大量数据，因此我预计会出现类似的情况。

但写这篇文章的原因是我可以在目标目的地看到文件，而且它们看起来很好。 rsync 是否有某种基于命令使用的重试逻辑？

答案1

rsync并没有真正进行重试。然而，没有什么可以阻止你将它包装在一个循环中：

#!/bin/sh
k=1 ss=1
while [ "$k" -le 5 ] 
do
    echo "Attempt $k" >&2
    rsync -rt ... &&
        ss=0 &&
        break
    sleep 60
    k=$((k+1))
done

if [ "$ss" -ne 0 ]
then
    echo "ERROR: rsync repeatedly failed" >&2
    exit 1
fi

确保使用--times( -t) 标志，否则此循环将不断重复，直到$k耗尽。您了解您选择的标志的实际用途吗？它们是一组奇怪的东西，我建议删除其中的大部分：

rsync -rtS
    --info=progress2 \
    --log-file="$rsync_file_basename.log" \
    --log-file-format="%o=%-7'''b | total=%-7'''l [%i] => %f%L" \
    "/mnt/disk$disk_id/$share_name/$share_subdir/" \
    "$target_path"

最后，如果您可以直接访问提供 SMB 共享的服务器，则通过rsync在其网络模式下使用，您将获得（至少）重试的显着速度提升：

rsync -rtSz local_path/ remote_host:remote_path

相关内容