使用cat,dd,pv或其他过程复制CD / DVD更好吗?


22

背景

我正在将一些数据CD / DVD复制到ISO文件中,以便以后在驱动器中不需要它们时使用它们。

我在网上寻找程序,发现了很多东西:

我不知道是不是所有的人都应该是等价的,虽然我测试了其中的一些(使用md5sum工具)和,至少,dd并且pv等价的。以下是md5sum使用每个过程的驱动器和生成的文件:

dd程序的md5: 71b676875b0194495060b38f35237c3c

光伏程序的md5: f3524d81fdeeef962b01e1d86e6acc04

编辑:该输出是从另一张CD而不是给定的输出。实际上,我意识到我提供了一些有趣的事实作为答案。

实际上,每个文件的大小相互比较是不同的

因此,是否有最佳的过程来复制CD / DVD,或者我只是错误地使用了命令?


有关情况的更多信息

这是有关我用来检查到目前为止找到的过程的测试用例的更多信息:

isoinfo -d i /dev/sr0 输出:https : //gist.github.com/JBFWP286/7f50f069dc5d1593ba62#file-isoinfo-output-19-aug-2015

dd复制带有输出校验和和文件信息的介质输出:https : //gist.github.com/JBFWP286/75decda0a67605590d32#file-dd-output-with-md5-and-sha256-19-aug-2015

pv复制带有输出校验和和文件信息的介质输出:https : //gist.github.com/JBFWP286/700a13fe0a2f06ce5e7a#file-pv-output-with-md5-and-sha256-19-aug-2015

任何帮助将不胜感激!

linux  dd  cat  disk-image  pv 

文件大小是否相同?结果cmp file1 file2?您是否使用dd了错误的代码count=(或者实际上根本没有任何计数,如果您想要整个东西,那是没有必要的?)。读取dmesg中的错误?
弗罗斯特斯

2
不用说,不同大小的文件(具有99.9999999999 +%的概率)将具有不同的校验和。只要您完成了测试,就可以发布所有结果,包括(1)dd您所使用的确切命令(什么是块大小?什么计数?),(2)大小和校验和,这将是很好的。所有输出,以及(3)您拥有的有关源光盘上数据量的任何独立信息。……………………PS为什么要使用count=on dd?您想复制整个磁盘映像,不是吗?  count=说“复制很多然后停止”。
斯科特,

@Scott在linuxjournal.com/content/archiving-cds-iso-commandline的此页面中,作者说一个人应该isoinfo -d -i /dev/cdrom知道并使用计数-实际上,他说一个人不应该只使用它dd。“无论如何,如果您想要该CD的正确ISO映像,则需要在创建映像之前正确设置块大小和块计数。”

@frostschutz在第一种情况下,大小并不相同,但是令人惊讶的是,我再次尝试并获得了不同的结果。有关更多详细信息,请参见我提供的答案。

Answers:


27

以下所有命令都是等效的。他们读取CD的字节/dev/sr0并将其写入名为的文件image.iso

cat /dev/sr0 >image.iso
cat </dev/sr0 >image.iso
tee </dev/sr0 >image.iso
dd </dev/sr0 >image.iso
dd if=/dev/cdrom of=image.iso
pv </dev/sr0 >image.iso
cp /dev/sr0 image.iso
tail -c +1 /dev/sr0 >image.iso

你为什么要使用一个?

  • 简单。例如,如果您已经知道catcp,则无需学习其他命令。

  • 坚固性。这有点简单。更改命令将更改其功能有多少风险?让我们看几个例子:

    • 与重定向有关的任何事情:您可能不小心将重定向错误地绕了过来,或者忘记了它。由于目标应该是一个不存在的文件,因此set -o noclobber应确保您不会覆盖任何内容。但是,如果不小心写入,则可能会覆盖设备>/dev/sda(对于CD,它是只读的,当然没有风险)。相cat /dev/sr0 >image.iso对于其他选择(例如,tee </dev/sr0 >image.iso如果您反转了重定向或忘记了输入,tee将写入/dev/sr0),这表示赞成(以破坏性的方式很难出错)。
    • cat:您可能不小心将两个文件串联在一起。这样就可以轻松挽救数据。
    • ddio并且在键盘上关闭,有些不寻常。没有等效的noclobberof=将很乐意覆盖任何内容。重定向语法不太容易出错。
    • cp:如果不小心交换了源和目标,则该设备将被覆盖(同样,假设是非只读设备)。如果cp使用某些选项(例如-R-a某些人通过别名添加的选项)调用了if ,它将复制设备节点而不是设备内容。
  • 附加功能。这里具有有用的附加功能的一个工具是pv,它具有强大的报告选项。
    但是在这里您仍然可以通过查看输出文件的大小来检查已复制了多少。

  • 性能。这是一个受I / O约束的过程。影响性能的主要因素是缓冲区大小:该工具从源读取块,将块写入目标,然后重复。如果块太小,计算机将花费时间在任务之间进行切换。如果块太大,则无法并行进行读取和写入操作。PC上的最佳块大小通常约为几兆字节,但这显然非常取决于操作系统,硬件以及计算机在做什么。不久前,我在Linux上对硬盘到硬盘副本进行了基准测试,结果表明,对于dd 具有较大缓冲区大小的同一磁盘中的副本,它具有优势,但对于跨磁盘副本,cat则胜过任何dd缓冲区大小。

您为什么dd经常提到它有几个原因。除了性能之外,它们并不是特别好的理由。

  • 在非常老的Unix系统中,某些文本处理工具无法处理二进制数据(它们内部使用了以null终止的字符串,因此它们在使用null字节时往往会遇到问题;某些工具还假定字符仅使用7位并且没有使用正确处理8位字符集)。我不知道这曾是一个问题cat(这是与更多的面向行的工具,如headsed等),但人们往往避免它,因为它与文本处理关联的二进制数据。在现代系统(例如Linux,OSX,* BSD或任何符合POSIX的系统)上,这不是问题。
  • 有一种说法dd比其他cat直接访问设备的工具“低级” 。这完全是错误的:ddand catteeand其他所有人都从其输入读取字节并将字节写入其输出。真正的魔力在里面/dev/sr0
  • dd有一个不寻常的命令行语法,因此,解释它的工作方式将为您提供更多机会,使他们能够通过解释刚刚编写的内容而大放异彩cat /dev/sr0
  • 使用dd 较大的缓冲区可以提高性能,但并非总是如此(请参阅Linux上的一些基准测试)。

一个主要的风险dd它可以静默地跳过一些数据。我认为dd只要通过skipcount不通过都是安全的,但是我不确定在所有平台上是否都是这种情况。但是除了性能之外,它没有任何优势。

因此,pv如果您想要其进度报告,请使用它,否则cat请使用。


非常感谢您抽出宝贵时间写此回复!=)现在,我了解了它们之间的区别。只是一个问题:是否pv < /dev/sr0 > image.iso相同pv /dev/sr0 > image.iso(后者可在pv的手册页中找到)?

1
@ JBFWP286他们复制相同的内容,但是pv /dev/sr0 …可以在进度报告中包含文件名,而pv </dev/sr0不能。
吉尔(Gilles)'所以

另一个注意事项:cp可能是的别名cp -R(至少在GNU cp上是root),导致cp复制设备节点而不是其内容。
marcelm

2
@ JBFWP286 设备节点是一个文件,通过它可以访问硬件或内核驱动程序提供的其他特殊功能。几乎所有文件/dev都是设备节点。例如,cp -R /dev/sr0 image.iso将制作image.iso一个文件来访问CD驱动器,就像一样/dev/sr0,而不是包含包含CD内容副本的常规文件cp /dev/sr0 image.iso
吉尔(Gilles)'所以

1
@Hashim我不能断定它具有更好的性能。我提到有时它的性能更好。我已经连接到基准我做-在最好的情况下ddcat而只是以微弱的差距。
吉尔斯(Gillles)“所以-别再作恶了”

4

在这种情况下,有一些有趣的事实,尤其是这些事实:

  • 我刚刚检查了获得和提供的输出(这次我使用了另一张光盘,确切地说是Xubuntu 15.04 x64安装光盘),并且在两个过程(ddpv)中,校验和都是相同的
  • 我的想法是,在执行完该dd过程之后,打开驱动器并用同一张光盘将其关闭,然后通过该pv过程完成测试。这样做,我得到了两个过程的相同副本。
  • 认为我是第一次获得不同的校验和,因为出于某种原因,从CD / DVD驱动器收集的数据似乎会“记录”到其他目的一段时间(例如缓存),因此,诸如校验和之类的其他操作是比转帐快很多。如果您知道确切原因,请发表评论。
  • 另一个事实是,ddw / o count=X参数在光盘末尾正确停止,并且提供与相同的光盘映像pv(校验和相同),所以对我来说,最好使用ddw / o参数或just pv

因此,就目前而言,看起来pvdd可以完成CD / DVD复制并获得相同的结果。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.