From nobody Fri Jan 14 18:53:07 2022 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6B1E8195F222 for ; Fri, 14 Jan 2022 18:53:17 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jb9Rc1kngz3j5s for ; Fri, 14 Jan 2022 18:53:16 +0000 (UTC) (envelope-from pete@nomadlogic.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1642186388; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zOXZ90Ta4Ho0wgwadtpUdnd9bCNBcsLD9HgnsyecFks=; b=FZ1UGBJ6oe1OG9F6lb5LY6tSAppqGbWDWJJjRJU1oKBnSMeDmgpVicH8qq9AtxYbRzSdIZ MyXpw3aP2lzQBI7Nqq9R7dxmuVQpGLPGvvLTJgZx/G59x3VNKPkl44h5sFbHBGBo66al/C UqyojeZZKfghfqg1wjL/3ekewV3zuTc= Received: from [192.168.1.160] (cpe-24-24-163-126.socal.res.rr.com [24.24.163.126]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 8ff1c5f9 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Fri, 14 Jan 2022 18:53:07 +0000 (UTC) Message-ID: <99ef4cd0-53a8-2c42-ca3b-990195daa805@nomadlogic.org> Date: Fri, 14 Jan 2022 10:53:07 -0800 List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: zero filling a storage device (was: dd and mbr) Content-Language: en-US To: questions@freebsd.org References: <77680665-7ddb-23c5-e866-05d112339b60@holgerdanske.com> <20220114023002.GP61872@eureka.lemis.com> <20220114045558.GQ61872@eureka.lemis.com> <20220114180039.4a1cf88e@archlinux> <20220114181021.6c92db75@archlinux> From: Pete Wright In-Reply-To: <20220114181021.6c92db75@archlinux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Jb9Rc1kngz3j5s X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=FZ1UGBJ6; dmarc=pass (policy=quarantine) header.from=nomadlogic.org; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; DKIM_TRACE(0.00)[nomadlogic.org:+]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; MLMMJ_DEST(0.00)[questions]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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