Date: Fri, 14 Jan 2022 19:13:03 +0100 From: Ralf Mardorf <ralf-mardorf@riseup.net> To: questions@freebsd.org Subject: Re: zero filling a storage device (was: dd and mbr) Message-ID: <20220114191303.171f1cad@archlinux> In-Reply-To: <523b6b6d-b17c-e632-a36a-a8c26ad61798@qeng-ho.org> References: <77680665-7ddb-23c5-e866-05d112339b60@holgerdanske.com> <20220114023002.GP61872@eureka.lemis.com> <YeDryNdYe1S20wd2@neutralgood.org> <YeGXejPepsd4aKiE@lorvorc.mips.inka.de> <523b6b6d-b17c-e632-a36a-a8c26ad61798@qeng-ho.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Jan 2022 17:14:18 +0000, Arthur Chance wrote: >On 14/01/2022 15:32, Christian Weisgerber wrote: >> "Kevin P. Neal": >> >>> Are we certain that an SSD won't at least track that there is >>> nothing written to a logical block and therefore it must be all >>> zeros? I'm not 100% that an SSD will always keep a logical block >>> assigned to a physical block. And I'm not 100% certain that an SSD >>> won't notice that all zeros are being written to a block and just >>> optimize out the write. >> >> It's tempting to speculate that an SSD could treat an all-zeros >> block write effectively like a TRIM. >> >> I'll note that there are SSDs that compress the data written to >> them. (Compression in storage devices isn't new. Terry Welch's >> 1984 paper, where he presented the LZW compression algorithm, already >> talks about this.) >> > >May I suggest "man trim"? (From 12.1 onwards.) *?* Nothing on the operating system side of the SSD's controller (and its firmware) has got direct access to what's under the hood of the SSD. Due to wear leveling a SSD much likely keeps a lot of not really erased sensitive data. This data is not accessible/restoreable without replacing the firmware by a forensic tool or by an unhappy coincidence, but replacing firmware is way more likely, than a high-tech lab to restore secret data and even an unhappy coincidence isn't far too unlikely.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220114191303.171f1cad>