为什么在 ext4 分区内移动文件这么慢?

为什么在 ext4 分区内移动文件这么慢?

简单的问题是,为什么在同一个 ext4 分区内移动的移动操作比从不同驱动器复制相同文件花费的时间更长?

该场景的较长描述:我最近移动了一个大目录的文件...我没有确切的数字,但也许 40-50GB 的数据主要由许多目录中的小文件组成(嵌套 10 层深将并不少见)。我使用 rsync 将其从 USB 拇指驱动器 (NTFS) 移动到内部硬盘(ext4 分区),虽然我没有计时,但我在睡觉前将其启动,并在起床前完成。所以可能不会超过 8 小时,甚至可能更短。

但是我错误地像这样重新同步了它(不是真正的目录名称)

rsync -a /thumbdrive/a/b/c /harddrive/a/b/c

这样我就得到了一个额外的c目录。

因此,我通过将第二个c向上移动一个级别来纠正此问题(复制较高级别的c,除了内部 之外,该级别是空的c)。我认为这应该是一个微不足道的操作,因此在 Dophin 中(在 KDE 桌面中)进行了操作。现在它已经运行了大约 9 或 10 个小时,并且仍在继续......

附录:还有一点可能很重要的信息:该c文件夹包含 51 个文件夹和 62 个文件。 (我希望 Dolphin 本质上会对每个操作进行 mv 操作。)

附录 2:一段时间后,我注意到进度(显示在 KDE 通知托盘等离子体中)似乎停滞了。硬盘指示灯仍然继续活跃,但进度指示器继续显示继续位于同一文件上。之前情况并非如此,当我已经想知道为什么花了这么长时间时,我定期检查并看到不同文件的生动进展)。看着盘面,我发现移动的源头似乎已经不存在了。我最终放弃了并点击了通知用户界面中的停止按钮。

我意识到这可能更多地表明 KDE 的怪异程度超过了 ext4 的怪异程度,而且至少 KDE 的层层让人很难知道发生的怪异现象是否与文件系统相关。但是,我认为有用的答案是了解 ext4 内部的人确认或否认 ext4 的此类行为有任何意义,或者了解相关 KDE 位并解释这种情况如何发生的人。

相关内容