Filesystems ZFS块大小（recordsize）和primarycache问题
在本网站上： 此人表明，通过将Filesystems ZFS块大小（recordsize）和primarycache问题,filesystems,zfs,Filesystems,Zfs,在本网站上： 此人表明，通过将primarycache切换到all或metadata，他在使用防病毒软件时获得了截然不同的读取性能 然而，他也显示了读取带宽也有巨大的差异 我创建了两个全新的数据集，primarycache=none和compression=lz4，并在每个数据集中复制了一个4.8GB的文件（2.05x compressratio）。然后我在第一个上设置primarycache=all，在第二个上设置primarycache=metadata。 在另一个终端上运行zpool io
primarycacheprimarycache关于ZFS的recordsize是可变的说法呢？博主Patrick运行的测试是将4.8 GB文件（压缩到2.44 GB）“cat”为/dev/null，并观察读取该文件所用的时间 关键是“primarycache=metadata”也可能意味着“cache=off”，因为实际文件都不会存储在缓存中。当“primarycache=all”时，系统读取整个文件一次，并将其存储在缓存中（通常为RAM，然后在填满时存储二级SSD缓存）。当“cat”或“clamscan”查找该文件时，他们可以在那里找到它，并且不需要再次从磁盘读取该文件 当cat将文件写入/dev/null时，它不仅仅将其写入一个2.44 GB的块中，而是一次写入一点，然后检查缓存中的下一位，然后再写入一点，等等 在关闭缓存的情况下，当文件写入/dev/null（或stdout，无论在哪里）时，需要从磁盘重新读取该文件的次数将是荒谬的——这就是“128k/4k=32”的逻辑 ZFS在磁盘上以128k块写入文件，但论坛海报发现“clamscan”（和“cat”，至少在该用户的FreeBSD盒上）以4k块处理数据。因此，如果没有缓存，每个128k块将必须被服务32次，而不是一次。（clamscan将块#1拉出，128k大，使用第一个4k；再次需要块#1，因为没有缓存，所以它会再次从磁盘读取该块；取出第二个4k，抛出其余的4k；等等。） 结果是： [1] 不管出于什么原因，可能永远都不会使用“primarycache=metadata” [2] 当块大小如此不匹配时，可能会导致性能问题。 如果clamscan读取128k块，则单个文件的读取不会有（显著？）差异。OTOH，如果您不久后再次需要该文件，缓存将仍然具有其数据块，并且不需要再次从磁盘中提取它 下面是一些受论坛帖子启发的测试来说明。示例发生在zfs数据集上，记录大小设置为128k（默认值），primarycache设置为metadata，1G虚拟文件以不同的块大小复制，先128k，然后4，然后8。（向右滚动，我已将复制命令与iostat读数对齐） 请注意，当块大小不匹配时，读写比率会急剧上升，读取带宽也会随之下降
root@zone1:~# zpool iostat 3
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
rpool 291G 265G 0 21 20.4K 130K
rpool 291G 265G 0 0 0 0
rpool 291G 265G 0 515 0 38.9M ajordan@zone1:~/mnt/test$ mkfile 1G test1.tst
rpool 291G 265G 0 1.05K 0 121M
rpool 292G 264G 0 974 0 100M
rpool 292G 264G 0 217 0 26.7M
rpool 292G 264G 0 516 0 58.0M
rpool 292G 264G 0 0 0 0
rpool 292G 264G 0 0 0 0
rpool 292G 264G 0 96 0 619K
rpool 292G 264G 0 0 0 0
rpool 292G 264G 0 0 0 0
rpool 292G 264G 0 0 0 0
rpool 292G 264G 0 0 0 0
rpool 292G 264G 0 0 0 0
rpool 292G 264G 0 0 0 0
rpool 292G 264G 0 0 0 0
rpool 292G 264G 0 0 0 0
rpool 292G 264G 474 0 59.3M 0 ajordan@zone1:~/mnt/test$ dd if=test1.tst of=test1.2 bs=128k
rpool 292G 264G 254 593 31.8M 67.8M
rpool 292G 264G 396 230 49.6M 27.9M
rpool 293G 263G 306 453 38.3M 45.2M 8192+0 records in
rpool 293G 263G 214 546 26.9M 62.0M 8192+0 records out
rpool 293G 263G 486 0 60.8M 0
rpool 293G 263G 211 635 26.5M 72.9M
rpool 293G 263G 384 235 48.1M 29.2M
rpool 293G 263G 0 346 0 37.2M
rpool 293G 263G 0 0 0 0
rpool 293G 263G 0 0 0 0
rpool 293G 263G 0 0 0 0
rpool 293G 263G 0 0 0 0
rpool 293G 263G 0 0 0 0
rpool 293G 263G 0 0 0 0
rpool 293G 263G 0 0 0 0
rpool 293G 263G 0 0 0 0
rpool 293G 263G 1.05K 70 134M 3.52M ajordan@zone1:~/mnt/test$ dd if=test1.tst of=test1.3 bs=4k
rpool 293G 263G 1.45K 0 185M 0
rpool 293G 263G 1.35K 160 173M 10.0M
rpool 293G 263G 1.44K 0 185M 0
rpool 293G 263G 1.31K 180 168M 9.83M
rpool 293G 263G 1.36K 117 174M 9.20M
rpool 293G 263G 1.42K 0 181M 0
rpool 293G 263G 1.26K 120 161M 9.48M
rpool 293G 263G 1.49K 0 191M 0
rpool 293G 263G 1.40K 117 179M 9.23M
rpool 293G 263G 1.36K 159 175M 9.98M
rpool 293G 263G 1.41K 12 180M 158K
rpool 293G 263G 1.23K 167 157M 9.63M
rpool 293G 263G 1.54K 0 197M 0
rpool 293G 263G 1.36K 158 175M 9.70M
rpool 293G 263G 1.42K 151 181M 9.99M
rpool 293G 263G 1.41K 21 180M 268K
rpool 293G 263G 1.32K 132 169M 9.39M
rpool 293G 263G 1.48K 0 189M 0
rpool 294G 262G 1.42K 118 181M 9.32M
rpool 294G 262G 1.34K 121 172M 9.73M
rpool 294G 262G 859 2 107M 10.7K
rpool 294G 262G 1.34K 135 171M 6.83M
rpool 294G 262G 1.43K 0 183M 0
rpool 294G 262G 1.31K 120 168M 9.44M
rpool 294G 262G 1.26K 116 161M 9.11M
rpool 294G 262G 1.52K 0 194M 0
rpool 294G 262G 1.32K 118 170M 9.44M
rpool 294G 262G 1.48K 0 189M 0
rpool 294G 262G 1.23K 170 157M 9.97M
rpool 294G 262G 1.41K 116 181M 9.07M
rpool 294G 262G 1.49K 0 191M 0
rpool 294G 262G 1.38K 123 176M 9.90M
rpool 294G 262G 1.35K 0 173M 0
rpool 294G 262G 1.41K 114 181M 8.86M
rpool 294G 262G 1.29K 155 165M 10.3M
rpool 294G 262G 1.50K 7 192M 89.3K
rpool 294G 262G 1.43K 116 183M 9.03M
rpool 294G 262G 1.52K 0 194M 0
rpool 294G 262G 1.39K 125 178M 10.0M
rpool 294G 262G 1.28K 119 164M 9.52M
rpool 294G 262G 1.54K 0 197M 0
rpool 294G 262G 1.39K 120 178M 9.57M
rpool 294G 262G 1.45K 0 186M 0
rpool 294G 262G 1.37K 133 175M 9.60M
rpool 294G 262G 1.38K 173 176M 10.1M
rpool 294G 262G 1.61K 0 207M 0
rpool 294G 262G 1.47K 125 189M 10.2M
rpool 294G 262G 1.56K 0 200M 0
rpool 294G 262G 1.38K 124 177M 10.2M
rpool 294G 262G 1.37K 145 175M 9.95M
rpool 294G 262G 1.51K 28 193M 359K
rpool 294G 262G 1.32K 171 169M 10.1M
rpool 294G 262G 1.55K 0 199M 0
rpool 294G 262G 1.29K 119 165M 9.48M
rpool 294G 262G 1.11K 110 142M 8.36M
rpool 294G 262G 1.43K 0 183M 0
rpool 294G 262G 1.36K 118 174M 9.32M
rpool 294G 262G 1.49K 0 190M 0
rpool 294G 262G 1.35K 118 173M 9.32M
rpool 294G 262G 1.32K 146 169M 10.1M
rpool 294G 262G 1.07K 29 137M 363K 262144+0 records in
rpool 294G 262G 0 79 0 4.65M 262144+0 records out
rpool 294G 262G 0 0 0 0
rpool 294G 262G 0 0 0 0
rpool 294G 262G 0 0 0 0
rpool 294G 262G 0 0 0 0
rpool 294G 262G 0 0 0 0
rpool 294G 262G 0 0 0 0
root@zone1:~# zpool iostat 3
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
rpool 292G 264G 0 21 22.6K 130K
rpool 292G 264G 0 0 0 0
rpool 292G 264G 0 0 0 0
rpool 292G 264G 1.03K 0 131M 0 ajordan@zone1:~/mnt/test$ dd if=test8k.tst of=test8k.2 bs=8k
rpool 292G 264G 1.10K 202 141M 16.4M
rpool 292G 264G 1.25K 25 161M 316K
rpool 292G 264G 960 215 120M 15.5M
rpool 292G 264G 1.25K 0 160M 0
rpool 292G 264G 1K 210 128M 14.8M
rpool 292G 264G 1010 159 126M 14.3M
rpool 292G 264G 1.28K 0 164M 0
rpool 292G 264G 1.08K 169 138M 15.6M
rpool 292G 264G 1.25K 0 161M 0
rpool 292G 264G 1.00K 166 128M 15.3M
rpool 293G 263G 998 201 125M 15.1M
rpool 293G 263G 1.19K 0 153M 0
rpool 293G 263G 655 161 82.0M 14.2M
rpool 293G 263G 1.27K 0 162M 0
rpool 293G 263G 1.02K 230 130M 12.7M
rpool 293G 263G 1.02K 204 130M 15.5M
rpool 293G 263G 1.23K 0 157M 0
rpool 293G 263G 1.11K 162 142M 14.8M
rpool 293G 263G 1.26K 0 161M 0
rpool 293G 263G 1.01K 168 130M 15.5M
rpool 293G 263G 1.04K 215 133M 15.5M
rpool 293G 263G 1.30K 0 167M 0
rpool 293G 263G 1.01K 210 129M 16.1M
rpool 293G 263G 1.24K 0 159M 0
rpool 293G 263G 1.10K 214 141M 15.3M
rpool 293G 263G 1.07K 169 137M 15.6M
rpool 293G 263G 1.25K 0 160M 0
rpool 293G 263G 1.01K 166 130M 15.0M
rpool 293G 263G 1.25K 0 160M 0
rpool 293G 263G 974 230 122M 15.8M
rpool 293G 263G 1.11K 160 142M 14.4M
rpool 293G 263G 1.26K 0 161M 0
rpool 293G 263G 1.06K 172 136M 15.8M
rpool 293G 263G 1.27K 0 162M 0
rpool 293G 263G 1.07K 167 136M 15.4M
rpool 293G 263G 1011 217 126M 15.8M
rpool 293G 263G 1.22K 0 156M 0
rpool 293G 263G 569 160 71.2M 14.6M 131072+0 records in
rpool 293G 263G 0 0 0 0 131072+0 records out
rpool 293G 263G 0 98 0 1.09M
rpool 293G 263G 0 0 0 0
rpool 293G 263G 0 0 0 0
rpool 293G 263G 0 0 0 0
真棒的回答，谢谢。我想区块大小应该总是匹配的。但是对于可变工作负载，块大小应该是多少？高估平均工作负载块大小还是低估平均工作负载块大小更好？嗯，我看到你在上面也问过这个问题--“关于ZFS的recordsize是可变的说法如何？”--recordsize是一个可变属性，因为文件系统将以该大小（假设默认值为128k）或更小的大小保存块。如果文件大于128k，它将被分成128k块。尝试将记录大小与存储的块大小相匹配，或者是它的倍数（永远不要小于）--这是一个大主题，这里有一个不错的链接：