Date: Sat, 30 Apr 2011 13:50:45 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Julian Elischer <julian@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: TRIM clustering Message-ID: <4DBBE985.9000701@FreeBSD.org> In-Reply-To: <mailpost.1304156092.7598560.10429.mailing.freebsd.fs@FreeBSD.cs.nctu.edu.tw> References: <20110430072831.GA65598@icarus.home.lan> <mailpost.1304156092.7598560.10429.mailing.freebsd.fs@FreeBSD.cs.nctu.edu.tw>
next in thread | previous in thread | raw e-mail | index | archive | help
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? -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DBBE985.9000701>