使用 mv(而不是 cp 后跟 rm)有什么危险吗?

And*_*rew 8 mv

我是一名研究生,可以访问我大学的研究小组 Linux 集群。这些年来,我积累了很多目录——我猜“文件夹”是 Windows/Mac 术语吗?-- 在我的主目录 ( ~) 中。当我进行新的模拟时,我在我的主目录中创建一个新目录mkdir,然后在该目录中运行模拟。

但是随着时间的推移,我在我的主目录中积累了许多这样的目录。现在我想将一些目录移动到子目录中。例如,我可能想创建一个名为的新目录simulations1_10,然后将目录simulation1, simulation2, ...移动simulation10到该目录中——这样我的主目录的根目录就会更有条理。

为此,我可以使用cp. 例如:

cp -r simulation1/ simulations1_10/
Run Code Online (Sandbox Code Playgroud)

将目录simulation1(及其所有内容)复制到目录simulations1_10。然后我可以删除simulation1.

但是,我的转让跨越文件系统边界,所以mv的速度比cp。(mv当然也允许我避免删除步骤。)例如:

mv simulation1/ simulations1_10/
Run Code Online (Sandbox Code Playgroud)

做的伎俩很快(不像cpmv默认情况下递归)。根据this answer to this questionmv速度要快得多,因为它“只是更新各个目录中的inode数据库”。

我的问题是,使用有什么危险mv吗?

我认为一个危险是,如果在传输过程中mv被中断(由于电源故障、用户按下Ctrl+C等),文件可能在源目标中都被损坏。这样对吗?

另外,如果我使用mv 很多,是否有可能“inode 数据库”更新过于频繁,从而导致磁盘碎片或其他硬盘驱动器/文件系统问题?

dha*_*hag 9

rename函数(作为命令的基础mv“mv 实用程序应执行与 rename() 函数等效的操作”)是原子的(参见 POSIX http://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html,即参考C标准):

对于常规文件,此 rename() 函数等效于 ISO C 标准定义的函数。它在此处的包含扩展了该定义以包括对目录的操作并指定当新参数命名已存在的文件时的行为。该规范要求函数的动作是原子的。

(但请参阅此警告:https : //unix.stackexchange.com/a/322074/88983。)

中断的操作,无论是通过 Ctrl-C 还是其他方式,都不应该导致部分传输的文件。事实上,正如您提到的,单文件系统mv实际上并不复制任何文件内容,仅复制文件元数据。在这方面应该发生的最糟糕的情况是看到部分移动的目录(如果您这样做mv a b c dest,可能会中断并且只a移动到dest,但所有文件及其内容都将被正确移动),而不是部分移动的常规文件。

关于您的 inode 方面的问题,我想说这通常不是问题;更新 inode 以仅移动几个目录是一种低开销的常规操作(发生在同一文件系统上的文件内容写入应该是更大的潜在性能损失或碎片原因,具体取决于特定的文件系统类型)。