我应该使用Python还是Assembly来实现超快的复制程序

Question

作为一个维护问题，我需要常规地(每年3-5次)复制一个存储库，该存储库现在有超过2000万个文件，总磁盘空间超过1.5TB。我目前正在使用RICHCOPY，但已经尝试过其他方法。RICHCOPY似乎是最快的，但我不相信我的XP机器的能力已经接近极限。

我正在使用我在汇编语言艺术中读到的东西来编写一个程序来复制我的文件。我的另一个想法是开始学习如何在Python中使用多线程进行复制。

我正在考虑在Assembly中做这件事，因为它看起来很有趣，但虽然我的时间不是特别宝贵，但它足够宝贵，我试图了解我是否会在复制速度方面获得足够大的收益。我假设我会，但我只是开始真正学习编程18个月，它仍然或多或少是一种爱好。因此，我可能遗漏了一些关于解释型语言的基本概念。

如有任何观察或经验，我们将不胜感激。注意，我不是在寻找任何代码。我已经用Python2.6编写了一个基本的复制程序，它的速度不会比RICHCOPY慢。我正在寻找一些能给我带来更多速度的观察。现在，我花了50多个小时从磁盘复制到Drobo，然后再从Drobo复制到磁盘。当我只是简单地复制磁盘时，我有一个LogicCube，但有时我需要从磁盘转到Drobo或相反。我在想，考虑到我可以在7小时内使用LogicCube扇区复制一个3/4的完整2TB驱动器，我应该能够使用Assembly接近这一点，但我不知道这是否有效。(是的，有时无知是福)

我需要加快速度的原因是我有两三个周期，在复制过程中发生了一些事情(50小时对于期望世界静止不动来说是一个很长的时间)，这导致我不得不丢弃副本并重新开始。例如，上个星期，自来水总管在我们大楼下面破裂，导致电力短路。

感谢您的早期回复，但我不认为这是I/O限制。我没有通过网络，硬盘是通过sata连接到我的主板上的，而我的Drobo是通过Firewire端口连接的，我的想法是这两个连接都应该允许更快的传输。

实际上，我不能使用扇区复制，除非从单个磁盘到Drobo。它不会以另一种方式工作，因为Drobo文件结构是一个谜。我的非科学观察是，从一个内部磁盘复制到另一个磁盘的速度并不比从Drobo复制到内部磁盘的速度快。

我受到硬件的限制，我买不起10K rpm 2 if的硬盘(如果他们制造的话)。

你们中的一些人正在建议一种文件同步解决方案。但这并不能解决我的问题。首先，我使用过的文件同步解决方案首先构建了数据的地图(因为没有更好的术语)，我有太多的小文件，所以它们卡住了。我使用RICHCOPY的原因之一是它立即开始复制，它不使用内存来构建映射。其次，几周前，我的三个Drobo备份中有一个失败了。我的规则是，如果我有一个备份失败，其他两个必须保持离线，直到新的备份构建完成。因此，我需要从我在LogicCube上使用的三个备份单驱动器副本中的一个进行复制。

在一天结束时，我必须在一个驱动器上有一个好的副本，因为这是我交付给客户的。因为我的客户有不同的系统，所以我通过SATA驱动器交付给他们。

我从别人那里租了一些云空间，在那里我的数据也被存储为最深的备份，但从那里取出的成本很高。

Answer 1

正如其他答案所提到的(+1表示)，在复制文件时，磁盘i/o是瓶颈。你使用的语言不会有太大的不同。你如何布局你的文件将会有所不同，你如何传输数据也会有所不同。

你提到复制到DROBO上。你的DROBO是如何连接的？看看这个graph of connection speeds。

让我们来看看在某些线路类型上可以获得的最大复制速率：

• USB = 97天(1.5 TB / 1.5 Mbps)。差劲，至少你的表现没那么差。
• USB2.0=~7小时(1.5 TB / 480 Mbps)。也许LogicCube?
• Fast SCSI = ~40hrs (1.5 TB / 80 Mbps)。也许是你的硬盘速度吧？
• 100Mbps以太网= 1.4天(1.5 TB / 100 Mbps).

因此，根据你的问题的限制，你可能不能做得更好。但您可能想要开始执行原始磁盘复制(如Unix's dd，它应该比文件系统级复制快得多)(它更快，因为没有对目录遍历或碎片文件的随机磁盘寻道)。

要使用dd，您可以将linux实时引导到您的机器上(或者使用cygwin?)。参见this page for reference或this one about backing up from windows using a live-boot of Ubuntu。

如果您打算在RAID上组织1.5TB的数据，您可能会加快复制速度(因为磁盘将并行读取)，并且(取决于配置)还可以保护您免受驱动器故障的影响。

Answer 2

复制文件是一个受I/O限制的过程。在汇编语言中重写它不太可能提高速度，甚至多线程也可能会导致速度变慢，因为不同的线程同时请求不同的文件会导致更多的磁盘寻道。

使用标准工具可能是最好的方法。如果有任何需要优化的地方，您可能需要考虑更改文件系统或硬件。

Answer 3

有两个地方可以放慢速度：

• 的每个文件拷贝比磁盘拷贝慢得多(在磁盘拷贝中，您可以100%克隆每个扇区的数据)。尤其是对于20 for的文件。除非您从克隆文件切换到克隆原始磁盘数据，否则您无法使用调优最多的程序集来修复这个问题。在后一种情况下，是的，汇编确实是您的门票(或者在C).
• Simply中存储20 In文件并递归查找它们的效率可能较低。但这更有可能是为了找到更好的算法，而且不太可能通过汇编得到显着改进。另外，这不会是50小时

的主要贡献者。

概要-如果您执行原始磁盘扇区复制，程序集将有所帮助，但如果您执行文件系统级复制，则不会有所帮助。