dd
我目前在使用稀疏文件作为输入 ( if
) 和文件作为输出 ( of
)进行调用时遇到问题conv=sparse
。dd
似乎只使用CPU的一个核心(Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz
4个核心+ 4个英特尔超线程)(1个核心的100%),所以我一直想知道是否可以并行化dd
。我去过
- 查看
info dd
andman dd
and 似乎在corutils 8.23版本中有内置函数 sgp_dd
从包中检查sg3-utils
(不了解它是否适合我的需求),但它似乎无法处理稀疏文件dcfldd
似乎没有并行化能力
AFAIK
- 优先于在多个线程中对程序部分进行内部处理的增强版本/分支(避免上下文更改破坏 I/O 性能)
- 本地运行GNU 的解决方案
parallel
优于 - 自定义(可能未经测试)代码片段
如何避免CPU成为I/O密集型操作的瓶颈?我想在带有 Linux 3.13 的 Ubuntu 14.04 上运行该命令,并在任何支持稀疏文件的文件系统上使用它处理稀疏文件磁盘映像(至少该解决方案不应绑定到一个特定的文件系统)。
背景:我正在尝试在 zfs(zfsonlinux 0.6.4 不稳定版本,可能有错误以及 CPU 瓶颈的原因(最终缓慢的空洞搜索))上创建 11TB 稀疏文件(包含约 2TB 数据)的副本。对于如何并行化 dd (以非常通用的方式)的问题,这不应该改变任何事情。
答案1
在 Bash 中测试:
INFILE=in
seq 0 1000 $((`stat --format %s $INFILE` /100000 )) |
parallel -k dd if=$INFILE bs=100000 skip={} conv=sparse seek={} count=1000 of=out
您可能需要调整 1000。
答案2
即将出现一个自定义的、未经测试的代码片段:
dd if=oldf conv=sparse bs=1k count=3000000000 of=newf &
dd if=oldf conv=sparse bs=1k skip=3000000000 count=3000000000 seek=3000000000 of=newf &
dd if=oldf conv=sparse bs=1k skip=6000000000 count=3000000000 seek=6000000000 of=newf &
dd if=oldf conv=sparse bs=1k skip=9000000000 count=3000000000 seek=9000000000 of=newf &
wait
这应该在逻辑上将文件划分为四个 3TB 的块并并行处理它们。 (skip=
跳过输入块;seek=
查找输出块。)当然,第四个命令将读取到旧文件的末尾,因此该count=
参数并不是绝对必要的。