我有一个tar存档(17GB),它包含许多小文件(所有文件都<1MB).
我如何使用此存档.
>我提取它吗？在我的笔记本电脑上使用7-zip说需要20小时(而且我认为需要更多时间)
>我可以在不提取文件的情况下阅读/浏览文件的内容吗？如果是,那怎么样？
>还有其他选择吗？
它实际上是一个处理过的*数据集,我应该在其上执行一些自然语言处理.
平台Windows / Linux不是问题;只要能尽快完成工作,任何事都可以.
解决方法:
我想你有一台Linux笔记本电脑或台式机,你的hugearchive.tgz文件放在一些本地磁盘上(不是远程网络文件系统,这可能太慢了).如果可能的话,将hugearchive.tgz文件放在某个快速磁盘(最好是SSD,而不是磁性旋转硬盘)和快速Linux本机文件系统(Ext4,XFS,BTRFS,而不是FAT32或NTFS)上.
请注意,.tgz文件是.tar文件的gnu-zipped压缩.
下次获得一个大型存档时,请考虑以afio存档格式询问它,这样可以单独压缩不太小的文件(或者可能要求一些SQL转储 – 例如PostGreSQL或Sqlite或MariaDB – 压缩形式).
首先,您应该在该hugearchive.tgz gziped tar存档中列出文件名,并询问总字节数：
tar -tzv --totals -f hugearchive.tgz > /tmp/hugearchive-list.txt
该命令将运行gunzip以将.tgz文件解压缩到某个管道(因此不会消耗大量磁盘空间)并将目录写入/tmp/hugearchive-list.txt并且您将获得stderr之类的东西
Total bytes read: 340048000 (331MiB, 169MiB/s)
当然这些数字是虚构的,你会得到更大的数字.但是你会知道存档的总累积大小是多少,你就会知道它的目录.使用wc -l /tmp/hugearchive-list.txt获取该内容表中的行数,即存档中的文件数,除非某些文件被奇怪地和恶意地命名(例如文件名中有一些换行符) ,这可能但很奇怪).
我的猜测是,你将在不到一个小时的时间内处理你的庞大档案.细节取决于计算机,尤其是硬件(如果你能负担得起,使用一些SSD,并获得至少8GB的RAM).
然后您可以决定是否能够提取所有文件,因为您知道他们需要多少总大小.由于您拥有/tmp/hugearchive-list.txt中的目录,因此您可以轻松地提取有用的文件(如果需要).
值得一提的是,我的i3770K台式机配备16Gb RAM以及SSD和DSP.磁盘存储,我做了(用于试验)一个无用的大型存档(专门用于回答这个问题的目的,因为我没有你的hugearchive.tgz文件….)
sudo time tar czf /tmp/hugefile.tgz /bin /usr/bin /usr/local/bin /var
并且花了这个时间来创建该存档(在SSD上具有所有这些文件系统)：
719.63s user 60.44s system 102% cpu 12:40.87 total
并且生成的/tmp/hugefile.tgz有5.4千兆字节(注意它可能位于page cache).
然后我尝试了：
time tar -tzv --totals -f /tmp/hugefile.tgz > /tmp/hugefile-list.txt
得到了：
Total bytes read: 116505825280 (109GiB, 277MiB/s)
tar -tzv --totals -f /tmp/hugefile.tgz > /tmp/hugefile-list.txt
395.77s user 26.06s system 104% cpu 6:42.43 total
并且生成的/tmp/hugefile-list.txt有2.3Mbytes(23Kfiles),没什么大不了的.
如果您的tar存档不是GNU zip,请不要在tar命令中使用z.
阅读tar(1)(以及time(1),如果你使用它,更常见的是你正在使用的每个命令！)的文档,当然还使用命令行(不是一些GUI界面),也是learn一些shell脚本.
顺便说一句,你以后可以隔离非常小的文件(小于64K字节),例如把它们放在一些数据库(可能是一些Sqlite或Redis或PostGreSQL或MongoDB数据库,填充例如一个小脚本)或可能是一些GDBM索引文件.请注意,大多数文件系统对于大量小文件都有一些显着的开销.
学习shell脚本和一些脚本语言(Python,Lua,Guile,Ocaml,Common Lisp)和基本的数据库技术并不是浪费时间.如果是你正在开始攻读博士学位,这几乎是一项必修的技能.
我不知道也不使用(并且不喜欢)Windows,所以我显然有偏见(我的第一个Linux是一些Slackware,大约在1993年或1994年初的0.99.12内核),但我强烈建议你做所有的NLP在Linux上的工作(并且只在你有时间的时候保持Windows只用于播放视频游戏),因为在Linux上编写和组合许多有用的现有free software非常容易.