一个文件怎么能有大小(每个Nemo)，却不占用磁盘上的空间(在RAM中)？

Question

今天我下载了几个文件。应用程序AFAIK从一开始就为整个文件保留了空间。对于第一和第二个文件，我看到可用内存在下载开始后就减少了，但是对于第三个文件，没有足够的空间(每条消息)，我删除了一些并开始下载。但令我惊讶的是，free继续显示出巨大的可用空间。我检查了文件的大小，认为应用程序可能只保留了一部分空间来启动，但是没有，文件大小满了几个GBs，如Nemo所示。我想也许我无意中删除了比预期更多，但下载后free显示几乎没有可用的内存。文件系统如何报告大小对象(文件)，但不占用空间？

该系统基于Ubuntu liveUSB，引导到内存中，findmnt for /表示cow，因此我不太愿意称它为tmpfs，因为我不太清楚启动脚本(也不确定哪些标记适用于这个问题)。如果找出原因很重要，我可以尝试在纯tmpfs驱动器上重复这个问题。哦，我的问题--如果信息相互矛盾，我怎么能相信来自各种Linux工具的信息呢？

Answer 1

文件的表面大小不一定与它们在磁盘上所占的空间相同：

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

我实际上没有10 don磁盘，谢天谢地，hugefile没有占用10 don：

$ 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。

这类文件称为稀疏文件。

当许多下载工具提前知道文件的最终大小时，它们就会这样操作:它们将使文件具有完整的大小，使文件的明显大小始终与其最终的“真实”大小相等，然后在接收到文件内容时写入文件，并逐步在磁盘上分配空间。这就是你看到的。