Date: Tue, 11 Mar 2014 15:47:56 -0500 From: Danny Schales <dan@LaTech.edu> To: freebsd-stable@freebsd.org Subject: Re: ZFS UNMAP performance Message-ID: <531F767C.3040105@LaTech.edu> In-Reply-To: <531F3503.8090403@LaTech.edu> References: <531F2BA0.6000105@LaTech.edu> <CAFHbX1JghVaQ3xM2OZ6jpWOs6tn=Z8epd8Om3NW_CDnZHPSdng@mail.gmail.com> <531F3503.8090403@LaTech.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BUthNRlOpV9ItuNsoTflpcHRfJsGwRMOI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/11/2014 11:08, Danny Schales wrote: > On 03/11/2014 10:48, Tom Evans wrote: >> On Tue, Mar 11, 2014 at 3:28 PM, Danny Schales <dan@latech.edu> wrote:= >>> I'm seeing very slow performance with certain operations on a ZFS >>> filesystem built on ISCSI LUN's on a 10.0 system (new ISCSI >>> implementation). The issue appears to be with BIO_DELETE operations.= >>> Monitoring the system with gstat shows expected times for read and wr= ite >>> operations, but deletes are in the multiple hundreds of milliseconds >>> under normal operation. Destroying a snapshot sends the times to >>> astronomical levels. sysctl says the system is using UNMAP for delet= es: >>> >>> kern.cam.da.0.delete_method: UNMAP >>> >>> I searched and found where Oracle issued a performance alert for Sola= ris >>> 11.1 where ZFS using UNMAP was in use. Here's a link to a blog >>> discussing it: >>> >>> http://schalwad.blogspot.com/2013/12/solaris-111-zfs-write-performanc= e.html >>> >>> >>> Is FreeBSD also impacted? If so, is there a fix or a workaround? >> > The backend is an ISCSI LUN from a SAN (Dell Compellent). From > research, it seems the SAN *does* support SCSI UNMAP requests for > deletes, but the performance is horrible. I don't know if this is a > FreeBSD issue or a Compellent issue. I haven't seen the problem with > other devices, but I don't think anything else is using UNMAP (yet). >=20 > Danny >=20 >=20 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? 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 Danny --BUthNRlOpV9ItuNsoTflpcHRfJsGwRMOI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlMfdnwACgkQymYKbvs0SzH9zQCfcpTzXtFlMQUqqpM5d41Zsqc+ +eAAnilAWzm7gS0zPf5plHEZ+ouwvISd =OoGP -----END PGP SIGNATURE----- --BUthNRlOpV9ItuNsoTflpcHRfJsGwRMOI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?531F767C.3040105>