首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >cpio VS tar和cp

cpio VS tar和cp
EN

Stack Overflow用户
提问于 2010-06-03 13:33:17
回答 2查看 16.8K关注 0票数 14

我刚了解到cpio有三种模式:复制、复制和传递。

我想知道在复制模式和复制模式下,cpio与tar相比有什么优缺点。什么时候使用cpio更好,什么时候使用焦油?

同样的问题对cpio在传递模式下对cp。

谢谢和问候!

EN

回答 2

Stack Overflow用户

发布于 2016-01-04 12:30:28

TAR(1)与cpio()一样好,如果不是更好的话。人们可以说,它实际上比CPIO好,因为它无处不在并经过审查。我们到处都有焦油球一定有原因。

票数 -1
EN

Stack Overflow用户

发布于 2010-11-27 18:29:48

为什么cpio比焦油好?有几个原因。

  1. cpio保留硬链接,如果您将其用于备份,则这一点非常重要。
  2. cpio没有那个烦人的文件名长度限制。当然,gnutar有一个"hack“,它允许您使用更长的文件名(它创建一个临时文件,其中存储真名),但它本质上不能移植到非gnu tar文件。
  3. 默认情况下,cpio保留时间戳。
  4. 在编写脚本时,它可以更好地控制要复制和不复制的文件,因为您必须显式列出要复制的文件。例如,下列哪一项更容易阅读和理解? 找出来。-type f -name '*.sh‘-print cpio -o _ gzip >sh.cpio.gz 或者在Solaris上: 找出来。-type f -name '*.sh‘-print >/tmp/-print-.-I /tmp/includeme gzip >sh.tar.gz 或与侏儒: 找出来。-type f -name '*.sh‘-print >/tmp/-print-.-from=/tmp/includeme/ gzip >sh.tar.gz 这里有几个特别的注意事项:对于大型文件列表,不能在反向引号中找到;命令行长度将超出;必须使用中间文件。单独的find和tar命令本身是比较慢的,因为这些操作是连续执行的。 考虑这个更复杂的情况,您希望树完全打包,但是在一个tar中有一些文件,而另一个tar中有剩余的文件。 找出来。-depth -print >/tmp/files egrep '.sh$‘/tmp/files cpio -o \ gzip >with.cpio.gz egrep -v '.sh$’/tmp/files cpio -o _ gzip >without.cpio.gz 或在Solaris下: 找出来。-depth -print >/tmp/files '.sh$‘/tmp/file >/tmp/with -cf -。-I /tmp/with _ gzip >with.tar.gz tar -cf -。/tmp/不含gzip >without.tar.gz ## ^^-不,这里没有缺少参数。只是那边空了 或与侏儒: 找出来。-depth -print >/tmp/files '.sh$‘/tmp/file >/tmp/with -cf -。-I /tmp/with _ gzip >with.tar.gz tar -cf -。-X /tmp/不含gzip >without.tar.gz 同样,一些注意事项:单独的find和tar命令本来就比较慢。创建更多的中间文件会造成更多的混乱。gnutar感觉有点干净,但是命令行选项本质上是不兼容的!
  5. 如果您需要在繁忙的网络中匆忙地将大量文件从一台计算机复制到另一台计算机,您可以并行运行多个cpio。例如: 找出来。-depth -print >/tmp/files拆分/tmp/文件中F的/tmp/文件?;cat $F \ cpio -o -o ssh目的地"cd /target && cpio -idum“& do? 请注意,如果您可以将输入分割成大小相等的部分,则会有所帮助。为此,我创建了一个名为“n管道”的实用程序。N管道将读取stdin中的行,并创建N个输出管道,并在每一行被消耗时将这些行提供给它们。这样,如果第一个条目是一个大文件,需要10分钟才能传输,而剩下的是小文件,需要2分钟才能传输,那么您就不会因为等待大文件和后面排着队的另外12个小文件而陷入停滞。通过这种方式,您可以按需求进行拆分,而不是严格按照文件列表中的行数或字节数进行拆分。使用gnu-xargs的并行分叉功能也可以实现类似的功能,但在命令行中放置参数而不是将它们流到stdin。 找出来。-depth -print >/tmp/files nPIP-4/tmp/file 'cpio -o \ ssh目的地"cd /target && cpio -idum"‘ 这怎么会更快?为什么不使用NFS呢?为什么不使用rsync呢?NFS本身是非常慢的,但更重要的是,任何单个工具的使用都是单线程的。rsync在源树中读取,并每次向目标树写入一个文件。如果您有一台多处理器机器(在我使用16 you的每台机器时),并行写入就变得非常重要。我将8GB树的复制速度降到30分钟,即4.6MB/秒!当然,这听起来很慢,因为100 this网络可以轻松地做到5-10 in /秒,但是inode创建时间使它慢下来;这棵树中很容易有500万个文件。因此,如果inode创建是瓶颈,那么我需要并行化该操作。相比之下,以单线程方式复制文件需要4个小时.快8倍! 这样做速度更快的另一个原因是,并行tcp管道不太容易受到丢失数据包的攻击。如果一个管道因为丢了一个包而停顿,其他的通常不会受到影响。我不太确定这有多大的区别,但是对于多线程内核来说,这可以再次提高效率,因为工作负载可以分布在所有那些空闲cpu上。

在我的经验中,cpio比tar做得更好,而且具有更多的参数可移植性(参数在cpio的不同版本之间不会改变!),尽管在某些系统上可能找不到它(在RedHat上没有默认安装),但是Solaris在默认情况下也不附带gzip。

票数 -5
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/2966409

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档