文件操作(复制、移动、删除)的速度是否取决于该文件的权限?

文件操作(复制、移动、删除)的速度是否取决于该文件的权限?

文件操作(复制、移动、删除)的速度是否取决于该文件的权限?如果是这样,那又如何呢?

原因:需要不断地对许多文件执行上述操作。如果文件具有一定的权限,这些操作会更快完成吗?例如,“只读”权限。

答案1

文件操作(复制、移动、删除)的速度是否取决于该文件的权限?如果是这样,那又如何呢?

仅当权限阻止操作时,操作才会被拒绝(因此可以被认为花费无限时间)。

除了极端的边缘情况外,权限不会影响任何复制/移动/删除操作的速度。


我被要求验证我的陈述,这对于某人来说是完全可以接受的事情。这是我的回答的理由。 (如果我对这一挑战的引用/解释不当,我深表歉意;我无意回避。)

如果数百万个小文件中的每一个都有大量的 ACL,该怎么办?在这种情况下,解析权限可能比实际从磁盘(即 PCI-E gen4 SSD)读取这些文件花费更多时间。您是否可以使用读取速度通常高达 10GB/秒的 PCI-E 第 4 代 NVMe 驱动器?

我找不到每个文件 ACL 数量的最大数量。然而,有完成了一些研究对此,有一个可下载的脚本。在研究人员的测试中,每个文件大约有 500 个 ACL。在我的测试中,我达到了 Raspbian 上 ext4 文件系统 252 个 ACL 的限制。 (我们不考虑速度,只考虑限制。)

在这个大小下,它们要么被打包在 inode 的块中,要么最多在一个块之外。这是一个需要阅读和解析的额外块。非常小的文件可以存储在 ext4 inode 中,因此无需读取额外的数据块。使用 NVMe 驱动器,每个文件额外 ACL 块的读取时间将非常短,并且解析 250 个左右的 ACL 条目在计算上不会非常困难。这是假设文件非常小,不需要额外的块。

经验?当然。实际的?我相信是这样。

答案2

文件操作(复制、移动、删除)的速度是否取决于该文件的权限?如果是这样,那又如何呢?

速度是完全由文件系统定义的:例如,同一文件系统内的移动只会更改文件系统数据结构中的条目,因此不会触及实际的文件内容。因此,所花费的时间将取决于系统从程序切换到内核所需的时间以及这些数据结构上操作的复杂性。

无论权限如何,复杂性都应该是相同的。但是:对于所有者、组、其他人来说,权限不仅仅是读/写/执行;还有 ACL 和 xattrs,在特殊情况下可能会变得更加复杂。但这些很可能对你来说根本不重要。

权限可能重要的唯一情况是,如果需要协调对文件的并发访问(例如,在通过 NFS 挂载的网络文件系统上),但即便如此,我还没有看到这样的差异。

所以,现在,通常情况下,事情是“快”的,完全停止。您问这个问题,但甚至没有提及您正在使用的实际文件系统,这可能意味着您担心的是错误的事情。您很可能会发现文件系统之间的差异。例如,如果您经常复制文件,那么使用知道多重引用范围的文件系统将大大地加快事情的进展。目前,在 Linux 下,只有两种选择:XFS 和 btrfs。但即使在这两者之间,在进行大量操作时(例如每秒 10000 次以上),您也会发现可测量的速度差异。我倾向于 XFS,但要自己进行基准测试;使用 LVM,创建和销毁文件系统确实是微不足道的。

您正在使用标签的事实 ,, 和但是,这可能意味着您将同名的 shell 工具完成所需的时间等同起来。这是一个非常不同的问题:调用/usr/bin/rm1 比实际删除该文件花费的时间要长得多。如果您从 shell 脚本或某些明确必须调用这些工具来修改文件系统的语言中看到此瓶颈,则很可能您的进程创建是您的瓶颈,而不是您的文件操作本身。


1 也就是说,在 fork 中fork启动进程execve("/usr/bin/rm"),Linux 将程序加载到 RAM 中,为动态链接器尝试打开大约 20 个库的进程分配内存,然后实际加载一个,分配更多内存,执行大量文件属性,opening stdout 和stderr...然后再次关闭所有这些,然后再实际unlinking 文件...这是实际删除请求(即)的 100 倍unlink

相关内容