Date: Fri, 14 Jan 2022 10:53:07 -0800 From: Pete Wright <pete@nomadlogic.org> To: questions@freebsd.org Subject: Re: zero filling a storage device (was: dd and mbr) Message-ID: <99ef4cd0-53a8-2c42-ca3b-990195daa805@nomadlogic.org> In-Reply-To: <20220114181021.6c92db75@archlinux> References: <77680665-7ddb-23c5-e866-05d112339b60@holgerdanske.com> <20220114023002.GP61872@eureka.lemis.com> <YeDryNdYe1S20wd2@neutralgood.org> <20220114045558.GQ61872@eureka.lemis.com> <20220114180039.4a1cf88e@archlinux> <20220114181021.6c92db75@archlinux>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/14/22 09:10, Ralf Mardorf wrote: > On Fri, 14 Jan 2022 18:00:39 +0100, Ralf Mardorf wrote: >> Hi, >> >> zero filling is fishy for several reasons. It's never secure! >> However, I won't comment zero filling. I'm not an expert and to lazy to >> search for links. >> >> Related to the addressable blocks and real physical locations I've got >> a link at hand. >> >> On Fri, 14 Jan 2022 15:55:58 +1100, Greg 'groggy' Lehey wrote: >>> proof of the contrary >> Due to >> https://en.wikipedia.org/wiki/Wear_leveling >> the only way that could be (but not necessarily is) secure, is a secure >> erase command provided by the firmware. >> >> Regards, >> Ralf > PS: IIRC SSDs provide more disk space under the hood, than accessible by > a user. So you can't outwit wear leveling by overwriting the complete > disk. Probably it's still better to overwrite the complete accessible > disk space, than not to do so. > it depends on device but this is a common practice for low latency key/value stores like Aerospike. granted apps making using this have to have pretty specific knowledge of the underlying SSD device to fully exploit any latency gains. The industry term is Over-Provisioning: https://www.samsung.com/semiconductor/global.semi.static/S190311-SAMSUNG-Memory-Over-Provisioning-White-paper.pdf https://docs.aerospike.com/operations/plan/ssd/ssd_op -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99ef4cd0-53a8-2c42-ca3b-990195daa805>