From owner-freebsd-stable@FreeBSD.ORG  Wed Mar 12 10:16:43 2014
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
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 EDF2396B
 for <freebsd-stable@freebsd.org>; Wed, 12 Mar 2014 10:16:43 +0000 (UTC)
Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id 951EB7C6
 for <freebsd-stable@freebsd.org>; Wed, 12 Mar 2014 10:16:43 +0000 (UTC)
Received: from [194.32.164.24] (80-46-130-69.static.dsl.as9105.com
 [80.46.130.69])
 by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id s2CA1NAM093217;
 Wed, 12 Mar 2014 10:01:24 GMT (envelope-from rb@gid.co.uk)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: ZFS UNMAP performance
From: Bob Bishop <rb@gid.co.uk>
In-Reply-To: <531FAA20.7080407@latech.edu>
Date: Wed, 12 Mar 2014 10:01:18 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <C7680FD4-885B-4295-9D82-AB1CF869B928@gid.co.uk>
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>
To: Danny Schales <dan@LaTech.edu>
X-Mailer: Apple Mail (2.1874)
Cc: freebsd-stable@freebsd.org
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 10:16:44 -0000

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