From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsMVory2E1VA for ; Sun, 15 Apr 2012 18:55:09 +0200 (CEST) Received: from nm12-vm0.bullet.mail.ird.yahoo.com (nm12-vm0.bullet.mail.ird.yahoo.com [77.238.189.196]) by mail.saout.de (Postfix) with SMTP for ; Sun, 15 Apr 2012 18:55:09 +0200 (CEST) Message-ID: <1334508908.81616.YahooMailClassic@web171306.mail.ir2.yahoo.com> Date: Sun, 15 Apr 2012 17:55:08 +0100 (BST) From: alban bernard In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [dm-crypt] simple ideas addressing ssd TRIM security concern List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --- On Sun, 4/15/12, Sven Eschenberg wrote: > That would render TRIMing completely > useless anyway and you could as well > turn it off. Not really if there are enough TRIMed blocks before block writes occur. There lies the purpose of a "smart" layer that will be responsible of TRIMing blocks in a certain amount of the total space: a kind of TRIMed block buffer that smooths writing zeroes and spreads them among the device the "crypto" way.