From owner-freebsd-stable@FreeBSD.ORG Tue Mar 11 20:48:01 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B43DABD for ; Tue, 11 Mar 2014 20:48:01 +0000 (UTC) Received: from smtp.LaTech.edu (smtp.LaTech.edu [138.47.18.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4932DED1 for ; Tue, 11 Mar 2014 20:47:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.LaTech.edu (Postfix) with ESMTP id 3614C2A96C for ; Tue, 11 Mar 2014 15:47:58 -0500 (CDT) X-Virus-Scanned: amavisd-new at latech.edu Received: from smtp.LaTech.edu ([127.0.0.1]) by localhost (smtp.latech.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id R5Yy70b49nfO for ; Tue, 11 Mar 2014 15:47:56 -0500 (CDT) Received: from smtp.LaTech.edu (localhost [127.0.0.1]) by smtp.LaTech.edu (Postfix) with ESMTP id 6BB5D2A964 for ; Tue, 11 Mar 2014 15:47:56 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=latech.edu; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type; s=latech; bh=pnGWvjRxDKeqHc3VozNSK+fcq9w=; b=thh+ KBkGJAkFkKB/xPakRzaFeDrx1XkTNOdgaj9AGAWv2JY69Y92P2iZhymRrS16uRUt XI2pqf1Tyi71bmBh9puR4h5PtNavEw3BGIwNbBJsH9+msDwZN0G8SRJ78BRe7DUu MQXsXRkcDm/5d0sEP/YAzuVTCqicFXBK2nM8IMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=latech.edu; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type; q=dns; s=latech; b=jChjCXWp3J7M72XnKgL+aR3Fri9f7q pYyoZAwjod+wWd0PuwXiUEUAcol3GU6qR8CxhXgAKqCgMm/Cbs0kyKGKkWn3vNc+ 7A2JBEGibJD/DfQIGNd8Az3TsUs5C4ORZRO4d/EZfFG/q+vQAYAmfl2QsfubNcWj c5g5eBoHtNfP8= Received: from atlantis.latech.edu (atlantis.LaTech.edu [138.47.18.149]) by smtp.LaTech.edu (Postfix) with ESMTPSA id 689782A963 for ; Tue, 11 Mar 2014 15:47:56 -0500 (CDT) Message-ID: <531F767C.3040105@LaTech.edu> Date: Tue, 11 Mar 2014 15:47:56 -0500 From: Danny Schales User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: ZFS UNMAP performance References: <531F2BA0.6000105@LaTech.edu> <531F3503.8090403@LaTech.edu> In-Reply-To: <531F3503.8090403@LaTech.edu> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BUthNRlOpV9ItuNsoTflpcHRfJsGwRMOI" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 20:48:01 -0000 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 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--