Date: Mon, 14 May 2018 15:37:43 -0500 From: Eric Borisch <eborisch@gmail.com> To: =?UTF-8?Q?Karli_Sj=C3=B6berg?= <karli@inparadise.se> Cc: Paul Esson <paul.esson@redstor.com>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: Releasing deleted blocks from a sparse ZVOL Message-ID: <CAMsT2=k%2BcW7GheH945rp-hX4Er6rpUvrRghXEgj1=VchdEotxQ@mail.gmail.com> In-Reply-To: <FCD89CD5-B86F-41EB-A30B-6ABF67D4630A@inparadise.se> References: <AM5PR0102MB2578E94BA1F8894339FEB93C9E9C0@AM5PR0102MB2578.eurprd01.prod.exchangelabs.com> <FCD89CD5-B86F-41EB-A30B-6ABF67D4630A@inparadise.se>
next in thread | previous in thread | raw e-mail | index | archive | help
I've had success in a similar config by attaching the zvol as 'ahci-hd', which shows up as a 'BHYVE SATA DISK' in a BSD guest. With such a guest (running a zpool on the attached device): kstat.zfs.misc.zio_trim.failed: 0 kstat.zfs.misc.zio_trim.unsupported: 0 kstat.zfs.misc.zio_trim.success: 179883 kstat.zfs.misc.zio_trim.bytes: 13126696960 Also working with a linux guest. I see the expected tracking of the 'logicalreferenced' size in the host with the ALLOC size in the guest (allowing for upward bias due to using 32k sector sizes on my zvols). Note that TRIM and UNMAP are two extremely similar but distinct (used for SATA & SCSI, respectively) commands. Both are commonly referred to as 'trim' by layers above the device drivers. - Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMsT2=k%2BcW7GheH945rp-hX4Er6rpUvrRghXEgj1=VchdEotxQ>