☰

文件如何拥有大小（根据 Nemo），但不占用磁盘空间（在 RAM 中）？

tag-icon • tag-icon linux filesystems
文件如何拥有大小（根据 Nemo），但不占用磁盘空间（在 RAM 中）？

今天我下载了几个文件。 AFAIK 应用程序从一开始就为整个文件保留空间。对于第一个和第二个文件，我看到下载开始后可用 RAM 减少，但对于第三个文件，没有足够的空间（每条消息），我删除了一些文件并开始下载。但令我惊讶的是，free仍然显示出很大的可用空间。我检查了文件的大小，认为应用程序可能只保留了部分空间来启动，但事实并非如此，文件大小已满了几个 GB，如 Nemo 中所示。我以为可能是我不小心删除了超出预期的内容，但下载后free显示几乎没有可用内存。文件系统如何报告相当大的对象（文件），但不占用空间？

该系统基于 Ubuntu liveUSB，启动到 RAM，findmnt因为/说cow，因此我犹豫是否要调用它，tmpfs因为我不太了解启动脚本（并且也不知道该问题应用哪些标签）。如果需要确定原因，我可以尝试在纯 tmpfs 驱动器上重现该问题。哦，我的问题 - 如果来自各种 Linux 实用程序的信息相互矛盾，我如何才能信任这些信息？

答案1

文件的表观大小不一定与它们在磁盘上实际占用的空间相同：

$ truncate -s 10P hugefile
$ ls -l hugefile
-rw-rw-r--. 1 skitt skitt 11258999068426240 Jan  7 11:49 hugefile

我实际上没有 10PiB 磁盘，幸好hugefile不占用 10PiB：

$ stat hugefile
  File: hugefile
  Size: 11258999068426240   Blocks: 0          IO Block: 4096   regular file
Device: fd02h/64770d    Inode: 182589989   Links: 1
Access: (0664/-rw-rw-r--)  Uid: (26561/   skitt)   Gid: (26561/   skitt)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2022-01-07 11:49:26.653101365 +0100
Modify: 2022-01-07 11:49:34.631215761 +0100
Change: 2022-01-07 11:49:34.631215761 +0100
 Birth: 2022-01-07 11:49:26.653101365 +0100

这里重要的字段是块数，0。

此类文件称为稀疏文件。

许多下载工具在提前知道文件的最终大小时都是这样操作的：它们将给出文件的完整大小，使文件的表观大小始终等于其最终“实际”大小，然后在收到文件内容时写入文件，逐步分配磁盘空间。这就是你所看到的。

相关内容