我最近缩减了我的家庭网络规模，其中最大的变化之一是改用 BD-RE 驱动器进行备份。由于多年的图片和家庭视频消耗了大约 25GB，而[重要]文档远低于 10GB，这似乎是一个很好的方法。
一切都很完美，我唯一关心的是开销。我有 UDF 格式的光盘，以及每晚运行的脚本rsync，用于将文件系统中选定的路径同步到驱动器。
在同步期间，我的 CPU 显示大约 25% 处于等待状态。这不会那么糟糕，但它会在很长一段时间内保持在这个水平，并且在此过程中，一切都会变得缓慢。我什至观察到我的平均负载飙升至 15.9+（在 Core 2 Quad 上）。这段时间内“实际”CPU 利用率仅为 6% 左右（所有虚拟机的总和），因此这严格来说是一个 I/O 瓶颈。
与其他内容相比，专门针对蓝光刻录机的文档（在 Linux 下）很少，而且我从来没有遇到过足够高的 I/O 瓶颈来保证进行任何深入分析。考虑到驱动器以 2 倍（约 9MB/s）的速度刻录，它应该在大约一个小时内完成，但实际上运行了多个小时。
有什么方法可以优化它以减少等待状态吗？我只是受到内核驱动程序/硬件/的限制吗？？？这是否只是我不知道的使用 UDF 的令人讨厌的副作用？这是否与运行 3 个虚拟机（2 个 Windows 和 1 个 MythTV）以及 NFS 以及此过程有关？有什么方法可以确定问题出在哪一块拼图上？
抱歉最后提出了一系列问题；任何帮助是极大的赞赏。
编辑：得到 psusi 的回答后，我有了一个想法；有没有办法根据每个设备确定 I/O 的优先级？类似于“保证 XXX PCI 卡 1MB/s”、“限制 XXX 块设备为 20MB/s”之类的东西？？？
答案1
等待时间是正常的。等待意味着 cpu 不忙，但如果程序 ( rsync ) 没有等待磁盘 IO （写入慢速 blueray ），则可能会忙。它是 25%，因为您有 4 个 cpu，并且 rsync 只能使用其中之一 ( 1/4 = 25% )，如果它不在磁盘上等待的话。
至于整体吞吐量较低，那是因为rsync必须首先从光盘读取文件，计算校验和，从硬盘读取文件，比较，找出更改的内容，然后写入更改的部分。花在阅读上的所有时间都会减慢速度。
rsync实际上是为了通过慢速网络在两个快速硬盘之间移动数据，而不是移动到读/写安装的 udf 光盘。您最好使用传统的备份系统，例如tar.