Date: Sat, 30 Apr 2011 15:28:24 -0700 From: Julian Elischer <julian@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: TRIM clustering Message-ID: <4DBC8D08.7030000@freebsd.org> In-Reply-To: <4DBBE985.9000701@FreeBSD.org> References: <20110430072831.GA65598@icarus.home.lan> <mailpost.1304156092.7598560.10429.mailing.freebsd.fs@FreeBSD.cs.nctu.edu.tw> <4DBBE985.9000701@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/30/11 3:50 AM, Alexander Motin wrote: > Julian Elischer wrote: >> 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. > I believe any device should benefit from receiving single 128K request > instead of 8*16k. Just because of command processing overhead. Am I wrong? well if you never make the 16 k request because you are waiting for the other 112K to show up then I'd prefer the 16k request. I am not sure exactly of exact figures but I would think that about 16k would be a good cluster size for our devices.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DBC8D08.7030000>