SMB 协议在写时复制文件系统上的存储效率机制分析

最后更新于：2025-11-19 10:49:42

第 1 节：SMB 服务端操作与文件系统交互的核心原则

本报告旨在对在写时复制 (Copy-on-Write, CoW) 文件系统（如 Btrfs）上运行的 SMB (Server Message Block) 服务的存储效率机制进行详尽的技术分析。本节首先确立了理解该技术栈所需的基础原则，并澄清了常见的关键概念区别。

1.1 SMB 服务端复制作为网络卸载机制

SMB 2 和 3 协议定义了一种“服务端复制” (server-side copy) 操作 1。此操作的协议定义目的，是通过 FSCTL_SRV_COPYCHUNK 2 等控制代码实现的，是将复制过程的负载从客户端卸载。这避免了客户端首先需要读取（下载）数据，然后再写入（上传）数据的完整过程，从而极大地优化了网络流量。然而，此协议本身并不保证存储空间的效率 4。

1.2 存储效率作为文件系统依赖特性

服务端复制操作是否节省存储空间，完全取决于底层文件系统的能力。具体而言，文件系统必须支持 reflink（也称为“写时复制数据区”或“浅拷贝”）功能 5。

1.3 Btrfs 与 XFS 在 Reflink 功能上的等效性

一个关键的澄清是，reflink 能力并非 Btrfs 7 所独有。XFS 文件系统，当以启用 reflink 支持的方式创建时（例如 mkfs.xfs -m reflink=1）5，在实现空间高效复制方面提供了等效的功能 10。相比之下，ext4 文件系统通常缺乏此特性 11。

1.4 概念区分：Reflink（主动）与重复数据删除（被动）

本报告将明确区分两个在 Btrfs 上经常被混淆的概念：

Reflink (写时复制链接)：这是一种主动的、在复制时发生的操作。创建新文件时，该文件会共享源文件的数据块 6。这是高效 SMB 复制所使用的机制。

Deduplication (重复数据删除)：这是一种被动的、“带外” (out-of-band) 的操作，即在数据写入之后进行的进程。它扫描已存在的、独立写入的文件，查找相同的数据块并将其合并 8。Btrfs 不会自动执行此操作 14。

1.5 跨主机数据传输 (rsync) 与块共享的丢失

reflink 带来的空间节省是一种本地文件系统的元数据特性。当使用如 rsync 16 这样的基于文件的工具将数据复制到远程主机时，这种元数据不会被保留。目标服务器接收的是完整的逻辑数据，导致物理存储占用变得更大。这并非“数据膨胀”，而是块共享状态的丢失 17。

第 2 节：SMB 服务端复制协议

本节深入分析 SMB 服务端复制的协议层机制，确立其功能是独立于底层存储实现的网络优化。

2.1 协议定义与功能

SMB 2/3 协议定义了用于服务端数据复制的文件系统控制 (FSCTLs) 操作 1。主要的控制代码是 FSCTL_SRV_COPYCHUNK 2 和 FSCTL_SRV_COPYCHUNK_WRITE 2。

客户端应用程序通过发送 SMB2 IOCTL Request 3 来发起此操作。该请求指定了源文件密钥、目标文件句柄，以及一个定义了要复制的数据块的源偏移量、目标偏移量和长度的“块”数组 4。服务器在本地处理此请求，并返回一个 SRV_COPYCHUNK_RESPONSE 2，其中包含了已写入的块数和总字节数 21。

微软的协议规范 19 完全专注于偏移量、长度和句柄。它们对于服务器如何物理执行复制请求是完全不可知的。服务器可以执行一个完整的、逐块的读/写操作，也可以执行一个纯元数据的 reflink 操作。这种协议层的抽象是导致用户产生误解的核心来源。SMB 协议保证了网络卸载，因为数据不会传输到客户端，但它不能保证存储效率。这种效率是一种存储层优化，现代文件系统在被调用此协议时可选择性地提供。

2.2 Samba 实现

Samba 项目（在 Linux 上实现 SMB 协议套件）在 4.1.0 版本中引入了对 FSCTL_SRV_COPYCHUNK 请求的支持 22。

Samba 4.1.0 的发布说明 22 同时宣布了两个关键特性：“添加 vfs_btrfs 模块”和“通过 SMB2 FSCTL_SRV_COPYCHUNK 请求添加对服务端复制操作的支持”。这种同步引入并非巧合。它有力地表明，Samba 中服务端复制支持的开发与 vfs_btrfs 模块的开发是共生的。该协议特性的实现，从一开始就意图利用 Btrfs 暴露的 reflink 能力，建立一条“快速路径”。

第 3 节：存储效率复制的文件系统机制

本节分析将 SMB 服务端复制从网络优化转变为存储优化所需的特定文件系统特性 (reflink)。

3.1 Reflink (写时复制) 机制

3.1.1 Btrfs

Btrfs 是一种现代的写时复制 (CoW) 文件系统 7。其核心特性之一是 "Reflink" 6。Reflink 是一种“浅拷贝” 6，复制操作会创建新的文件元数据，该元数据指向源文件的现有数据块。这些文件是独立的；通过 CoW 机制对一个文件所做的更改不会影响另一个文件 6。

3.1.2 XFS

XFS 文件系统同样支持“共享的写时复制数据区功能” 5，这在功能上与 reflink 相同。此功能允许“两个或多个文件共享一组公共的数据块” 5，并被明确指出可用于“高效的文件克隆” 5。

在现代的 xfsprogs 软件包（例如 v4.17.0-2.el8）中，此功能默认启用 5。在 Red Hat Enterprise Linux 8, 9 和 10 中，这是一个标准的、非实验性的功能 9。它可以在创建文件系统时通过 mkfs.xfs -m reflink=1 5 显式启用，或通过 reflink=0 5 禁用。

3.1.3 ext4

ext4 文件系统的权威文档 11 详细说明了诸如 extents、元数据日志和校验和等特性。然而，这些文档中明显缺乏对 reflink 或 CoW 数据区功能的任何引用。因此，ext4 文件系统上的复制操作是完整的数据块复制，会消耗双倍空间。

3.2 Samba VFS：关键的转换层

Samba 利用一个可堆叠的虚拟文件系统 (VFS) 层来与底层文件系统交互 27。vfs_btrfs 模块 28 是一个特定的 VFS 模块，它“为 Samba 提供了 Btrfs 的特定功能” 29。

vfs_btrfs 模块的明确功能是“通过使用 Btrfs 的 clone-range IOCTL 来提高服务端复制操作的性能和效率” 30。它直接将传入的 SMB FSCTL_SRV_COPYCHUNK 请求映射到 Btrfs 的 BTRFS_IOC_CLONE_RANGE ioctl 30。

此映射并非自动发生。管理员必须在 smb.conf 文件中为特定共享显式启用它，例如：[share] vfs objects = btrfs 29。

这是一个关键的故障点。管理员可能会（1）将卷格式化为 Btrfs，（2）通过 Samba 共享它，并假设这些好处是自动的。然而，来自 30 的证据表明，这需要一个显式的配置步骤。一个真实的案例 32 证实了这一点：用户发现在 SMB 挂载上执行 cp --reflink 失败，直到 vfs objects = btrfs 被添加后才得以解决。

3.3 本地操作与性能权衡

在服务器本地，可以使用 cp --reflink=auto 或 cp --reflink=always 5 来调用此 reflink 机制。

reflink 是一种 I/O 的延迟，而非“免费”复制。为什么 cp --reflink=auto 不是 cp 命令在所有情况下的默认行为？coreutils 的文档 34 给出了理由：“健壮性”（用户可能希望物理上分离的副本以保证数据完整性）和“性能”。性能问题是关键：CoW 复制在初始时只是元数据操作，但对任一文件的首次写入都会引发性能损失（延迟），因为 CoW 机制必须读取旧块，将新块写入别处，并更新元数据。

这意味着 reflink 是一种依赖于工作负载的优化。它非常适合“一次写入，多次读取”(WORM) 的数据，如媒体文件或归档。但它可能不利于高 I/O 事务性工作负载（如活跃的虚拟机磁盘或数据库），在这些场景下，CoW 引入的不可预测的写入延迟，比执行完整复制所需的前期 I/O 成本更不受欢迎。

表 1：针对 SMB 服务端复制的文件系统比较

第 4 节：澄清：Btrfs 中的 Reflink 与重复数据删除

本节直接处理最重大的技术误解：将 Btrfs 的 reflink 能力与自动的、在线的重复数据删除功能错误地等同起来。

4.1 Reflink：一种主动的、复制时的机制

如前所述，reflink 是一个特性 7，其中复制操作会创建一个新文件，该文件与源文件共享数据块 6。这是一个主动操作。用户或应用程序（例如 Samba 通过 vfs_btrfs）必须明确请求复制一个文件，reflink 才会发生。它仅适用于作为其他文件副本而创建的文件。

4.2 重复数据删除：一种被动的、带外的机制

Btrfs 文档分别列出了“Deduplication”(重复数据删除) 作为一个特性 7。这被明确定义为“带外”(out-of-band) 重复数据删除 8，意味着它发生在数据写入之后，而不是写入时（带内）。

Btrfs 本身只提供了“基本构建块” 13。实际执行重复数据删除需要用户空间的外部工具，如 duperemove 或 bees 13，来扫描文件系统以查找相同的数据块并将它们合并。

Btrfs 文档 8 和用户空间工具文档 35 直接反驳了自动重复数据删除的观点。Btrfs 不会执行自动的、带内的（在线）重复数据删除。如果用户独立地写入了两个相同的文件（例如，两次单独上传同一个文件，而不是复制），Btrfs 将写入该文件的两个完整的、物理上分离的副本 14。要回收这些重复的空间，管理员必须运行外部的重复数据删除工具，作为单独的、计划性的维护任务。

4.3 SMB 共享的实际影响

场景 A (Reflink)：客户端 A 将 \\server\share\file.dat 复制到 \\server\share\file-copy.dat。

结果： Samba 通过 vfs_btrfs 30 拦截此操作并执行 reflink。空间使用量约为 1 倍。这是高效的。

场景 B (无 Reflink, 无 Dedupe)：客户端 A 上传 file.dat 到 \\server\share\folder1\。客户端 B 上传一个完全相同的 file.dat 到 \\server\share\folder2\。

结果：这是两个独立的写入流。Btrfs 没有带内机制来检查传入的数据块是否与所有现有的数据块匹配。它会写入两个完整的副本。空间使用量为 2 倍。这不会被自动去重 8。

场景 C (带外 Dedupe)：继场景 B 之后，管理员在 \\server\share\ 路径上运行 duperemove。

结果：该工具 13 扫描这两个文件，识别出相同的数据块，并指示 Btrfs 合并它们，释放了 2 倍的空间占用。

第 5 节：跨主机备份策略分析 (rsync)

本节解释备份过程中“数据膨胀”的技术原因，并分析 rsync 缓解功能的技术语义。

5.1 “膨胀”效应：源元数据的丢失

rsync 是一种基于文件的传输工具 16。当备份 Btrfs 卷时，rsync 在虚拟文件系统层操作。它请求文件，Btrfs 驱动程序呈现的是逻辑文件，而不是物理块布局。

因果链：

源端：存在一个 10GB 的文件 (file.dat) 和一个 10GB 的 reflink 副本 (file_reflink.dat)。逻辑大小 = 20GB。物理大小 = 10GB。

rsync 读取 file.dat。Btrfs 驱动程序交付 10GB 的数据。rsync 将其传输到目标端。

rsync 读取 file_reflink.dat。Btrfs 驱动程序（从共享块中读取）交付 10GB 的数据。rsync 将其传输到目标端。

目标端：目标服务器接收两个 10GB 的写入流，并创建两个物理上分离的 10GB 文件。逻辑大小 = 20GB。物理大小 = 20GB。

结论：感知到的“膨胀”并非错误。这是基于文件的复制所导致的正确且预期的结果，它将源端的 reflink 元数据“展平”为完整的数据表示。

5.2 rsync 缓解措施：--link-dest (硬链接)

rsync 实现空间高效增量备份的标准方法是 --link-dest=DIR 选项 38。该选项告诉 rsync 在 DIR（一个先前的备份）中查找，对于任何未更改的文件，创建一个硬链接 (hard link)，而不是重新传输数据 40。

一个硬链接 (ln 41) 会创建一个指向与原始文件完全相同的 inode 的新文件名。链接计数增加，但它本质上是同一个文件的多个名称 41。

5.3 硬链接 (rsync) 与 Reflink (Btrfs) 的语义差异

--link-dest 是否保留了 CoW 行为？答案是否定的。reflink 6 和 hard link 41 的文档揭示了关键区别：

Reflink (CoW): 6 两个文件，两个不同的 inode。共享数据块。编辑一个是隔离的（由于写时复制），不会影响另一个。

Hard Link (硬链接): 41 两个文件，一个 inode。共享数据。编辑一个会立即影响另一个，因为它们是同一个文件。这不是 CoW。

结论是，虽然 rsync --link-dest 38 实现了空间效率，但它是通过创建硬链接，而非 reflink 副本。这从根本上改变了备份的性质。备份中的文件不是独立的 CoW 副本；它们是相互链接的。

5.4 “缺失”的功能：原生 rsync Reflink 支持

标准的 rsync 工具不原生支持在目标端创建 reflink 副本。

rsync 项目的开发历史证实了这一点，支持 reflink 是一个功能请求。开发者们在讨论“rsync 应该支持类似于 cp --reflink 的 reflink” 17，并提议一个新的 --reflink-dest 选项来替代 --link-dest 18。

这证实了 rsync 的标准行为不感知 reflink。在备份期间保留 Btrfs 原生元数据（reflinks, snapshots）的架构上“正确”的工具，不是 rsync，而是 Btrfs 原生的 send/receive 功能 7。

表 2：复制机制语义比较

第 6 节：存储管理员的实施指南

本节将前述分析综合为一组面向系统管理员的、基于证据的声明性建议。

6.1 文件系统选择

建议：对于那些需要高效、服务端复制大文件（例如虚拟机镜像、媒体归档）的 SMB 共享，底层文件系统必须支持 reflink。

行动：部署 Btrfs 8 或 XFS (需以 reflink=1 创建) 5。

避免：不要在该工作负载上部署 ext4 12，因为它缺乏 reflink 支持，所有服务端复制都将消耗 2 倍存储并产生高磁盘 I/O。

6.2 Samba 配置

要求：确保启用 SMB2 或 SMB3 协议。

要求 (Btrfs)：对于 Btrfs 卷上的所有共享，smb.conf 配置必须在共享定义中包含 vfs objects = btrfs 29。

理由：此 VFS 模块是必不可少的组件，它将 SMB FSCTL_SRV_COPYCHUNK 请求 4 映射到 Btrfs BTRFS_IOC_CLONE_RANGE ioctl 30。未能添加此行将导致完整且消耗空间的复制。

6.3 本地文件操作 (服务器端)

建议：在服务器上进行本地文件管理时，使用 cp --reflink=auto 33 来确保复制是空间高效的，并与 SMB 复制的行为保持一致。

考量：评估 CoW 的性能权衡 34。对于高 I/O 事务性数据，完整复制 (--reflink=never) 可能比避免写入延迟更可取。

6.4 重复数据删除 vs. Reflink 策略

澄清：不要指望 Btrfs 执行自动的、在线的重复数据删除。

行动 (Reflink)：使用 reflink（通过 SMB/vfs_btrfs 或 cp --reflink）来复制文件，以主动节省空间。

行动 (Dedupe)：如果工作负载涉及许多独立写入的相同文件（如 4.3 节中的场景 B），则应在低 I/O 时段安排被动的“带外”重复数据删除，使用用户空间工具（如 duperemove）13。

6.5 备份与恢复策略

预期：当跨主机使用如 rsync 之类的基于文件的备份工具时，预计目标存储占用将大于源的物理占用。这是 reflink 元数据丢失的预期结果。

缓解 1 (基于文件)：对于增量文件级备份，使用 rsync --link-dest=DIR 38。这将通过硬链接未更改的文件来节省目标端的空间。必须意识到语义上的差异：这些是硬链接，不是 CoW reflinks 6。

缓解 2 (基于块)：要实现 Btrfs 卷的真正保留元数据的备份，应使用 Btrfs 原生的 btrfs send/receive 功能 7。这在子卷级别操作，并将保留所有的 reflink 和快照数据，但这要求目标端也是 Btrfs 格式。

Works cited

[MS-SMB]: FSCTL SRV COPYCHUNK - Microsoft Learn, accessed November 7, 2025,

[MS-SMB2]: Handling a Server-Side Data Copy Request - Microsoft Learn, accessed November 7, 2025,

[MS-SMB2]: SRV_COPYCHUNK_COPY - Microsoft Learn, accessed November 7, 2025,

[MS-SMB2]: Application Requests a Server Side Data Copy - Microsoft Learn, accessed November 7, 2025,

Chapter 13. File systems and storage | Considerations in adopting RHEL 8 | Red Hat Enterprise Linux, accessed November 7, 2025,

Reflink — BTRFS documentation - Read the Docs, accessed November 7, 2025,

Welcome to BTRFS documentation! — BTRFS documentation - Read the Docs, accessed November 7, 2025,

Introduction — BTRFS documentation - Read the Docs, accessed November 7, 2025,

Chapter 9. Getting started with XFS | Managing file systems | Red Hat Enterprise Linux, accessed November 7, 2025,

Chapter 9. Getting started with XFS | Managing file systems | Red Hat Enterprise Linux | 10, accessed November 7, 2025,

Chapter 6. The Ext4 File System | Storage Administration Guide | Red Hat Enterprise Linux, accessed November 7, 2025,

Chapter 1. Overview of available file systems | Managing file systems | Red Hat Enterprise Linux | 9, accessed November 7, 2025,

Deduplication — BTRFS documentation - Read the Docs, accessed November 7, 2025,

Dedup on btrfs-progs v5.4.1 - Reddit, accessed November 7, 2025,

BTRFS and inband deduplication... - Reddit, accessed November 7, 2025,

rsync(1) manpage - Samba.org, accessed November 7, 2025,

rsync should support reflink similar to cp --reflink · Issue #119 - GitHub, accessed November 7, 2025,

Add new --reflink-dest option to be used instead of --link-dest · Issue #153 · RsyncProject/rsync - GitHub, accessed November 7, 2025,

[MS-FSA]: Server Requests an FsControl Request - Microsoft Learn, accessed November 7, 2025,

[MS-SMB]: Application requests a Server-side Data Copy - Microsoft Learn, accessed November 7, 2025,

FSCTL_SRV_COPYCHUNK Response - MS-SMB - Microsoft Learn, accessed November 7, 2025,

Samba 4.1.0 Available for Download, accessed November 7, 2025,

Chapter 28. Getting started with XFS | System Design Guide | Red Hat Enterprise Linux | 8, accessed November 7, 2025,

Chapter 4. The ext4 File System | Deployment Guide | Red Hat Enterprise Linux | 5, accessed November 7, 2025,

Chapter 5. The ext4 File System | Storage Administration Guide | Red Hat Enterprise Linux, accessed November 7, 2025,

Managing file systems | Red Hat Enterprise Linux | 8, accessed November 7, 2025,

Samba Documentation, accessed November 7, 2025,

Samba man pages in html, accessed November 7, 2025,

vfs_btrfs - Samba, accessed November 7, 2025,

Server-Side Copy - SambaWiki, accessed November 7, 2025,

vfs_btrfs - Samba, accessed November 7, 2025,

if the underlying FS is btrfs the smb.conf options for the share need to reflect that · Issue #1159 - GitHub, accessed November 7, 2025,

cp(1) - Linux manual page - man7.org, accessed November 7, 2025,

Why is cp --reflink=auto not the default behaviour? - Unix & Linux Stack Exchange, accessed November 7, 2025,

Btrfs - ArchWiki, accessed November 7, 2025,

File copying with RSync | Administration Guide | SLES 15 SP7 - SUSE Documentation, accessed November 7, 2025,

Copying Files and Directories with rsync | SUSE Linux Enterprise Server for SAP applications 16.0, accessed November 7, 2025,

rsync(1) - Linux manual page - man7.org, accessed November 7, 2025,

rsync --link-dest understanding : r/linuxquestions - Reddit, accessed November 7, 2025,

Strange rsync behavior when enabling --link-dest - Unix & Linux Stack Exchange, accessed November 7, 2025,

Hard links and soft links in Linux explained - Red Hat, accessed November 7, 2025,