☰

ZFS 快照行为处理文件修改、移动和重命名

tag-icon • tag-icon samba zfs btrfs
ZFS 快照行为处理文件修改、移动和重命名

由于 ZFS 被描述为更像数据库而非文件系统，因此可以合理地预期它的行为也会更像版本管理系统，可以智能地管理文件修改、移动和重命名。这些问题特别询问了快照，但快照与克隆和

  1. 当快照之后在 ZFS 中修改文件时，快照是否具有相同的大小且仅包含差异，还是整个文件？
  2. 当快照之后在 ZFS 中移动文件时，快照的大小是否基本上保持为零？
  3. 当快照之后在 ZFS 中重命名文件时，快照的大小是否基本上保持为零？

  4. 当文件在快照之后具有其自身的硬链接副本时，快照是否基本上保持为空？

  5. 有建议称，BTRFS 的设计目的与 ZFS 大致相同，那么在这些条件下它是否会有相同的行为？

  6. 当 Windows 机器通过 SAMBA 远程访问 ZFS 共享时，上述相同的行为是否成立，或者 SAMBA 是否是标准驱动器指令的子集，即移动变成了复制+删除？

  7. 是否可以一般性地回答上述问题，或者答案是否都是针对特定实现的？

根据评论者的要求，以下是对所述操作进行的测试：

系统信息：

  • CentOS 7 内核 3.10.0
  • ZFS v0.6.5.9-1

。

                  `zpool list`           `zfs list`
      POOL        SIZE  ALLOC   FREE    USED   AVAIL  REFER

创建池：zpool create -m /test/mnt FILE-TEST /test/1.img /test/2.img

      FILE-TEST   224M  80.5K    224M    73K    192M    19K

快照：zfs snapshot FILE-TEST@1

      FILE-TEST   224M   122K    224M    73K    192M    19K
      FILE-TEST@1                          0       -    19K

创建文件：echo ‘test’ > /test/mnt/test.txt

      FILE-TEST   224M   132K    224M    95K    192M    21K
      FILE-TEST@1                        17K       -    19K

增加文件大小：`head -c 128K /test/mnt/test.txt

      FILE-TEST   224M   678K   223M    490K    192M    148K
      FILE-TEST@1                        17K       -    19K

快照：zfs snapshot FILE-TEST@2

      FILE-TEST   224M   267K   224M    239K    192M    148K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                          0       -     48K

编辑文件，更改最后 4 个字节。

      FILE-TEST   224M  1.07M   223M    386K    192M    148K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K

快照：zfs snapshot FILE-TEST@3

      FILE-TEST   224M   548K   223M    388K    192M    148K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                          0       -    148K

重新命名文件mv test.txt test2.txt

      FILE-TEST   224M   552K   223M    404K    192M    150K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K

快照：zfs snapshot FILE-TEST@4

      FILE-TEST   224M  1.06M   223M    645K    191M    150K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                          0       -    150K

新建文件夹：mkdir /test/mnt/subdir

      FILE-TEST   224M   716K   223M    420K    192M    151K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K

快照：zfs snapshot FILE-TEST@5

      FILE-TEST   224M   790K   223M    424K    192M    151K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K
      FILE-TEST@5                          0       -    151K

移动文件：mv /test/mnt/test2.txt /test/mnt/subdir/

      FILE-TEST   224M   584K   223M    444K    192M    151K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K
      FILE-TEST@5                        10K       -    151K

快照：zfs snapshot FILE-TEST@6

      FILE-TEST   224M   602K   223M    447K    192M    151K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K
      FILE-TEST@5                        10K       -    151K
      FILE-TEST@6                          0       -    151K

创建硬链接文件：cp -l /test/mnt/subdir/test2.txt /test/mnt/subdir/test3.txt

      FILE-TEST   224M   603K   223M    466K    192M    152K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K
      FILE-TEST@5                        10K       -    151K
      FILE-TEST@6                        12K       -    151K

从以上观察可以得出：

  • SIZE 和 FREE 非常恒定并且与文件消耗的空间一致
  • ALLOC 是随机的
  • 快照上的 REFER 似乎等于池上的当前 REFER
  • 在大多数操作中，快照上的USED大约为10KB，但文件更改除外，其中USED略大于整个更改的文件大小。
  • 池中的 USED 以不等的跳跃方式增长
  • REFER 在每个操作中逐渐增长到 1K 左右
  • 非当前快照的大小保持不变

答案1

  1. 当快照之后在 ZFS 中修改文件时，快照是否具有相同的大小且仅包含差异，还是整个文件？

不同的块会增加尺寸。

这意味着如果一个文件由 100 个块组成，并且您修改了一个字节（假设一个字节小于一个块），则会在末尾添加一个新块（总共 101 个），您的旧文件将引用块 1 到 100（可以从快照中以只读方式访问）并且您的新/当前文件将引用块 1 到 37 和 39 到 101（或根据您的实际修改操作的任何其他组合）。

一旦您销毁快照，第 38 块将被标记为空闲并且可以被覆盖（只要没有其他快照引用它）。

  1. 当快照之后在 ZFS 中移动文件时，快照的大小是否基本上保持为零？

在同一个文件系统内是的，除了元数据之外（例如，必须重新排列引用）。

在文件系统之间，这是一个完整的复制+删除操作，即使文件系统位于同一个池或彼此的后代。

  1. 当快照之后在 ZFS 中重命名文件时，快照的大小是否基本上保持为零？

是的，除了元数据（例如您的新名字必须记录在某处）。

  1. 当文件在快照之后具有其自身的硬链接副本时，快照是否基本上保持为空？

您能在这里更具体一点吗？

  1. 有建议称，BTRFS 的设计目的与 ZFS 大致相同，那么在这些条件下它是否会有相同的行为？

我不会认为它所做的一切都是一样的。

  1. 当 Windows 机器通过 SAMBA 远程访问 ZFS 共享时，上述相同的行为是否成立，或者 SAMBA 是否是标准驱动器指令的子集，即移动变成了复制+删除？

Windows 文件共享有两种可能的实现 - 要么是 Sun 为 Solaris 开发并使用 OpenSolaris/illumos 开源的 CIFS 服务器，要么是几乎所有 GNU/Linux 发行版和 BSD 系统中使用的 Samba SMB 实现：

  • Solaris 版本更好地适应了 ZFS 特性（比如直接在文件系统上设置共享属性、像 Windows 以前的版本一样实现 ZFS 快照）。
  • 另一方面，Samba 版本更加跨平台，并且具有一些更高级的功能，如（部分）SMB3 支持、IIRC。

我认为第二种情况与其他系统上的情况非常相似，尽管我没有测试过。

  1. 是否可以一般性地回答上述问题，或者答案是否都是针对特定实现的？

如果您喜欢阅读 C 代码，您可以根据 illumos/OpenZFS repo（Github 存储库）上的代码来具体回答，或者您可以根据手册页和文档来一般性地回答。例如，REFER、USED 等属性在那里有详细的解释。最有趣的手册页是man zpool（硬件、磁盘布局、池属性）、man zfs（文件系统属性、快照、克隆）、man chmod（仅限 Solaris/illumos、文件和共享 ACL）和man zdb（调试和分析）。

相关内容