Date: Wed, 12 Mar 2014 10:01:18 +0000 From: Bob Bishop <rb@gid.co.uk> To: Danny Schales <dan@LaTech.edu> Cc: freebsd-stable@freebsd.org Subject: Re: ZFS UNMAP performance Message-ID: <C7680FD4-885B-4295-9D82-AB1CF869B928@gid.co.uk> In-Reply-To: <531FAA20.7080407@latech.edu> References: <531F2BA0.6000105@LaTech.edu> <CAFHbX1JghVaQ3xM2OZ6jpWOs6tn=Z8epd8Om3NW_CDnZHPSdng@mail.gmail.com> <531F3503.8090403@LaTech.edu> <531F767C.3040105@LaTech.edu> <531F8EAA.1020107@vangyzen.net> <531FAA20.7080407@latech.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On 12 Mar 2014, at 00:28, Danny Schales <dan@LaTech.edu> wrote: > On 3/11/2014 5:31 PM, Eric van Gyzen wrote: >>> Replying to myself...I note that the system is reporting that TRIM = is >>> being used. Is this normal for non-SSD systems? There *is* SSD in = the >>> system, but I'm pretty sure the system can't tell it's SSD (it's = hidden >>> behind a Dell PERC card). The number of trim.successes is roughly >>> equivalent to the number of deletes reported by gstat for the ISCSI = LUN >>> devices. Should the system be using TRIM for ISCSI LUNs? >> Sure, if the LUN (i.e. the storage controller) reports that it = supports >> TRIM/UNMAP. Note that this is completely unrelated to the type of = disks >> that provide the LUN's backing store. >>=20 >>> kstat.zfs.misc.zio_trim.bytes: 232845656064 >>> kstat.zfs.misc.zio_trim.success: 30810983 >>> kstat.zfs.misc.zio_trim.unsupported: 809 >>> kstat.zfs.misc.zio_trim.failed: 0 >>>=20 >>> Danny >>>=20 >>=20 >=20 > Are there any risks to turning off TRIM to see if the performance > improves (other than the loss of space recovery)? >=20 > Danny If the backing store really is SSD then turning off TRIM should hurt = write performance eventually (and read to a lesser extent). -- Bob Bishop rb@gid.co.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C7680FD4-885B-4295-9D82-AB1CF869B928>