在我抢救了一些磁盘后，我将结果（几TB的磁盘映像）从本地网络数据存储（LNDS）以文件形式复制到目标磁盘。通常目标磁盘的文件系统是NTFS。 LNDS 能够以 > 600MB/s 的速度（在 10Gbit 网络上）向我传递数据。目标磁盘能够以 >150 MB/s 的持续速度保存数据。但是从服务器复制文件到目标磁盘文件系统的速度慢得要命，etwa 60-80MB/s。今天我被要求准备两份。好吧，我使用 tee 命令指定了两个目标：
dd if=/servermount/path/file.img bs=8192 |tee /localmount/target1/file.img >/localmount/target2/file.img
（cp无法分叉tee）但令我惊讶的是：复制速度只有约40MB/s。我立即开始分析流量：网络以 40MB/s 的持续速度加载数据，两个磁盘都以最大速度 160MB/s 写入，但写入时间不到 25%。
我查看了一下，top发现 CPU 在两个mount.ntfs进程上花费了大部分时间 - 每个进程都花费 > 40% - 并且tee大约占用了 CPU 时间的 30%。
我还尝试了一个反向过程：我在我的工作站上启动了一个 samba 服务器，将两个目标添加为共享，并将数据从服务器发送到两个磁盘。我再次感到惊讶，因为常见速度已增长到 66 - 69 MB/s，而 mount.ntfs 进程只花费了大约 7% 的 CPU 时间。
我不明白，为什么推网和拉网之间存在如此大的差异，而且方式与预期不同。
并非所有 bash 命令都适合使用tee.如果dd目标为/dev/null650-700MB/s 的速度。如果我将物理磁盘复制到另外两个 phy.磁盘（无论是克隆还是创建两个磁盘映像）复制速度都超过 120MB/s，如果目标位于服务器 (LNDS) 上，我得到的速度也是相同的。
有人可以解释一下我做错了什么吗？是否有一些复制命令更适合将大文件从 LNDS 复制到两个本地磁盘？
答案1
我尝试了在互联网上找到的一些提示：
建议我使用选项挂载 NTFS：big_writes。我可以承认，它确实可以将CPU负载从40%降低到5-7%。但主要问题是，为什么之前显示的dd命令的吞吐量低于 40 MB/s，这个问题仍然存在。
下一个提示是同时使用两个独立的进程将源复制到第一个目标，并将相同的源复制到第二个目标，如下所示：
# (cp /servermount/path/file.img /localmount/target1/)&
# (cp /servermount/path/file.img /localmount/target2/)&
这可以从两个控制台发送，也可以通过使用后台进程从单个控制台发送。
让我惊讶的是，网络持续速度超过 110MB/s，并且两个磁盘的写入几乎同步，速度超过 170MB/s，占空比约为 50-70%。
好吧，我找到了一些解决方案。操作系统具有如此良好的磁盘缓冲区管理能力，能够“为我们进行创造性思考”，这可能是一个很好的功能，但另一方面，我无法理解操作系统与合理期望直接相反的行为。即使dd来自物理磁盘的相同命令也可以完美运行。
希望我不要再因为默默表达自己的意见而受到惩罚。