☰

测试

tag-icon • tag-icon zfs qemu ntfs compression
测试

我在主机系统上使用带压缩+重复数据删除的 ZFS，并使用 Qemu/KVM 进行虚拟化。我想让 ZFS 完成它的工作并禁用 Windows 10 的 NTFS 压缩功能（CompactOS 和 NTFS FS 压缩）。但是，事情并没有按预期进行，所以我做了一些测试，如下所示。

总结NTFS 压缩如何真的被禁用？Windows 似乎忽略了设置和 GPO.... oO

事实证明，这并没有问题，只是对duZFS 系统上的输出感到困惑。参见接受的答案。

测试

1 禁用压缩

  1. fsutil behavior set disablecompression 1
  2. compact /compactos:never（这不会影响这个测试，但我们还是禁用它）
  3. 通过 GPO 设置“不允许在 NTFS 卷上压缩”
  4. 重启

2 创建测试数据

不可压缩：

$ dd if=/dev/urandom of=uncomp.bin bs=1M count=5500
$ dd if=/dev/urandom of=uncomp2.bin bs=1M count=3000
# I had Ctrl-C'ed somewhere so I finally ended up with these sizes:
# du -scm uncomp*
2861    uncomp2.bin
3642    uncomp.bin
6503    total
# check
$ tar -cf - uncomp* | lz4 >uncomp.comp
$ du -m uncomp.comp
6503    uncomp.comp

且可压缩：

$ lzdgen -o comp -r 3.0 -s 6503m
# check
$ cat comp | lz4 >comp.comp
$ du -h comp.comp
2,2G    comp.comp

3 创建原始测试磁盘

$ qemu-img create -f raw testdisk1.img 10G
$ qemu-img create -f raw testdisk.img 10G

通过 VirtIO 将两个磁盘连接到 Windows VM，初始化并格式化为 NTFS 卷。

4 将测试数据复制到测试磁盘

复制uncomp*到testdisk和comp并testdisk1检查磁盘使用情况。

测试磁盘 测试磁盘

正如预期的那样，两个卷都显示相同的磁盘使用情况。

5 检查原始磁盘映像大小

在禁用 NTFS 压缩的情况下，我期望两个原始磁盘映像具有完全相同的大小，但是，（可压缩）数据仍然会被压缩：

$ du -h testdisk*
2,2G    testdisk1.img
6,4G    testdisk.img

$ qemu-img info testdisk.img 
image: testdisk.img
file format: raw
virtual size: 10 GiB (10737418240 bytes)
disk size: 6.35 GiB

$ qemu-img info testdisk1.img 
image: testdisk1.img
file format: raw
virtual size: 10 GiB (10737418240 bytes)
disk size: 2.17 GiB

6 挂载时检查 testdisk1 的数据大小

只是要确定 ...

$ sudo qemu-nbd -c /dev/nbd0 testdisk1.img
$ mkdir /tmp/mnt
$ sudo mount /dev/nbd0p2 /tmp/mnt
$ df -h
...
/dev/nbd0p2                               10G  6,4G  3,6G  64% /tmp/mnt
$ du -sch /tmp/mnt
6,4G    /tmp/mnt
6,4G    total

更新 1

经过验证testdisk1（感谢@DanielB的提示！），我意识到这lzdgen会创建空字节漏洞，这对测试来说非常糟糕。因此，我使用以下方式创建的文件重新进行了测试：

./fio --name=randomwrite --ioengine=sync --rw=readwrite --bs=4k --size=5600M --buffer_compress_percentage=50 --refill_buffers --buffer_pattern=0xdeadbeef --filename=comp2

这里不使用空字节洞，而是使用 0xdeadbeef 模式。该文件完全可以压缩：

$du -h comp2
5,5G    comp2
$ cat comp2 | lz4 >yyy
$ du -h yyy
2,8G    yyy

将文件复制comp2到（刚刚重新创建的）后testdisk1，原始图像如下所示：

$ du -h testdisk1.img 
3,0G    testdisk1.img

我使用 hexedit 搜索文件的开头并使用 dd 将其转储：

dd if=testdisk1.img of=comp2_dump skip=3367040 bs=1k count=5734400
5734400+0 records in
5734400+0 records out
5872025600 bytes (5,9 GB, 5,5 GiB) copied, 48,2982 s, 122 MB/s
c0d3@z3r0:[~]# du -sch comp2_dump
3,0G    comp2_dump
3,0G    total
$ sha1sum comp2_dump comp2 
22171686b58536d50c8b516ee859213650cb6b55  comp2_dump
22171686b58536d50c8b516ee859213650cb6b55  comp2

什么……

答案1

好的，我终于知道这是怎么回事了。du似乎显示了压缩/重复数据删除的大小（ZFS）。我已将文件复制comp2到没有压缩/重复数据删除的 zfs 数据集，并du显示正确的 5,5G：

$ sudo zfs create -o mountpoint=/wtf rpool/zroot/wtf
$ sudo cp comp2 /wtf/
$ zfs list rpool/zroot/wtf
NAME              USED  AVAIL     REFER  MOUNTPOINT
rpool/zroot/wtf  5.47G   224G     5.47G  /wtf
$ du -h /wtf/comp2 
5,5G    /wtf/comp2

同样的情况也发生在testdisk1：

$ sudo rm /wtf/comp2
$ sudo cp testdisk1.img /wtf/
$ zfs list rpool/zroot/wtf
NAME              USED  AVAIL     REFER  MOUNTPOINT
rpool/zroot/wtf  5.49G   224G     5.49G  /wtf
$ du -h /wtf/testdisk1.img
5,5G    /wtf/testdisk1.img

相关内容