netatalkでの共有を止めて、zvol+iSCSIへ移行したわけですが、どうにもディスク消費量が大きすぎるのが気になってました。
zfs create -sVにて疎ボリュームで作成したんで、使用したら使用した分だけディスク消費するようにしてました。
すると、実容量に対し管理領域なんかで数％ふえるのはあり得る話しだけども、2TBのファイル置くだけで2.6TBも消費していて明らかにおかしい…。
そんなわけで、volblocksizeを疑ってテストしてみました。
用意した1GBiの書込みファイル。dd if=/dev/random of=test.data bs=1048576 count=1024
今回は-sオプション使わず、普通にzfs create -V 2Gで確保しました。
| blocksize | USED | REFER |
|---|---|---|
| 8kB | 2.06G | 1.35G |
| 16kB | 2.03G | 1.01G |
| 32kB | 2.02G | 1.00G |
| 64kB | 2.01G | 1.00G |
| 128kB | 2.01G | 1.00G |
FreeBSDでzvolを作成すると、デフォルトではblocksizeは8kBに設定されます。
しかし結果を見てみると、8kBだけ明らかにREFERの上昇が激しいです。
REFERは実際に消費されているサイズというより「書込みで使用済みとなったサイズ」なので、CoW的な動きされると「書込んだけど今は使ってない」領域が存在し、それらがカウントされているのかと思います。
それでも8kBだけこれだけ差があると、ちょっと気持ち悪い…。
blocksizeによる実際のディスク消費量の違いは、USEDの値を見るのが妥当なところかな。それでも8kBだと約3%と、ちょい多い。
パフォーマンスについては、下記のサイトで検証されていて、あんまり影響は無い模様。
っていうか、FreeNASでは16kBがデフォルトなんですね。
ディスクケチりたいので128kBにしたいところですが、なんとなくビビって64kBに設定してzvol作り直しましたとさ。
APFS自体がCoWっぽい振舞するので、zfsの疎ボリューム機能使っても無駄にしかならないので、ギリギリサイズで確保して都度、volサイズを拡張することにしました。
おまけ：zvol/iSCSI/APFS運用でのvolサイズ拡張について
ディスク容量が手狭なんで、必要最低限のzvol確保しておいて、足りなくなったらちょっとづつ拡張していく作戦。
試しに# zfs set volsize=2T hddvol/scsivolみたいな感じで拡張してみましたところ、dmesgにこんな感じのログが。
GEOM_PART: zvol/hddvol/scsivol was automatically resized.
Use `gpart commit zvol/hddvol/scsivol` to save changes or `gpart undo zvol/hddvol/scsivol` to revert them.GEOM_PARTがサイズの変更を感知して、GPTを修正するかどうか？って聞いてるっぽい。因みに無視して進めようとすると、zvolが使用中とかでアクセス出来ません。
gpart commit zvol/hddvol/scsivolって実行すると、良きに計らってくれるようで。
追記：2020/12/16
容量拡張時には、FreeBSD側でgpart commitしておかないと、Mac側でのボリューム拡張に失敗する模様。
パーティションテーブルもMacの管理下だろう…と、volmode=devとかしてFreeBSD側からのgeom通したパーティション操作禁止したら嵌まった…。
