Date: Sat, 05 Jul 2014 08:36:07 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Jesse Gooch <lists@gooch.io> Cc: freebsd-hackers@freebsd.org Subject: Re: geli+trim support Message-ID: <43222.1404549367@critter.freebsd.dk> In-Reply-To: <53B750C1.8070706@gooch.io> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <53B750C1.8070706@gooch.io>, Jesse Gooch writes: >> If you TRIM, your old sector is still unchanged somewhere in flash, but >> if you're lucky for slightly less time. > >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? Yes. But "ahead of time" does not mean "now." 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". 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. There is no way to characterize any of these things, without full acces to the FLT. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43222.1404549367>