From owner-freebsd-fs@FreeBSD.ORG Fri Dec 10 05:19:57 2010 Return-Path: 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 0B8661065670; Fri, 10 Dec 2010 05:19:57 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-6.mx.aerioconnect.net [216.240.47.66]) by mx1.freebsd.org (Postfix) with ESMTP id A597B8FC17; Fri, 10 Dec 2010 05:19:56 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oBA5Js1S007869; Thu, 9 Dec 2010 21:19:54 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 6CB3A2D6012; Thu, 9 Dec 2010 21:19:53 -0800 (PST) Message-ID: <4D01B878.4020008@freebsd.org> Date: Thu, 09 Dec 2010 21:19:52 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <201012091813.oB9IDd2H078366@chez.mckusick.com> <20101210003749.3F7E15B92@mail.bitblocks.com> <20101210005838.GD1866@garage.freebsd.pl> In-Reply-To: <20101210005838.GD1866@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Kirk McKusick , Oliver Fromme , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 05:19:57 -0000 On 12/9/10 4:58 PM, Pawel Jakub Dawidek wrote: > On Thu, Dec 09, 2010 at 04:37:48PM -0800, Bakul Shah wrote: >> On Thu, 09 Dec 2010 10:13:39 PST Kirk McKusick 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). > libgeom(3) provides: > > int g_delete(int fd, off_t offset, off_t length); > One of the things that has not been mentioned is that trim 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.