我在主机系统上使用带压缩+重复数据删除的 ZFS,并使用 Qemu/KVM 进行虚拟化。我想让 ZFS 完成它的工作并禁用 Windows 10 的 NTFS 压缩功能(CompactOS 和 NTFS FS 压缩)。但是,事情并没有按预期进行,所以我做了一些测试,如下所示。
总结NTFS 压缩如何真的被禁用?Windows 似乎忽略了设置和 GPO.... oO
事实证明,这并没有问题,只是对du
ZFS 系统上的输出感到困惑。参见接受的答案。
测试
1 禁用压缩
fsutil behavior set disablecompression 1
compact /compactos:never
(这不会影响这个测试,但我们还是禁用它)- 通过 GPO 设置“不允许在 NTFS 卷上压缩”
- 重启
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