我有一台 Ubuntu VM，其中有一个卷包含一些非常非常可压缩的数据集。
因此，我将相关卷转换为 ZFS 卷，因为我可以使用 ZFS 压缩。
这一切都运行得很好，但是我对一些 ZFS 状态输出感到困惑。
durr@graphical:/tank$ du . -h --max-depth=1; echo -----; du . -h --apparent-size --max-depth=1
1.9G ./carbon
1.9G .
-----
193G ./carbon
193G .
注意：/tank/是 ZFS 卷的挂载点。
因此，根据上述情况，我目前获得的压缩率约为 1%（这是预期的，因为音量几乎完全碳数据文件（大部分都是空的，因此压缩性极高）。
但是，如果我向 ZFS 询问有关卷的信息：
durr@graphical:/tank$ sudo zfs get all tank
NAME PROPERTY VALUE SOURCE
tank type filesystem -
tank creation Mon Dec 25 7:27 2017 -
tank used 1.87G -
tank available 239G -
tank referenced 1.85G -
tank compressratio 4.39x -
tank mounted yes -
tank quota none default
tank reservation none default
tank recordsize 128K default
tank mountpoint /tank default
tank sharenfs off default
tank checksum on default
tank compression on local
tank atime on default
tank devices on default
tank exec on default
tank setuid on default
tank readonly off default
tank zoned off default
tank snapdir hidden default
tank aclinherit restricted default
tank canmount on default
tank xattr on default
tank copies 1 default
tank version 5 -
tank utf8only off -
tank normalization none -
tank casesensitivity sensitive -
tank vscan off default
tank nbmand off default
tank sharesmb off default
tank refquota none default
tank refreservation none default
tank primarycache all default
tank secondarycache all default
tank usedbysnapshots 0 -
tank usedbydataset 1.85G -
tank usedbychildren 18.7M -
tank usedbyrefreservation 0 -
tank logbias latency default
tank dedup on local
tank mlslabel none default
tank sync standard default
tank refcompressratio 4.40x -
tank written 1.85G -
tank logicalused 8.13G -
tank logicalreferenced 8.13G -
tank filesystem_limit none default
tank snapshot_limit none default
tank filesystem_count none default
tank snapshot_count none default
tank snapdev hidden default
tank acltype off default
tank context none default
tank fscontext none default
tank defcontext none default
tank rootcontext none default
tank relatime on temporary
tank redundant_metadata all default
tank overlay off default
ZFS 报告的压缩率为 或4.39x，4.40x具体取决于您查看的位置。但是，对于之前的 ~1% 压缩率，我预计会看到 0.01x 或 99.0x，具体取决于 ZFS 如何表示其状态。
我谷歌了一下，似乎找不到关于该compressratio成员的文档。它肯定会随着数据的移动而改变，因为我看到它发生了变化，但它实际上告诉我什么？
想想看，我还为这个卷启用了 ZFS 重复数据删除功能，所以我认为它可以对空块进行重复数据删除。然而，这似乎不正确：
durr@graphical:/tank$ sudo zpool get all tank
NAME PROPERTY VALUE SOURCE
tank size 248G -
tank capacity 0% -
tank altroot - default
tank health ONLINE -
tank guid 11995166271724776732 default
tank version - default
tank bootfs - default
tank delegation on default
tank autoreplace off default
tank cachefile - default
tank failmode wait default
tank listsnapshots off default
tank autoexpand off default
tank dedupditto 0 default
tank dedupratio 1.12x -
tank free 246G -
tank allocated 1.69G -
tank readonly off -
tank ashift 0 default
tank comment - default
tank expandsize - -
tank freeing 0 default
tank fragmentation 1% -
tank leaked 0 default
tank feature@async_destroy enabled local
tank feature@empty_bpobj enabled local
tank feature@lz4_compress active local
tank feature@spacemap_histogram active local
tank feature@enabled_txg active local
tank feature@hole_birth active local
tank feature@extensible_dataset enabled local
tank feature@embedded_data active local
tank feature@bookmarks enabled local
tank feature@filesystem_limits enabled local
tank feature@large_blocks enabled local
从 ZFS 的角度来看，我不知道额外的数据在哪里。我认为这些文件很稀疏。ZFS 不会立即将磁盘空间专用于稀疏文件吗？
答案1
看起来 ZFS 在启用压缩时会将空文件转换为稀疏文件。摘自从这里开始 DeHackEd。
对你的问题最可能的答案是，稀疏洞不被视为“压缩”。它们是洞。在 ext4 上你也会遇到同样的情况，而且它根本不支持压缩。启用压缩后，ZFS 会将全空页面变成稀疏洞。
我还使用稀疏文件、从中创建的文件/dev/zero和仅使用字符创建的文件在 ZFS 数据集上创建了一些文件a，以获得良好的压缩。
用于创建文件的命令。
truncate -s $((1024*1024*1024)) /tank1/sparsefiledd if=/dev/zero of=/tank1/zerofile bs=1073741824 count=1- 使用一些 for 循环来回
a显afile
首先检查空文件集的压缩率tank1。
[root@localhost tank1]# zfs get all tank1 | grep compress
tank1 compressratio 1.00x -
tank1 compression lz4 local
tank1 refcompressratio 1.01x -
然后创建一个稀疏文件和一个大小为 1GB 的文件/dev/zero并再次检查压缩率。
[root@localhost tank1]# truncate -s $((1024*1024*1024)) sparsefile
[root@localhost tank1]# dd if=/dev/zero of=/tank1/zerofile bs=1073741824 count=1
[root@localhost tank1]# zfs get all tank1 | grep compress
tank1 compressratio 1.00x -
tank1 compression lz4 local
tank1 refcompressratio 1.01x -
什么都没有改变，尽管零文件应该被认为是相当好的可压缩性。使用稀疏文件时，空间永远不会立即分配，而只会按需分配。这是任何文件系统上的行为，因为它与文件系统无关。
所做的就是设置尺寸参数，但是正如您从中看到的那样，没有分配任何块stat。
[root@localhost tank1]# stat sparsefile
File: ‘sparsefile’
Size: 1073741824 Blocks: 1 IO Block: 131072 regular file
Device: 2ah/42d Inode: 2 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-12-30 15:31:37.512845721 +0100
Modify: 2017-12-30 15:31:37.513845720 +0100
Change: 2017-12-30 15:31:37.513845720 +0100
Birth: -
[root@localhost tank1]# stat zerofile
File: ‘zerofile’
Size: 1073741824 Blocks: 1 IO Block: 131072 regular file
Device: 2ah/42d Inode: 3 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-12-30 15:31:41.742838662 +0100
Modify: 2017-12-30 15:31:42.616837203 +0100
Change: 2017-12-30 15:31:42.616837203 +0100
Birth: -
所以稀疏文件和零文件看起来几乎一样，只分配了 1 个块。
如果我们在文件系统上执行相同操作ext4，我们可以看到差异，因为零文件被分配。
[root@localhost test]$ stat sparsefile
File: sparsefile
Size: 1073741824 Blocks: 0 IO Block: 4096 regular file
Device: fd02h/64770d Inode: 2883724 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ root) Gid: ( 1000/ root)
Access: 2017-12-30 15:53:46.477442716 +0100
Modify: 2017-12-30 15:53:46.477442716 +0100
Change: 2017-12-30 15:53:46.477442716 +0100
Birth: -
[root@localhost test]$ stat zerofile
File: zerofile
Size: 1073741824 Blocks: 2097160 IO Block: 4096 regular file
Device: fd02h/64770d Inode: 2884453 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ root) Gid: ( 1000/ root)
Access: 2017-12-30 15:54:11.014403727 +0100
Modify: 2017-12-30 15:54:11.311403254 +0100
Change: 2017-12-30 15:54:11.311403254 +0100
Birth: -
现在让我们看一个文件的示例，该文件仅包含aZFS 上大小为 1GB 的字符。
[root@localhost tank1]# du -h afile
33M afile
[root@localhost tank1]# du -h afile --apparent-size
1.0G afile
[root@localhost tank1]# zfs get all tank1 | grep compress
tank1 compressratio 31.16x -
tank1 compression lz4 local
tank1 refcompressratio 31.89x -
压缩率相当好，并且与包含的文件不同zeros。