为啥在 NAS 上“移动目录”需要这么长时间?

Posted

技术标签:

【中文标题】为啥在 NAS 上“移动目录”需要这么长时间?【英文标题】:Why does "move directories" on a NAS take so long?为什么在 NAS 上“移动目录”需要这么长时间? 【发布时间】:2015-01-15 06:20:25 【问题描述】:

我很不确定客户端和 NAS 场景中的 move files/directories use case 在技术上是如何工作的 - 也许有人可以启发我或告诉我这是否是正常的操作系统行为。

我在千兆位 LAN 中有一个 NAS ( Synology DiskStation ),有时我想将其移动到同一 NAS 上的其他位置(甚至在同一个硬盘上)的大目录(在 ~ 10GB 的范围内)。

问题是,如果我从假设中移动目录

//diskstation:/dir_foo/dir_1/src_1

//diskstation:/dir_foo/dir_2/

通过我在资源管理器中的 Windows 7 台式电脑(我什至在 MacBook 上的 Finder 中尝试过),这可能需要 10 分钟(或类似时间),我真的很想知道为什么会这样。 对我来说,这似乎是整个数据首先通过 LAN 传输到我的客户端 PC,然后再移回 NAS!?

资源管理器或 NAS 不应该注意到这是本地文件操作,因此数据不必通过我的 LAN 传输,电影应该更快吗? 如何分析文件移动是否真的通过 LAN 执行?因为如果我想从外部通过 *** 进行此类操作,那将几乎无法使用...... 这是正常行为吗?

【问题讨论】:

【参考方案1】:

很难给出一个肯定的答案,因为这取决于。您正在使用什么访问协议,您正在执行什么操作?它是您 GUI 中的拖放吗?

您的 NAS 会按照指示执行操作。它几乎肯定实现了某种内部重命名功能,这意味着您无需复制数据即可“移动”它。

如果您从命令行执行此操作,使用“move”或“mv”(取决于 DOS/Unix)会遇到同样的问题吗?我准备打赌你不这样做,因为你告诉 NAS 重命名,它会重命名,它会没事的。

【讨论】:

在 Synology DiskStation 上,我为 Windows 和 Mac 激活了 SMB 和 AFP。我在 Windows 资源管理器/Mac Finder 的 GUI 中进行了复制/移动。当然,我也可以在 DiskStation 的网页视图中进行这种文件操作(称为“File Station”)——这里似乎要快得多。这对我来说也是合乎逻辑的,因为我“直接登录到 DiskStation”。但是所有其他用户的正常用例是他们使用各自的客户端(笔记本电脑)。我们还想在 Mac 上使用“Hazel”自动化一些文件操作,这将再次使用 AFP...【参考方案2】:

从 GUI 而不是文件资源管理器中移动它。

【讨论】:

我不知道这是否回答了这个问题,但假设它确实提供了更多细节会很好。例如:如何从 GUI 中移动它?请使用该信息编辑您的答案,否则可能会被否决或关闭。【参考方案3】:

如果您使用 Windows 资源管理器移动文件,那么您的操作系统将首先将文件从源目录下载到客户端 PC,然后将其上传到目标目录,这是因为您使用 SAMBA 共享。

如果您想在 nas 中快速移动文件,那么最好的方法是使用 putty 或 WinSCP,后者使用 ssh 和 ftp 等。

【讨论】:

以上是关于为啥在 NAS 上“移动目录”需要这么长时间?的主要内容,如果未能解决你的问题,请参考以下文章

为啥 H2 DB FileLock.sleep() 需要这么长时间?

为啥我的 gradle 需要这么长时间? > 13 分钟

为啥在 VCC 2003 中编译需要这么长时间?

为啥'withColumn'在pyspark中需要这么长时间?

为啥 BigQuery API 调用需要这么长时间?

为啥这个 tensorflow 训练需要这么长时间?