首页 > 解决方案 > 使用 copy_file_range 进行复制加速

问题描述

我正在学习 Linux 中两个文件描述符之间的内核数据传输,遇到了一些我无法理解的东西。这是来自copy_file_range 手册页的引用

copy_file_range()为文件系统提供了实现“复制加速”技术的机会,例如使用 reflinks(即,两个或多个 i-nodes 共享指向相同的写时复制磁盘块的指针)或服务器端复制

我曾经认为索引节点是stat/ statxsyscall 返回的东西。st_ino类型在这里typedef编辑为

typedef unsigned long   __kernel_ulong_t;

那么,“两个或多个 i-node 共享指向同一个写时复制磁盘块的指针”是什么意思呢?

标签: clinuxfile-descriptor

解决方案


根据我的理解,copy_file_range不需要通过用户模式传递数据的事实意味着内核根本不需要从磁盘加载数据(它仍然可能但它不必),这允许通过将操作下推到文件系统堆栈来进一步优化。这涵盖了通过 NFS 进行服务器端复制的情况。

关于其他优化的实际答案从介绍文件的存储方式开始,如果您已经知道,可以跳过它。

文件在典型 Linux FS 中的存储方式分为 3 层:

  1. 某个目录中的文件条目(它本身就是一个包含此类条目列表的文件)。这样的条目本质上将文件名映射到某个 inode。它是通过存储 inode-number aka 来完成的,st_ino它实际上是指向某个表中的 inode 的指针。

  2. 包含一些共享(见进一步)元数据(作为返回的元数据)和一些指向存储实际文件内容的数据块的指针的inode 。stat

  3. 实际数据块

因此,例如,硬链接是某个目录中的记录,它指向与“原始”文件相同的 inode(并增加 inode 内的“链接计数器”)。这意味着只有文件名(可能还有目录)不同,所有其余数据和元数据在硬链接之间共享。请注意,创建硬链接是复制文件的一种非常快速的方法。唯一的缺点是现在两个文件都必须永远共享它们的内容,所以这不是一个真正的副本。但是如果我们使用一些写时复制的方法来修复“写”部分,它会工作得很好。这是一些 FS(例如Btrfs)通过 reflink 支持的。

这种写时复制技巧的想法是,您可以使用新的适当元数据创建新的 inode,但仍共享相同的数据块。您还可以在 inode 元数据的“不可见”部分中添加两个 inode 之间的交叉引用,以便它们知道它们共享数据块。显然,这个操作与真正的复制相比是非常快的。再次,只要文件只被读取,一切正常。但与硬链接不同,我们也可以处理将它们视为独立的写入。当执行一些写入时,FS 检查文件(或者更确切地说是 inode)是否真的是数据块的唯一所有者,否则在写入之前复制数据。根据 FS 实现,它可以在第一次写入时复制整个文件,或者它可以存储一些更详细的元数据,只复制必须修改的块,并在文件之间共享其余部分。在后一种情况下,如果写入大小超过一个块,则可能根本不需要复制块。

所以最简单的技巧copy_file_range()是检查整个文件是否真的被复制,如果是,则执行上面描述的 reflink 技巧(显然,如果 FS 支持它)。

如果 FS 支持数据块上更详细的元数据,则还可以进行一些更高级的优化。假设您将文件开头的前 N ​​个字节复制到一个新文件中。然后 FS 可以只共享起始块,并且可能只需要复制最后一个未完全复制的块。


推荐阅读