Date: Sat, 24 Nov 2018 09:05:20 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Dimitry Andric <dim@FreeBSD.org> Cc: Wojciech Puchar <wojtek@puchar.net>, Warner Losh <imp@bsdimp.com>, FreeBSD Hackers <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: <201811241705.wAOH5K8j088484@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <CEF0AC1C-71C5-4CD3-A5A4-7A982D985F73@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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). > 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. Some manufactures actually recommend this procedure to revive a drives performance that has degraded over time. > > If you are lucky, the manufacturer's documentation will explain the > specifics, but don't count on it. :) And there is that problem :-( -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201811241705.wAOH5K8j088484>