Date: Sun, 1 May 2011 10:17:42 -0500 (CDT) From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> To: Alexander Motin <mav@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: TRIM clustering Message-ID: <alpine.GSO.2.01.1105011008340.20825@freddy.simplesystems.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 Sat, 30 Apr 2011, Alexander Motin wrote: >> >> 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? Since I have not seen it mentioned in this discussion thread yet, it is worth pointing out that if TRIM has already been issued for a block that the filesystem can not re-use that space for storage until the TRIM request is completed. Otherwise in-use blocks might get TRIMmed, resulting in filesystem destruction. If the system should spontaneously reboot, then there may be a mismatch between the filesystem's notion of free blocks and the FLASH device's notion of free blocks. In fact, if the kernel panics, the device may continue trimming blocks after the system is gone (because power is still on). Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.2.01.1105011008340.20825>