Sam*_*mir 4 linux filesystems disk-usage directory-structure files
我有一个基于 Linux 的 STB（机顶盒），它具有 64 MB 闪存和 256 MB RAM。我想先备份我的一些设置，然后再用另一个图像刷它，但我不确定它们的确切位置。我想我以后会研究这个。所以我决定通过 FTP 连接到盒子并下载所有文件和文件夹。在 FTP 客户端中，我右键单击该框的根目录并选择将其下载到 Windows 桌面上的专用文件夹中。
下载一直在继续，似乎永远不会停止......但是FTP连接被FTP服务器终止（我认为它在日志中说）。我最终得到了 2.97 GB 的数据。这怎么可能？所有这些数据从哪里来？......它最多不能容纳超过 256 MB？！......
为什么你不能直接复制 Linux 机器的根目录，然后期望所有其他文件和文件夹都跟着呢？和在 Windows 上复制 C:\ 不一样吗？是因为它是一个实时系统吗？...也许我必须先关闭它或注销并停止进程？当时就在待机...
至少有 3 种不同的事情可以解释为什么您传输的数据比可能存储在 STB 上的数据多：
稀疏文件：文件似乎总是包含从时间开始到文件当前长度的连续字节序列。但是您可以创建一个（通常是二进制）文件并且只写入特定的字节范围。在这种情况下，这些字节范围（从未被写入）之间的空洞在读取时似乎包含 0 值字节。文件系统通常会注意到软件何时创建了这些“漏洞”，并且实际上并不将这些漏洞存储在磁盘上。这样就可以创建一个1000000字节的文件，在999999位置写入一个字节，注意这个文件差不多有1兆字节，但是只占用了一块磁盘空间。
某些类型的数据库或索引文件通常可能是稀疏的，如果文件格式要求文件的某些部分位于某些字节偏移处，但并非所有内容都被填充。
文件复制器无法判断文件在起始位置是稀疏的，因此它们只是将整个文件作为来自源的字节流读取，并将相同的字节流写入目标。由于文件的每个字节都写入目标，因此目标的文件系统不会创建稀疏文件。
如果您怀疑数据集中的稀疏文件导致其大小增加，请尝试rsync--sparse选项。只要源中有大量 0 值字节，它就会在目标上机会性地创建稀疏文件。（它无法判断源文件实际上是稀疏的，只是可能稀疏，但无论如何它都会使其在目标上变得稀疏。）
您的 STB 可能包含某种内部数据库，可以使用一个或多个稀疏文件来实现。在源文件系统上查找非常大的文件，特别是大于 STB 上存储量的文件。那些必须是稀疏的。
东西装在不止一处。像机顶盒这样的嵌入式系统通常有一个奇怪的文件系统布局，因为它们可能混合了只读和读写分区，它们分别是制造商软件分发和用户数据的一部分，设计用于不同类型的文件系统在原始闪存（不是块设备）、引导加载程序分区、联合安装的文件系统上，可以非常轻松地实现出厂重置功能、ramdisk 以便在断电的情况下正常生存而不会损坏文件系统等......因此，实际相同的内容可能会出现在几个不同的独立位置（例如，以工厂原始形式，作为联合安装，绑定安装用于其他目的......）
要破解这个难题，该df命令可能会有所帮助，尽管一些嵌入式系统制造商会做一些非常奇怪的事情，以至于可能不清楚df输出中的内容。但是您至少应该能够看到存在哪些文件系统以及它们中的每一个有多满。
硬链接：FTP 不识别硬链接，因此如果您要求它将两个链接复制到同一个文件，它将复制该文件两次，并且在目标端占用两倍的空间。如果文件有 2 个以上的链接，则相应地相乘。
为了帮助解决这个问题，请尝试 rsync 的--hard-links选项。
请注意，在三分之二的情况下，我建议您使用 rsync 复制文件。这只有在您对 STB 具有 shell 访问权限并且安装了 rsync（或者您可以安装它），或者如果 STB 提供 rsync 作为文件传输协议（STB 可能没有，但一些 NAS 设备出售给家庭）时才有可能用做）。
如果您可以使用它，rsync 是将大量数据从一个系统复制到另一个系统的好方法。它不仅可以解决上面提到的三个问题中的两个（或者可能是全部 3 个？看看--one-file-system），而且它对于恢复中断的副本非常方便。