Date: Sat, 24 Nov 2018 14:40:32 -0700 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> Cc: Dimitry Andric <dim@freebsd.org>, Wojciech Puchar <wojtek@puchar.net>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Lev Serebryakov <lev@freebsd.org>, Eugene Grosbein <eugen@grosbein.net> Subject: Re: TRIM utility Message-ID: <CANCZdfquapKmVBHV4Cr_ammaj-LLaeyUvvOoDpvBH7%2BLabHyPA@mail.gmail.com> In-Reply-To: <201811241705.wAOH5K8j088484@pdx.rh.CN85.dnsmgr.net> References: <CEF0AC1C-71C5-4CD3-A5A4-7A982D985F73@FreeBSD.org> <201811241705.wAOH5K8j088484@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <wojtek@puchar.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfquapKmVBHV4Cr_ammaj-LLaeyUvvOoDpvBH7%2BLabHyPA>