From owner-freebsd-fs@FreeBSD.ORG  Fri Dec 10 05:45:52 2010
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 08A9B1065670;
	Fri, 10 Dec 2010 05:45:52 +0000 (UTC)
	(envelope-from mckusick@mckusick.com)
Received: from chez.mckusick.com (chez.mckusick.com [64.81.247.49])
	by mx1.freebsd.org (Postfix) with ESMTP id CEBAB8FC08;
	Fri, 10 Dec 2010 05:45:51 +0000 (UTC)
Received: from chez.mckusick.com (localhost [127.0.0.1])
	by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id oBA5jkwO027291;
	Thu, 9 Dec 2010 21:45:46 -0800 (PST)
	(envelope-from mckusick@chez.mckusick.com)
Message-Id: <201012100545.oBA5jkwO027291@chez.mckusick.com>
To: Julian Elischer <julian@freebsd.org>
In-reply-to: <4D01B878.4020008@freebsd.org> 
Date: Thu, 09 Dec 2010 21:45:46 -0800
From: Kirk McKusick <mckusick@mckusick.com>
Cc: Oliver Fromme <olli@lurza.secnetix.de>,
	Pawel Jakub Dawidek <pjd@freebsd.org>, freebsd-fs@freebsd.org
Subject: Re: TRIM support for UFS? 
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Dec 2010 05:45:52 -0000

> Date: Thu, 09 Dec 2010 21:19:52 -0800
> From: Julian Elischer <julian@freebsd.org>
> To: Pawel Jakub Dawidek <pjd@freebsd.org>
> CC: Bakul Shah <bakul@bitblocks.com>, Kirk McKusick <mckusick@mckusick.com>,
>         Oliver Fromme <olli@lurza.secnetix.de>, freebsd-fs@freebsd.org
> Subject: Re: TRIM support for UFS?
> 
> One of the things that has not been mentioned is that releasing
> space in a file is not really 'free' (at least not for us) if you
> want things to remain trimmed after a reboot.  So if I were
> implementing it I'd want a couple of parameters.
> 
> 1/ don't bother trimming free space under some size.
>
> 2/ does it matter if the trimmed space comes back as garbage
> after an unclean shutdown? (a hint to the driver, and no, I don't
> know anyone that supports this yet)
> (there are security implications to that one but cheap trim (that
> may come back) is way cheaper than persistent trim to impliment).
> 
> With these parameters we (fusion-io) could tune our behaviour
> which can save performance, and also the file system could tune
> it's min-trim value to see what gives best performance.

The above is one of the reasons that we never implemented the
`release' system call. To be stable after a crash requires either
a lot of synchronous writes or a bunch more soft update dependencies.
Many of the same issues relate to stability of snapshots across
system crashes. In the end we added the dopersistence flag:

/*
 * To ensure the consistency of snapshots across crashes, we must
 * synchronously write out copied blocks before allowing the
 * originals to be modified. Because of the rather severe speed
 * penalty that this imposes, the following flag allows this
 * crash persistence to be disabled.
 */
int dopersistence = 0;
         
#ifdef DEBUG
#include <sys/sysctl.h>
SYSCTL_INT(_debug, OID_AUTO, dopersistence, CTLFLAG_RW, &dopersistence, 0, "");
#endif /* DEBUG */

As you can see it defaults to off.

	Kirk McKusick