From owner-freebsd-hackers@freebsd.org Sat Nov 24 21:40:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCBF0113A6BF for ; Sat, 24 Nov 2018 21:40:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 118688D6A7 for ; Sat, 24 Nov 2018 21:40:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it1-x12e.google.com with SMTP id v11so22252409itj.0 for ; Sat, 24 Nov 2018 13:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iqpECedrwCsdc+fJ6yeYFZgtRa5/TkqxgN6Ucf6eAVs=; b=Hg8eeCsbf99WPXxtRxS2aH+uwsJuEudIEStG4pTPPOmzeFoyspMZLYO52waio5rijh EqmKZk9Wj4tYPH3qUhIy1Dl9P0csibl855NJDvRh6Oc5hhor0uikn/L7M55mdTctEuFX M+pBtBNu/zGnWSrJDsI38HPWISTh8lA/Tz+XxIfkwaWCnKpB1qLGsLlqjuW712cszHYP IHuSB7cM1Wxv6ug76n0UwPDoGjEzf8urwyPBCSSQtXOUNhal2/rJt2xsBOoAsgdw0jZN W312Uu+EumgVxrqpnHDbid/vYnMp71obnnGpa3wC5Em1XF5RdQ1tDyaiiEeUKlnbmDNT DQQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iqpECedrwCsdc+fJ6yeYFZgtRa5/TkqxgN6Ucf6eAVs=; b=P1+oS34FcR9FiBdulzKG/l7C0/qIn7iXQZi4qtDAaJAjCMntTEmqDbDoZrzNplh+oW Nq/XqExlKTLTG6L+vhmlII3/qf91Mt9+/II/bMZnmJNBnvRHHnR9XVYISglcd0Pdg7z1 oboj7llCkDmws0WCxCEJyYIS0MLkWvo4YopQ17XZlptsuIRiqywFOUBGHUpzdYfPkjTN BuVYxN9Q9X8TO8WMSKArAe0KrjPMP7V1jgJ2b5dZ5D2/o0je1DgIkiQWxTbv/T7o8sP/ LrYrO5S8aE04kVSO3hHbDvIiLlnna7TfbtW5HrPTSmT7ZUccufIoEklsPEzidj1VnfK0 ZfWw== X-Gm-Message-State: AA+aEWY1r8i5ROjPpXQxcLUe4g6/AcQZ54jHn1+dLCgFKKlR5DRiDQFq 8hTG6eFANQnOnfQlvR7wEdQsSYdtQQW3qSdmDw8BkA== X-Google-Smtp-Source: AJdET5ePedSp3WibU3EwDcp7uzaVC5h+N42MICe7clq5xTrJPOMY+WzKK8Zk9O4+hHMC6+s6+yAmH34bOEG942A4+J8= X-Received: by 2002:a24:5f94:: with SMTP id r142-v6mr18502786itb.171.1543095643259; Sat, 24 Nov 2018 13:40:43 -0800 (PST) MIME-Version: 1.0 References: <201811241705.wAOH5K8j088484@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201811241705.wAOH5K8j088484@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Sat, 24 Nov 2018 14:40:32 -0700 Message-ID: Subject: Re: TRIM utility To: "Rodney W. Grimes" Cc: Dimitry Andric , Wojciech Puchar , "freebsd-hackers@freebsd.org" , Poul-Henning Kamp , Lev Serebryakov , Eugene Grosbein X-Rspamd-Queue-Id: 118688D6A7 X-Spamd-Result: default: False [-4.71 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[e.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-1.72)[ip: (-5.14), ipnet: 2607:f8b0::/32(-1.93), asn: 15169(-1.43), country: US(-0.09)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 21:40:45 -0000 On Sat, Nov 24, 2018 at 10:05 AM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > On 24 Nov 2018, at 15:44, Wojciech Puchar wrote: > > > > > >> Yes. It would. That's hard with the current storage stack to do via > the > > >> disk interface. And often the underlying protocols do not support > partial > > >> ranges. There is no good way to do this with buf/bio interface we > have. So > > > > > > what is an actual difference between "secure erase" and trimming whole > disk? > > I wonder if any drive recognises a single trim command > that covers the whole drive, or if that is even possible > to do. Or if it recognizes that all blocks are infact > in a free/trimmed state (should be easy if they have > a total block inuse counter, just watch for it to hit 0). > TRIM is a logical operation. And it's limited to ~32GB in ATA. Lots of TRIMs will trigger garbage collection, which is what causes the erase blocks to be physically erased so they can be used for future writes. > > > It depends a lot on the device. Some devices encrypt all blocks > > automatically, and a Secure Erase command might just throw away the key, > > not go over all the data and actively wipe it. > > > > Most SSDs will likely also trim all the blocks to be erased, since users > > have come to expect the SSD performance to go back to the 'out of box' > > level, after such an operation. > > I do not think they actually "trim" anything, I am pretty > sure they just do a full FDT re-initializse and keep the > block use counters for future allocations, in effect this > looks like you trimmed the whole drive but usually completed > in just a fex seconds or less. > TRIM and Secure Erase are different beasts. TRIM is a logical operation that unmaps a LBA to physical mapping and does nothing more (though that unmapping may cause other things to happen indirectly). TRIMs also have to conform to certain behavior characteristics spelled out in the standards, so at the very least trimming the whole drive requires that, for drives that report back 0's or 1's for trimmed sectors, it write out records that say the blocks were unmapped in case there's a power outage before it can get to erasing things. Such SSDs are somewhat rare these days. Most take more than a few seconds to trim the entire drive. At least so my experience has shown. > Some manufactures actually recommend this procedure to > revive a drives performance that has degraded over time. > p Most recommend secure erase to restore performance because it knows it can do certain operations cheaply than lots of incremental trims might make harder to know. > > > > If you are lucky, the manufacturer's documentation will explain the > > specifics, but don't count on it. :) > > And there is that problem :-( > Not really. It depends on what you are using the tool for. TRIM is just an operation that un-does mappings. Secure Erase and Sanitize make the drive's contents unavailable to the host (though maybe not determined adversaries with access to the NAND chips). The reason the specs are nailed down 100% is because there's a number of NAND cell / block failures that make guarantees impossible. And the vendor may not implement any feature to 'restore factory new speed' in its drives, either because it believes its FTL never slows down (super high end) or because they don't care (super low end). Warner Warner