From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 9 16:22:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0260CE8 for ; Wed, 9 Jul 2014 16:22:32 +0000 (UTC) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B725B2FDE for ; Wed, 9 Jul 2014 16:22:32 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id c1so2065434igq.1 for ; Wed, 09 Jul 2014 09:22:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type:mime-version:subject :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1cQjE1beu1wGcPJypj2Z0uqWKM6sCd3mFNtoW6xqT6k=; b=eXeOSntvFpzBFMd1hAWp5S3XaoNl6Pc0rRwxPFlQ68816Iijp1aBnm1zJHAI+v0Vcb nCSCsxBflVhU+yK7B9IqeyHEASZhgbF+DzJSSeocyxkfXIap5QoES/icnQudFb11nymK nQ8BRHwquxJ7nk/cVJMPp/c64EP/CTFFx+Um2pyDSZJoRGdAA6pgFaVt9Oc7JS1GrWjT ubB56iHs1iIlPccMkZDiwJAidrlr1y62s1ZpRHgyvcLEDBGeKwcxbt+rHHLTeDeO3pQQ CB33RZBfTkVqi2C/jMDYPLE4lOTAIrfyjD8cMOlfIJHdPmIjZcZ3LA2Bc7QZfa/EFWE6 FH+g== X-Gm-Message-State: ALoCoQk+x3zmRSGuHzphOnrWgZXOsU6rktLrCTkWeEx2n0wriSbYDOBmIy3DQL6/XFr1yBTHwAvS X-Received: by 10.50.164.201 with SMTP id ys9mr14698731igb.40.1404922946423; Wed, 09 Jul 2014 09:22:26 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id z6sm16720535igl.1.2014.07.09.09.22.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 09:22:25 -0700 (PDT) Sender: Warner Losh From: Warner Losh X-Google-Original-From: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: geli+trim support In-Reply-To: <43222.1404549367@critter.freebsd.dk> Date: Wed, 9 Jul 2014 10:22:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <20856DE3-6622-455D-9B15-B4723D75B0DB@gmail.com> References: <7E2718485A3E405D89E5EAB331E9ED70@multiplay.co.uk> <53B6427D.1010403@gooch.io> <60445.1404461976@critter.freebsd.dk> <53B750C1.8070706@gooch.io> <43222.1404549367@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-hackers@freebsd.org, Jesse Gooch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:22:33 -0000 On Jul 5, 2014, at 2:36 AM, Poul-Henning Kamp = 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...=