我目前在使用dd
稀疏文件作为输入(if
)和文件作为输出(of
)时遇到麻烦conv=sparse
。dd
似乎仅使用一个CPU Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz
内核(4个内核+ 4个Intel Hyperthreads)(1个内核的100%),因此我一直在想是否可以并行化dd
。我去过
- 寻找到
info dd
和man dd
而且似乎内置功能corutils 8.23版本 sgp_dd
从sg3-utils
程序包中检查(不了解它是否适合我的需求),但是似乎无法处理稀疏文件dcfldd
似乎没有并行化功能
据我所知
- 与在多个线程中内部处理程序部分的增强版本/分支(避免上下文更改导致I / O性能下降)相比,它更可取
- 在
parallel
本地运行GNU的解决方案优先于 - 定制(可能未经测试)的代码片段
如何避免CPU成为I / O密集型操作的瓶颈?我想在具有Linux 3.13的Ubuntu 14.04上运行命令,并在支持稀疏文件的任何文件系统上使用它来处理稀疏文件磁盘映像(至少该解决方案不应绑定到一个特定的文件系统)。
背景:我正在尝试在zfs(zfsonlinux 0.6.4不稳定版本,可能有故障以及导致CPU瓶颈的原因(最终漏洞搜索缓慢))上创建11TB稀疏文件(包含大约2TB数据)的副本。对于如何并行化dd的问题,这应该不会有任何改变(以一种非常通用的方式)。
我看不到您能从中得到什么,因为此操作是I / O绑定的,除非在极端情况下。我认为最好的选择是稀疏的程序,例如xfs_copy。它的手册页中提到:“但是,如果文件是在XFS文件系统上创建的,则该文件将消耗文件系统和XFS日志在源文件系统中实际使用的空间。该空间节省是因为xfs_copy会搜索可用块而不是复制它们,XFS文件系统有效地支持稀疏文件。”
—
Cristian Ciupitu 2014年
@mikeserv我不明白您的评论……
—
Karl Richter
@CristianCiupitu就我而言,CPU是瓶颈-不要问我为什么,因为我不知道。您的回答使我意识到,该解决方案应支持多个文件系统(能够处理稀疏文件)(已编辑)
—
Karl Richter 2014年
您拥有什么CPU和文件系统?文件有多大(长度和块)?
—
Cristian Ciupitu 2014年
dd
由于块大小较小,默认情况下会占用CPU。使其变大,例如bs=1M
。