From owner-freebsd-fs@FreeBSD.ORG  Fri Dec 10 00:37: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 7E5EE1065675;
	Fri, 10 Dec 2010 00:37:52 +0000 (UTC)
	(envelope-from bakul@bitblocks.com)
Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60])
	by mx1.freebsd.org (Postfix) with ESMTP id 63B6C8FC0A;
	Fri, 10 Dec 2010 00:37:52 +0000 (UTC)
Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1])
	by mail.bitblocks.com (Postfix) with ESMTP id 3F7E15B92;
	Thu,  9 Dec 2010 16:37:49 -0800 (PST)
To: Kirk McKusick <mckusick@mckusick.com>
In-reply-to: Your message of "Thu, 09 Dec 2010 10:13:39 PST."
	<201012091813.oB9IDd2H078366@chez.mckusick.com> 
References: <201012091813.oB9IDd2H078366@chez.mckusick.com>
Comments: In-reply-to Kirk McKusick <mckusick@mckusick.com>
	message dated "Thu, 09 Dec 2010 10:13:39 -0800."
Date: Thu, 09 Dec 2010 16:37:48 -0800
From: Bakul Shah <bakul@bitblocks.com>
Message-Id: <20101210003749.3F7E15B92@mail.bitblocks.com>
Cc: freebsd-fs@freebsd.org, pjd@freebsd.org,
	Oliver Fromme <olli@lurza.secnetix.de>
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 00:37:52 -0000

On Thu, 09 Dec 2010 10:13:39 PST Kirk McKusick <mckusick@mckusick.com>  wrote:
> Other than the nit pointed out by Pawel, the diffs look good to me.
> You should consider adding the -t option to newfs so that the TRIM
> option can be specified at the time the filesystem is created (as
> a general rule, anything you can do with tunefs should also be
> possible with newfs).
> 
> I agree with your decision to let administrators opt-out of doing
> TRIM. If experience shows it to be generally useful to have it on,
> we can change the default to enabled later. If we do change the
> default to enabled, then we will want to delete the warning about TRIM
> not being supported by the underlying disk that you added at mount
> time as we would start getting a lot of them for all the non-SSD disks.

Would be nice if something like ftrim(fd, offset, size) or
trim(path, offsetm size) or TRIM file ioctl is added, to free
up blocks undelying a given range in a file.  ftruncate can
delete blocks at the end but there is no facility to lose
blocks in the middle.  Mainly handy for virtual disks and
databases (and would work nicely with SEEK_DATA, SEEK_HOLE).