由于ZFS被描述为更像是数据库而不是文件系统，因此可以预期ZFS的行为也更像是版本管理系统，可以智能地管理文件的修改，移动和重命名。这些问题专门询问有关快照的信息，但是快照与克隆和
当文件在快照后具有自身的硬链接副本时，快照将基本上保持空白吗？
有人建议BTRFS被设计成与ZFS基本上具有相同的功能，那么在这些情况下是否会期望它们具有相同的行为？
当Windows计算机通过SAMBA远程访问ZFS共享时，上述相同行为是否成立，还是SAMBA是标准驱动器指令的子集，即移动变为复制+删除？
是否可以一般性地回答上述问题，或者答案是否都是针对特定实现的？
根据评论者的要求，以下是对所述操作进行的测试：
系统信息：
。
`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
从上面的观察：
- 在快照后在ZFS中修改文件时，快照的大小将是一样的，只是不同之处还是整个文件？
不同的块会增加大小。
这意味着，如果一个文件包含100个块，并且您修改了一个字节（假设一个字节小于一个块），那么最后将添加一个新块（总共101个），您的旧文件将引用第1到100个块（可以从快照中以只读方式访问），并且您的新文件/当前文件将引用块1到37和39到101（或任何其他组合，具体取决于您的实际修改操作）。
销毁快照后，块38将被标记为空闲并且可以被覆盖（只要没有其他快照引用该块）。
- 在快照后在ZFS中移动文件时，快照是否基本上保持零大小？
在同一个文件系统中，是，除了元数据（例如，引用必须重新排列）。
在文件系统之间，即使文件系统位于相同的池或彼此的后代中，它也是完整的复制+删除操作。
- 在快照后在ZFS中重命名文件时，快照是否基本上保持零大小？
是的，除了元数据（例如，您的新名称必须记录在某处）。
- 当文件在快照后具有自身的硬链接副本时，快照将基本上保持空白吗？
您能在这里更具体吗？
- 有人建议BTRFS被设计成与ZFS基本上具有相同的功能，那么在这些情况下是否会期望它们具有相同的行为？
我不认为它所做的一切都一样。
- 当Windows计算机通过SAMBA远程访问ZFS共享时，上述相同行为是否成立，还是SAMBA是标准驱动器指令的子集，即移动变为复制+删除？
您有两种可能的Windows文件共享实现方式-由Sun为Solaris开发并通过OpenSolaris / illumos开源的CIFS服务器，或几乎在所有GNU / Linux发行版和BSD系统中使用的Samba SMB实现：
我假设在第二种情况下，尽管我没有测试，但与其他系统几乎相同。
- 是否可以一般性地回答上述问题，或者答案是否都是针对特定实现的？
如果您想阅读C代码，则可以根据illumos / OpenZFS存储库（Github存储库）上的代码专门回答，也可以根据手册页和文档进行一般回答。例如，在此详细说明了REFER，USED等属性。最有趣的联机帮助页是man zpool（硬件，磁盘布局，池属性），man zfs（文件系统属性，快照，克隆），man chmod（仅Solaris / illumos，文件和共享ACL）和man zdb（调试和分析）。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句