请随意编辑标题以更好地解释我在这里要写的内容。
例如，当我将大文件复制到 U 盘时，进度窗口会显示一个估计值，大多数情况下不会显示实际完成时间和百分比，但有时它会显示所有操作都已完成，进度窗口会关闭。我去提取 U 盘，它显示它仍在使用中。检查 U 盘后，我发现它仍在复制文件，但没有进度窗口显示这一点。
这不仅发生在大文件上，也发生在许多小文件上。如果我复制它们，进度条可能会显示 15 秒，并在该时间内完成，但实际时间可能是 1 分钟，在接下来的 45 秒内，我需要实际查看 U 盘中的指示灯，以查看其中是否有实际活动。
我不想知道如何修复它，因为我已经读过修复这个问题需要多深。我想知道的是为什么进度窗口显示的估计值与复制过程不符。
它是否依赖于外部单元中的缓存？
文件大小和文件数量是否会影响正确估算。例如 1 个 4 GB 的文件或 1000 个 4 MB 的文件。
是否有可以改变行为的配置选项。
还有其他类似的问题，例如将文件复制到 USB 驱动器从未完成但我更关注的是其机制以及为什么它会表现得如此。
答案1
我猜你正在使用 Nautilus 作为文件管理器，如果是这样的话，这方面存在长期存在的错误。太神秘了，更不用说影响 Mint、Fedora、Red Hat 和所有类似产品了。Ubuntu 也存在同样的问题。
有人建议关闭缩略图视图会有所帮助。其他人则将希望寄托在“最新内核”上，但这仍然存在。
问题 = 开始时很快，然后变慢，这是因为当使用异步安装时它会写入缓存，当缓存已满时，您会看到“真实”写入速度。
解决方法似乎是sudo cp /filetobecopied /dev/nameofdevice
其他发布在这里表示“分块复制”有效。我尚未确认。
答案2
这也是一个很好的答案，并给出了解决方案： https://unix.stackexchange.com/a/181236 它说：
之所以会发生这种情况，是因为程序说“写入此数据”，然后 Linux 内核将其复制到排队等待写入磁盘的内存缓冲区中，然后说“好的，完成”。因此程序认为它已复制了所有内容。然后程序关闭文件，但内核突然让它等待，直到缓冲区被推送到磁盘。
因此，不幸的是，程序无法告诉您刷新缓冲区需要多长时间，因为它不知道。
如果您想尝试一些高级用户技巧，您可以通过将 /proc/sys/vm/dirty_bytes 设置为 15728640 (15 MB) 之类的值来减少 Linux 使用的缓冲区大小。这意味着应用程序不能比其实际进度提前 15MB 以上。
副作用是，使用此设置可能会降低计算机的数据写入吞吐量，但总体而言，我发现这有助于了解程序在写入大量数据的同时运行了多长时间，而不是出现程序似乎已完成其工作但系统严重滞后而内核实际工作的情况。将 dirty_bytes 设置为一个合理的小值还有助于防止系统在可用内存不足并运行突然写入大量数据的程序时变得无响应。
但是，不要设置得太小！我使用 15MB 作为粗略估计，内核可以在 1/4 秒或更短的时间内将缓冲区刷新到普通硬盘。它让我的系统不会感觉“滞后”。