ZVOLに加えてNTFSの8Kbクラスターサイズの欠点は？
ZVOLでWindows VM）のパフォーマンスを最大化しようとしています。公式の推奨事項は、zvolのアロケーションユニットサイズ（volblocksize）を配置したいアロケーションユニットサイズに揃えることです。 ZVOL上。Windowsの場合、4Kbのvolblocksizeになります。 http://open-zfs.org/wiki/Performance_tuning#Dataset_recordsize
ただし、volblocksizeが小さいとZFSのパフォーマンスが低下するとも言われており、このスレッドでは、さまざまな推奨事項が示されています。 http://list.zfsonlinux.org/pipermail/zfs-discuss/2017-September/029227.html
ZFSをデフォルトの8Kbブロックサイズのままにして、Windowsインストールを通常の4kbではなく8Kbブロックでフォーマットするのが最善かどうか疑問に思っています。これはNTFSファイルの圧縮がないことを意味することを理解しており、少なくともそれをやめようと思っています。
私の考えでは、ZVOLが8kbブロックをアドレス指定する場合、NTFSを8kbに設定しても正味のストレージスペースペナルティは発生しません。これは正しいです？これがひどい考えであるかもしれない他の理由はありますか？
FWIW、逸話的なパフォーマンスの数値を信頼することはほとんど不可能です。個々のデータポイントとセットアップの間で大きく異なる可能性があります。 （重複排除を使用していましたか？システムに十分なRAMがありましたか？ディスクの1つが失敗する寸前でしたか？使用していたデータ冗長性構成は何ですか？これは同期書き込みの前または後でしたか？ 2倍速くなりました ？リストはどんどん増えていきます。）
リンクしたガイドライン ここ は正しいです：
部分的なレコード書き込みでは、データをARC（安価）またはディスク（高価）から読み取る必要があります。
recordsizeは、512バイトから128キロバイトまでの2の累乗に設定できます。固定レコードサイズで書き込むソフトウェア（データベースなど）は、一致するrecordsizeを使用することでメリットが得られます。
そしてすぐ下...
Zvolには、レコードサイズに類似した
volblocksizeプロパティがあります。デフォルトのサイズは8KBです。これは、SPARCアーキテクチャのページのサイズです。より小さいサイズのIOを使用するワークロード（4096バイトのページを使用するx86のスワップなど）は、小さいvolblocksize。
ただし、その解釈は少しずれています。つまり、IO yourdatabaseのサイズに一致させる必要があるということです。 -）は（upIOスタック）を発行しますが、基盤となるハードウェアのブロックサイズ（downIOスタック）。
そのアドバイスは正しいです（そして私が正しく理解していれば8KiB volblocksizeを使用したいというあなたの願望と一致します）ZFS内で圧縮を行いたいと仮定します（ext4とXFSはそうではないのでゲストがLinuxの場合は基本的に唯一のオプションです圧縮を行います）。この構成では、読み取り-変更-書き込みまたは余分なスペースの消費が原因で、ストレージのオーバーヘッドは発生しません。リンクしたメーリングリストメッセージを信じるなら、これは、多くの4KiBブロックを書き込むときにZFSがヒットするボトルネックをわずかに減らすことにもなるでしょう。
ただし、NTFSは圧縮を実行できるため、何らかの理由で代わりにNTFSの圧縮を使用する場合は、volblocksizeを基になるディスクのブロックサイズと等しくして、NTFSに圧縮するための可能な最小単位を指定する必要があります（圧縮データを次のブロックサイズに切り上げる必要があるときに無駄になるスペースを最小限に抑え、NTFSの論理ブロックサイズをデータベースの目的のブロックサイズと一致させます。これにより、読み取り-変更-書き込みまたは余分なスペースによるストレージオーバーヘッドも発生しません。