Date: Sat, 30 Apr 2011 02:16:24 -0700 From: Julian Elischer <julian@freebsd.org> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-fs@freebsd.org, Alexander Motin <mav@freebsd.org> Subject: Re: TRIM clustering Message-ID: <4DBBD368.7000301@freebsd.org> In-Reply-To: <20110430072831.GA65598@icarus.home.lan> References: <4DBBB20A.5050102@FreeBSD.org> <20110430072831.GA65598@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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" :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DBBD368.7000301>