如果我tar -cvf在大小为 937MB 的目录上运行来创建深度嵌套文件夹结构的可轻松下载的副本，那么在给出以下输出的情况下，我是否会冒填满磁盘的风险df -h：
/dev/xvda1 7.9G 3.6G 4.3G 46% /
tmpfs 298M 0 298M 0% /dev/shm
相关问题：
- 如果磁盘可能已满，为什么 Linux (Amazon AMI) 和/或
tar在幕后会做什么？ - 我怎样才能准确地自己确定这些信息而不需要再次询问？
答案1
tar -c data_dir | wc -c
无压缩
或者
tar -cz data_dir | wc -c
使用 gzip 压缩
或者
tar -cj data_dir | wc -c
使用 bzip2 压缩
将打印将创建的存档的大小（以字节为单位），而不写入磁盘。然后，您可以将其与目标设备上的可用空间量进行比较。
您可以使用以下命令检查数据目录本身的大小，以防对其大小做出错误的假设：
du -h --max-depth=1 data_dir
正如已经回答的那样，tar 为存档中的每个记录添加一个标头，并将每个记录的大小四舍五入为 512 字节的倍数（默认情况下）。档案的结尾由至少两个连续的零填充记录标记。因此，未压缩的 tar 文件总是比文件本身大，文件的数量以及它们与 512 字节边界的对齐方式决定了所使用的额外空间。
当然，文件系统本身使用的块大小可能大于单个文件的内容，因此在解压文件时要小心，文件系统可能无法容纳大量小文件，即使它的可用空间大于 tar 大小！
https://en.wikipedia.org/wiki/Tar_(computing)#Format_details
答案2
tar 文件的大小将为 937MB 加上每个文件或目录所需的元数据大小（每个对象 512 字节），并添加填充以使文件与 512 字节边界对齐。
非常粗略的计算告诉我们，您的数据的另一个副本将为您留下 3.4GB 的可用空间。在 3.4GB 中，假设没有填充，我们有大约 700 万条元数据记录的空间；如果假设每个文件平均有 256 字节的填充，则空间会更少。因此，如果您有数百万个文件和目录需要 tar，您可能会遇到问题。
您可以通过以下方式缓解问题
z使用或j选项进行动态压缩tar- 以普通用户身份执行此操作
tar，以便/在空间不足时不会触及分区上的保留空间。
答案3
我对此做了很多研究。您可以使用字数统计对该文件进行测试，但它不会为您提供与du -sb adir.
tar -tvOf afile.tar | wc -c
du将每个目录计为 4096 字节，tar将目录计为 0 字节。您必须将 4096 添加到每个目录：
$(( $(tar -tvOf afile.tar 2>&1 | grep '^d' | wc -l) * 4096)))
那么你必须添加所有的字符。对于看起来像这样的东西：
$(( $(tar -tvOf afile.tar 2>&1 | grep '^d' | wc -l) * 4096 + $(tar -xOf afile.tar | wc -c) ))
我不确定这是否完美，因为我没有尝试已触及的文件（0 字节的文件）或具有 1 个字符的文件。这应该会让你们更接近。
答案4
-cvf不包括任何压缩，因此在 ~1 GB 文件夹上执行此操作将生成 ~1 GB tar 文件（Flub 的答案提供了有关 tar 文件中额外大小的更多详细信息，但请注意，即使有 10,000 个文件，这也只是5 MB）。由于您有 4+ GB 可用空间，因此您不会填满该分区。
易于下载的副本
大多数人会认为“更容易”在下载方面与“更小”同义，因此您应该在这里使用一些压缩。 bzip2我认为现在应该可以在任何带有 tar 的系统上使用，所以包含j在您的交换机中可能是最好的选择。 z( gzip) 可能更常见，并且还有其他（不太普遍的）可能性，具有更多的挤压。
如果您的意思是，tar在执行任务时确实暂时使用额外的磁盘空间，我很确定它不会，原因有几个，一是它可以追溯到磁带驱动器作为主存储的一种形式的时代，二是它有已经有几十年的发展时间（而且我确信没有必要使用临时中间空间，即使涉及压缩）。