From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 09:34:31 2011 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 CDC1A106564A for ; Sat, 30 Apr 2011 09:34:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8D8AB8FC16 for ; Sat, 30 Apr 2011 09:34:31 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p3U9FQJK092375 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 30 Apr 2011 02:15:28 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4DBBD368.7000301@freebsd.org> Date: Sat, 30 Apr 2011 02:16:24 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jeremy Chadwick References: <4DBBB20A.5050102@FreeBSD.org> <20110430072831.GA65598@icarus.home.lan> In-Reply-To: <20110430072831.GA65598@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Alexander Motin Subject: Re: TRIM clustering 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: Sat, 30 Apr 2011 09:34:31 -0000 On 4/30/11 12:28 AM, Jeremy Chadwick wrote: > On Sat, Apr 30, 2011 at 09:54:02AM +0300, Alexander Motin wrote: >> I've noticed that on file deletion from UFS with TRIM enabled, kernel >> issues BIO_DELETE for each 16K (block size?) separately -- thousands per >> second for single big file deletion. Fortunately ada driver will try to >> aggregate them for the device, but won't some clustering code worth to >> be there? > I'd like to know who decided it would be best to submit the TRIM command > automatically on every single block that is deemed free by UFS during > inode removal. The performance hit, from what I've been reading, from > doing this is quite severe. Many SSDs take hundreds of milliseconds to > complete TRIM operations, which greatly impacts filesystem performance. > I appreciate the efforts to get TRIM into FreeBSD for UFS, but the > implementation -- if what Alexander says is accurate -- seems like a bad > choice. well not all devices take it as a hit.. The suggestion of some sort of clustering is a good one but it should be tunable. > Sorry for the long-winded Email, but when I see/read about things like > what mav@ has brought up, I become immediately concerned (as someone who > has many production systems using Intel X25-M and Intel 320-series SSDs > for /, swap, /var, /tmp, and /usr). all of which I'd class as "really slow" :-)