Date: Wed, 9 Jul 2014 10:22:20 -0600 From: Warner Losh <imp@bsdimp.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-hackers@freebsd.org, Jesse Gooch <lists@gooch.io> Subject: Re: geli+trim support Message-ID: <20856DE3-6622-455D-9B15-B4723D75B0DB@gmail.com> In-Reply-To: <43222.1404549367@critter.freebsd.dk> References: <alpine.BSF.2.00.1407020036280.4507@wojtek.tensor.gdynia.pl> <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io> <60445.1404461976@critter.freebsd.dk> <53B750C1.8070706@gooch.io> <43222.1404549367@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 5, 2014, at 2:36 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> = wrote: > In message <53B750C1.8070706@gooch.io>, Jesse Gooch writes: >=20 >>> If you TRIM, your old sector is still unchanged somewhere in flash, = but >>> if you're lucky for slightly less time. >>=20 >> Perhaps I misunderstand TRIM, isn't the point of TRIM that it zeroes = out >> the sector ahead of time so it doesn't have to re-do it again when it >> stores more data in that sector later? >=20 > Yes. >=20 > But "ahead of time" does not mean "now." >=20 > It's a fairly lenghty explanation, but the short version is that = TRIM'ing > a sector means that the FTL knows you don't care about the contents of > the sector, so it need not be preserved during "washes". >=20 > When the washes actually happen depends on how large the actual = free-pool > is and very strongly on if an eraseblock happens to be all TRIM'ed and > finally on the wear-levelling algorithm and the characteristics of the > flash that informs it. >=20 > There is no way to characterize any of these things, without full > acces to the FLT. The only way to be sure the data is gone is a secure erase. And even = then it can only be on a best-effort basis because the NAND chips=92 charge = pumps can and do fail and once that happens, you can no longer erase anything on that part. Other than that, PHK is right: the FTL decides when it will =93groom=94 = or =93garbage collect=94 the old erase block that contains the disk block that you = just trimmed. The erase block is hundreds of pages long. Each page holds several disk = blocks in a typical implementation. The NAND flash simply cannot program on a sub-page basis[*], program a page twice[**] or erase with any = granularity smaller than an erase block. The one thing that PHK forgot to mention is that flash devices are laid = out in a log fashion, e.g. the next written block follows the previously written = block (more or less) in the physical NAND media, which is why the FTL is involved at all. = Again, this is due to pages and erase blocks and the write once then erase physics = of NAND. Warner [*] Well, in some rare edge cases you can, but most modern chips don=92t = let you do that reliably, and certainly not for previously programmed pages in a = fully programmed block. [**] the firmware usually prevents you from doing this, especially in = MLC designs where you program the cells twice with data from two different pages, but = that=92s a different kettle of fish...=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20856DE3-6622-455D-9B15-B4723D75B0DB>