From owner-freebsd-stable@FreeBSD.ORG  Wed Mar 12 15:08:13 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 357F292F
 for <freebsd-stable@freebsd.org>; Wed, 12 Mar 2014 15:08:13 +0000 (UTC)
Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com
 [143.166.224.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id ED484874
 for <freebsd-stable@freebsd.org>; Wed, 12 Mar 2014 15:08:12 +0000 (UTC)
X-Loopcount0: from 64.238.244.148
X-IronPort-AV: E=Sophos;i="4.97,638,1389765600"; d="scan'208";a="108386886"
Message-ID: <53207816.7030104@vangyzen.net>
Date: Wed, 12 Mar 2014 10:07:02 -0500
From: Eric van Gyzen <eric@vangyzen.net>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Bob Bishop <rb@gid.co.uk>, Danny Schales <dan@LaTech.edu>
Subject: Re: ZFS UNMAP performance
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>
 <C7680FD4-885B-4295-9D82-AB1CF869B928@gid.co.uk>
In-Reply-To: <C7680FD4-885B-4295-9D82-AB1CF869B928@gid.co.uk>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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 15:08:13 -0000

On 03/12/2014 05:01, Bob Bishop wrote:
> 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.
>>>
>>>> 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
>>>>
>> Are there any risks to turning off TRIM to see if the performance
>> improves (other than the loss of space recovery)?
>>
>> Danny
> If the backing store really is SSD then turning off TRIM should hurt write performance eventually (and read to a lesser extent).

Correct.  If it's not SSD, though, the loss of space recovery should be
the only risk.  And I imagine your highest tier of storage is not SSD.

Eric