bhyve and vfs.zfs.arc_max, and zfs tuning for a hypervisor
Victor Sudakov
vas at mpeks.tomsk.su
Wed Mar 20 01:52:38 UTC 2019
Patrick M. Hausen wrote:
>
> > 1. Does ARC actually cache zfs volumes (not files/datasets)?
>
> Yes it does.
>
> > 2. If ARC does cache volumes, does this cache make sense on a hypervisor,
> > because guest OSes will probably have their own disk cache anyway.
>
> IMHO not much, because the guest OS is relying on the fact that when
> it writes it’s own cached data out to „disk“, it will be committed to
> stable storage.
This is an important point.
> > 3. Would it make sense to limit vfs.zfs.arc_max to 1/8 or even less of
> > total RAM, so that most RAM is available to guest machines?
>
> Yes if you build your own solution on plain FreeBSD. No if you are running
> FreeNAS which already tries to autotune the ARC size according to the
> memory committed to VMs.
>
> > 4. What other zfs tuning measures can you suggest for a bhyve
> > hypervisor?
>
> e.g.
> zfs set sync=always zfs/vm
>
> if zfs/vm is the dataset under which you create the ZVOLs for your emulated
> disks.
Well, bhyve already has an option for this:
The block-device-options are:
nocache Open the file with O_DIRECT.
direct Open the file using O_SYNC.
ro Force the file to be opened read-only.
I think something like
"-s 4:0,virtio-blk,/dev/zvol/zroot/vm/mail/disk0,direct"
would do the same?
>
> I’m using this for all my VM „disks“ and have added a 16 GB SLOG device
> to my spinning disk pool - seems to work great. This is on a home system.
Is SLOG also used by zfs volumes?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49 at fidonet http://vas.tomsk.ru/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20190320/d324d5f7/attachment.sig>
More information about the freebsd-virtualization
mailing list