From owner-freebsd-geom@FreeBSD.ORG Mon Dec 30 23:24:54 2013 Return-Path: Delivered-To: freebsd-geom@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 C1569797 for ; Mon, 30 Dec 2013 23:24:54 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 899B11A5E for ; Mon, 30 Dec 2013 23:24:54 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id rBUNOqlc069822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Dec 2013 23:24:53 GMT Date: Mon, 30 Dec 2013 23:24:52 +0000 From: Karl Pielorz To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-geom@FreeBSD.org Subject: Re: Is TRIM working with gmirror? Message-ID: <18C59233568D3A475FF0D843@study64.tdx.co.uk> In-Reply-To: <52A90049.7050001@quip.cz> References: <52A90049.7050001@quip.cz> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 23:24:54 -0000 --On 12 December 2013 01:16:09 +0100 Miroslav Lachman <000.fbsd@quip.cz> wrote: > Is TRIM working on gmirror? > > I have FreeBSD 8.4-RELEASE-p1 amd64 GENERIC machine with 2x SSDs: ... > But there is a WARNING at boot: > > WARNING: /ssd_db: TRIM flag on fs but disk does not confirm that it > supports TRIM > > The filesystem is classic UFS2. > > Is TRIM supported throught gmirror, or not? I think 8.4 is way too old for this. I have a number of 9.2 boxes - and even on those, TRIM doesn't propagate through gmirror *yet* (at the time, which is a few months ago I seem to remember reading 'It should work soon' - but 9.2 doesn't appear to). You can use gstat to show if any calls to BIO_DELETE are being made - i.e. gstat -d On the systems here the 'd/s' (which afaik is 'BIO_DELETE/second') remains stubbornly at zero :( The flipside is with decent SSD's these days TRIM isn't quite so important... Some may even argue that *not* issuing heaps of BIO_DELETE on the I/O channel is actually faster - so long as the SSD has time to play catchup and isn't pegged all the time, I think they may be right :-) -Karl