From owner-freebsd-hackers@freebsd.org Tue Dec 8 20:13:12 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D73E99D3ABC for ; Tue, 8 Dec 2015 20:13:12 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9C8D81D81 for ; Tue, 8 Dec 2015 20:13:12 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 97549D85B; Tue, 8 Dec 2015 20:13:11 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 856A5482FD; Tue, 8 Dec 2015 21:13:09 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Warner Losh Cc: "freebsd-hackers\@freebsd.org" , Steven Hartland Subject: Re: DELETE support in the VOP_STRATEGY(9)? References: <201512052002.tB5K2ZEA026540@chez.mckusick.com> <86poyhqsdh.fsf@desk.des.no> <86fuzdqjwn.fsf@desk.des.no> <864mfssxgt.fsf@desk.des.no> <86wpsord9l.fsf@desk.des.no> <566726ED.2010709@multiplay.co.uk> <0DB97CBA-4DC3-4D52-AE9D-54546292D66F@bsdimp.com> <86d1ugrb7j.fsf@desk.des.no> <868u54radx.fsf@desk.des.no> Date: Tue, 08 Dec 2015 21:13:09 +0100 In-Reply-To: (Warner Losh's message of "Tue, 8 Dec 2015 12:58:49 -0700") Message-ID: <86wpsopulm.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 20:13:12 -0000 Warner Losh writes: > And to be fair, having an additional property of =E2=80=98seeks are nearly > free=E2=80=99 would also be a good way to tell. I=E2=80=99m not convinced= it is worth > the effort to add it to all the storage devices in the tree when > GEOM::candelete is a good proxy. I just provided you with an (admittedly fictional, but not unreasonable) example of a layer which implements BIO_DELETE on top of storage that may or may not have free seeks. The two are completely orthogonal; they just happen to be strongly correlated on currently available hardware. Note that my fictional example would guarantee that BIO_DELETEd space reads back as zeroes, even if the request doesn't align with physical block boundaries. Sounds pretty useful to me, even if it doesn't guarantee that the deleted data cannot be recovered from the physical media by a sufficiently determined attacker with access to liquid nitrogen and an electron microscope. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no