From owner-freebsd-stable@FreeBSD.ORG Tue Mar 11 16:08:44 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBDB4AE6 for ; Tue, 11 Mar 2014 16:08:43 +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 99B1A973 for ; Tue, 11 Mar 2014 16:08:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.LaTech.edu (Postfix) with ESMTP id C1C8E2A422 for ; Tue, 11 Mar 2014 11:08:36 -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 lpXkOVaZfmfp for ; Tue, 11 Mar 2014 11:08:35 -0500 (CDT) Received: from smtp.LaTech.edu (localhost [127.0.0.1]) by smtp.LaTech.edu (Postfix) with ESMTP id 660772A415 for ; Tue, 11 Mar 2014 11:08:35 -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=8byw4tsOEB7K6SESEZlyuc0PuU0=; b=sZHC q4rh+fzQGv/y71+Z6/9WDPDQ022RU3vxwf9Kzkq5TOP0AsJF9K8qhPL5Fkc3mkVW /8jAQa+01k7VonuSG589WrBqXpnYbI22IqtXHPkMu2BWBpwHtOhxUq+/DpLahUgE ePX4i0ufUcIevpAC9Vf6FmWhvmtO+Vk9jR6HxT8= 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=TtbZdzOjr4Z/zwxsip+dBKk0lvy5cy 3SIDARV/Zk4QLHjN34QJ6yE9P6ksPlu5sncnj1/cEx+yyQTu8iDmgc6zWBmO0l4j 5v06T36yK+VBd/UO7PEVO98Hd+BeVa9n08QBLMIUuAvCAsBMVdwHdhQAz2L8Rbi3 YpwI/AJeCgBFM= Received: from atlantis.latech.edu (atlantis.LaTech.edu [138.47.18.149]) by smtp.LaTech.edu (Postfix) with ESMTPSA id 62DDE2A414 for ; Tue, 11 Mar 2014 11:08:35 -0500 (CDT) Message-ID: <531F3503.8090403@LaTech.edu> Date: Tue, 11 Mar 2014 11:08:35 -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> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ws0vktcTD2mUitWkSGTPQ66o6G9jGKeSd" 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 16:08:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ws0vktcTD2mUitWkSGTPQ66o6G9jGKeSd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 wri= te >> 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 delete= s: >> >> kern.cam.da.0.delete_method: UNMAP >> >> I searched and found where Oracle issued a performance alert for Solar= is >> 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-performance= =2Ehtml >> >> >> Is FreeBSD also impacted? If so, is there a fix or a workaround? >=20 > FreeBSD is affected the same way Solaris is. IMHO, neither are > affected, it is merely a consequence of using a device with a poor > TRIM/UNMAP algorithm. >=20 > You can trivially tell ZFS to not use TRIM, or tweak the tunings to > suit your devices. I'm afraid I don't know what they all mean > precisely.. >=20 > vfs.zfs.vdev.trim_on_init: 1 > vfs.zfs.vdev.trim_max_bytes: 2147483648 > vfs.zfs.vdev.trim_max_pending: 64 > vfs.zfs.trim.enabled: 1 > vfs.zfs.trim.txg_delay: 32 > vfs.zfs.trim.timeout: 30 > vfs.zfs.trim.max_interval: 1 >=20 > Of course, if you disable TRIM you will end up with new (but > different) poor performance characteristics. Probably. 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). Danny --Ws0vktcTD2mUitWkSGTPQ66o6G9jGKeSd 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) iEYEARECAAYFAlMfNQMACgkQymYKbvs0SzE50gCeOxYTP+f4ZUWSRMxIzLAwelLH QtAAn28Fqtg98S402ew+flQ+Jq2i8Ckk =vHZk -----END PGP SIGNATURE----- --Ws0vktcTD2mUitWkSGTPQ66o6G9jGKeSd--