Page MenuHomeFreeBSD

Add VIRTIO_BLK_T_DISCARD (TRIM) support to the bhyve virtio-blk backend
ClosedPublic

Authored by allanjude on Sep 18 2019, 7:19 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 17 2024, 1:34 PM
Unknown Object (File)
Mar 9 2024, 2:10 PM
Unknown Object (File)
Mar 9 2024, 2:10 PM
Unknown Object (File)
Feb 24 2024, 4:24 PM
Unknown Object (File)
Feb 15 2024, 1:55 PM
Unknown Object (File)
Jan 28 2024, 5:03 AM
Unknown Object (File)
Dec 26 2023, 2:54 PM
Unknown Object (File)
Dec 12 2023, 9:24 PM

Details

Summary

This will advertise support for TRIM to the guest virtio-blk driver and
perform the DIOCGDELETE ioctl on the backing storage if it supports it.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj added inline comments.
usr.sbin/bhyve/pci_virtio_block.c
83 ↗(On Diff #62277)

I would think that we should just be using definitions from a driver header. Not something to fix in this review though.

93 ↗(On Diff #62277)

Does this mean that a guest will by default send discard requests even when we don't support them at the blockif layer? For instance, we do not handle discards when the device is backed by a regular file.

305 ↗(On Diff #62277)

In the kernel we are hard-coding 512 instead of DEV_BSIZE. I suspect that the same should be done here (or we should use a separate constant) instead of assuming that DEV_BSIZE is always going to be 512.

jhb added inline comments.
usr.sbin/bhyve/pci_virtio_block.c
93 ↗(On Diff #62277)

Yes, but this can be fixed. It looks like block_if already has a 'bc_candelete' member we can query via blockif_candelete(). All that needs to happen is that 'struct pci_vtblk_softc' needs to grow a new pointer to track an allocated 'struct virtio_consts'. pci_vtblk_init() would then allocate a structure and initialize it by copying 'vtblk_vi_consts' into it, then adding F_DISCARD to the host_caps member optionally. Something like:

sc->vbsc_consts = malloc(sizeof(struct virtio_consts));
sc->vbsc_consts = vtblk_vi_consts;
if (blockif_candelete(bctxt))
    sc->vbsc_consts->vc_host_caps |= VTBLK_F_DISCARD;

/* init virtio softc and virtqueues */
vi_softc_linkup(&sc->vbsc_sc, sc->vbsc_consts, sc, pi, &sc->vbsc_vq);
305 ↗(On Diff #62277)

If the spec defines it as units of 512 bytes, then I agree with a bare constant and/or having a dedicated constant that is not DEV_BSIZE.

420 ↗(On Diff #62277)

How did you come up with this number?

usr.sbin/bhyve/pci_virtio_block.c
93 ↗(On Diff #62277)

Ok, that makes sense. At some point it'd make sense to handle discard on regular files by punching a hole, but I don't think we have an interface to do that. (Linux has fallocate(FALLOC_FL_PUNCH_HOLE).)

305 ↗(On Diff #62277)

Yes, the spec states that discard commands are always expressed with multiples of 512 bytes.

usr.sbin/bhyve/pci_virtio_block.c
93 ↗(On Diff #62277)

At that point the block_if.c implementation can choose to support can delete. However, sooner to happen is supporting formats like QCOW2 via libvdsk which also supports sparse disks as part of its file format and will thus support trim.

Ping. Can you confirm that this works ok with Linux guests? Also, any sense of making forward progress on using block_if_can_delete()?

jason.brian.king_gmail.com added inline comments.
usr.sbin/bhyve/pci_virtio_block.c
301 ↗(On Diff #62277)

The virtio 1.1 spec states that if the unmap bit is set (in discard) for a DISCARD request, it should return VIRTIO_BLK_S_UNSUPP.

Add VIRTIO_BLK_T_DISCARD (TRIM) support to the bhyve virtio-blk backend

This will advertise support for TRIM to the guest virtio-blk driver and perform the DIOCGDELETE ioctl on the backing storage if it supports it.

Thanks to Jason King and others at Joyent and illumos for improvements including error handling and following the virtio spec better

Contributed By: Jason King <jason.king@joyent.com> (improvements)
Obtained From: illumos-joyent (improvements)

Testing and joyent reviews: https://smartos.org/bugview/OS-8136

usr.sbin/bhyve/block_if.c
32 ↗(On Diff #70412)

Which license? I'm assuming the BSD2 clause, so this should go up in the previous license block (but after the ARR line)

Looks fine to me modulo the license statement question

This revision is now accepted and ready to land.Apr 23 2020, 4:32 PM

Move copyright message to the correct place

This revision now requires review to proceed.Apr 23 2020, 5:00 PM
This revision is now accepted and ready to land.Apr 23 2020, 5:41 PM