为什么 64 MB 闪存可以达到 3048 MB？

Question 1

至少有 3 个不同的原因可以解释为什么您传输的数据多于 STB 上可能存储的数据：

稀疏文件：文件似乎始终包含从时间开始到文件当前长度的连续字节序列。但是您可以创建一个（通常是二进制）文件并仅写入某些字节范围。在这种情况下，这些字节范围之间的空洞（从未被写入）在读取时似乎包含 0 值字节。文件系统通常会注意到软件何时创建这些“漏洞”，但实际上并不将这些漏洞存储在磁盘上。这样，您可以创建一个 1000000 字节的文件，在 999999 位置写入单个字节，注意该文件的大小几乎是 1 MB，但只占用单个块磁盘空间。

如果文件格式要求文件的某些部分位于某些字节偏移处但并非所有内容都被填充，则某些类型的数据库或索引文件通常可能是稀疏的。

文件复制器无法判断文件在起始位置是稀疏的，因此它们只是从源读取整个文件作为字节流，并将相同的字节流写入目标。由于文件的每个字节都写入目标，因此目标的文件系统不会创建稀疏文件。

如果您怀疑数据集中的稀疏文件导致其大小增加，请尝试--sparse以下选项同步。每当源中存在大量 0 值字节时，它就会机会性地在目标上创建稀疏文件。（它无法判断源文件是实际上稀疏，只是可能稀疏，但无论如何它都会使其在目的地上稀疏。）

您的 STB 可能包含某种内部数据库，可以使用一个或多个稀疏文件来实现。在源文件系统上查找非常大的文件，特别是大于 STB 上存储量的文件。那些有变得稀疏。
物品安装在多个地方。像 STB 这样的嵌入式系统通常具有奇怪的文件系统布局，因为它们可能混合了只读和读写分区，这些分区分别是制造商软件分发和用户数据的一部分，设计用于不同类型的文件系统在原始闪存（不是块设备）、引导加载程序分区、允许非常轻松地实现恢复出厂设置功能的联合安装文件系统、ramdisk（以便在断电情况下正常运行而不会损坏文件系统）等...因此，实际的内容相同可能会安装在几个不同的独立位置（例如，以工厂原始形式、作为联合安装、用于其他目的的绑定安装...）

为了解决这个问题，该df命令可能会有所帮助，尽管一些嵌入式系统制造商所做的事情非常奇怪，以至于可能不清楚输出中正在做什么df。但您至少应该能够看到存在哪些文件系统以及每个文件系统的完整程度。
硬链接：FTP 不识别硬链接，所以如果你要求它复制两个链接到同一个文件，它会复制该文件两次，并且会占用目标端两倍的空间。如果文件有超过 2 个链接，则相应地相乘。

为了帮助解决这个问题，请尝试 rsync 的--hard-links选项。

请注意，在三分之二的情况下，我建议您使用 rsync 来复制文件。仅当您具有对 STB 的 shell 访问权限并且安装了 rsync（或者您可以安装它），或者 STB 提供 rsync 作为文件传输协议（STB 可能不提供，但某些家用 NAS 设备）时，这才有可能使用 do)。

如果您可以使用它，rsync 是将大量数据从一个系统复制到另一个系统的好方法。它不仅可以选择解决上述三个问题中的两个（或者可能全部三个？请参阅--one-file-system），而且对于恢复中断的复制非常方便。

Answer

至少有 3 个不同的原因可以解释为什么您传输的数据多于 STB 上可能存储的数据：

稀疏文件：文件似乎始终包含从时间开始到文件当前长度的连续字节序列。但是您可以创建一个（通常是二进制）文件并仅写入某些字节范围。在这种情况下，这些字节范围之间的空洞（从未被写入）在读取时似乎包含 0 值字节。文件系统通常会注意到软件何时创建这些“漏洞”，但实际上并不将这些漏洞存储在磁盘上。这样，您可以创建一个 1000000 字节的文件，在 999999 位置写入单个字节，注意该文件的大小几乎是 1 MB，但只占用单个块磁盘空间。

如果文件格式要求文件的某些部分位于某些字节偏移处但并非所有内容都被填充，则某些类型的数据库或索引文件通常可能是稀疏的。

文件复制器无法判断文件在起始位置是稀疏的，因此它们只是从源读取整个文件作为字节流，并将相同的字节流写入目标。由于文件的每个字节都写入目标，因此目标的文件系统不会创建稀疏文件。

如果您怀疑数据集中的稀疏文件导致其大小增加，请尝试--sparse以下选项同步。每当源中存在大量 0 值字节时，它就会机会性地在目标上创建稀疏文件。（它无法判断源文件是实际上稀疏，只是可能稀疏，但无论如何它都会使其在目的地上稀疏。）

您的 STB 可能包含某种内部数据库，可以使用一个或多个稀疏文件来实现。在源文件系统上查找非常大的文件，特别是大于 STB 上存储量的文件。那些有变得稀疏。
物品安装在多个地方。像 STB 这样的嵌入式系统通常具有奇怪的文件系统布局，因为它们可能混合了只读和读写分区，这些分区分别是制造商软件分发和用户数据的一部分，设计用于不同类型的文件系统在原始闪存（不是块设备）、引导加载程序分区、允许非常轻松地实现恢复出厂设置功能的联合安装文件系统、ramdisk（以便在断电情况下正常运行而不会损坏文件系统）等...因此，实际的内容相同可能会安装在几个不同的独立位置（例如，以工厂原始形式、作为联合安装、用于其他目的的绑定安装...）

为了解决这个问题，该df命令可能会有所帮助，尽管一些嵌入式系统制造商所做的事情非常奇怪，以至于可能不清楚输出中正在做什么df。但您至少应该能够看到存在哪些文件系统以及每个文件系统的完整程度。
硬链接：FTP 不识别硬链接，所以如果你要求它复制两个链接到同一个文件，它会复制该文件两次，并且会占用目标端两倍的空间。如果文件有超过 2 个链接，则相应地相乘。

为了帮助解决这个问题，请尝试 rsync 的--hard-links选项。

请注意，在三分之二的情况下，我建议您使用 rsync 来复制文件。仅当您具有对 STB 的 shell 访问权限并且安装了 rsync（或者您可以安装它），或者 STB 提供 rsync 作为文件传输协议（STB 可能不提供，但某些家用 NAS 设备）时，这才有可能使用 do)。

如果您可以使用它，rsync 是将大量数据从一个系统复制到另一个系统的好方法。它不仅可以选择解决上述三个问题中的两个（或者可能全部三个？请参阅--one-file-system），而且对于恢复中断的复制非常方便。

Question 2

在Windows方面，您不仅复制了c:驱动器，还复制了各种不是磁盘文件而是硬件设备的文件，并且您多次复制了某些文件。可能包括整个磁盘内容和 RAM 的转储多次。

在 Linux 和其他类 UNIX 系统上，几乎所有内容都是文件。除了常规的文件和目录之外，还有符号链接（指向其他文件的指针）和设备文件代表硬件设备（磁盘、分区、RAM、串行端口等）。还有一些特殊的文件系统，它们不存储在磁盘上，但允许应用程序访问有关系统的数据：/proc（过程）和/sys（系统文件系统）。

在的设备中/dev，甚至还有无穷文件——您可以永远阅读的文件。有/dev/zero，它包含您想要从中读取的任意数量的空字节。还有/dev/urandom，它包含您想从中读取的任意数量的随机字节 - 因此要获得 n 个随机字节，您可以从中读取 n 个字节/dev/urandom。

如果您使用 FTP 程序传输整个文件系统树，它会复制所有内容，并且可能复制可以从获得的大量内容/proc，或更可能复制从获得的无限量数据/dev。

进一步阅读：

如果您有除 FTP 之外的其他方式连接到该设备，例如 SSH 命令行，请使用它来代替 FTP，因为 FTP 不知道特殊文件。运行命令df以查看存在哪些文件系统。您可以使用以下命令备份根文件系统

rsync -a -x root@settopbox:/ settopbox.backup

（注意告诉-x选项同步程序不跨文件系统。）

根文件系统可能不是值得备份的系统，某些设备设置了只读根文件系统和包含设置的不同读写文件系统。发布命令的输出df，以及mount您是否需要帮助确定要备份哪些命令。

或者，备份闪存本身。您必须找到设备名称。尝试以下命令来查找块设备，即对应于磁盘或磁盘分区或其他类似设备的设备：

find /dev -type b
ls -l /dev /dev/* | grep '^b'

如果您不确定这些设备的含义，请发布这些命令的输出。

Answer