Date: Tue, 08 Dec 2015 21:13:09 +0100 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-hackers\@freebsd.org" <freebsd-hackers@freebsd.org>, Steven Hartland <killing@multiplay.co.uk> Subject: Re: DELETE support in the VOP_STRATEGY(9)? Message-ID: <86wpsopulm.fsf@desk.des.no> In-Reply-To: <E7F0EECA-724C-4595-AB4A-96E29EF6871B@bsdimp.com> (Warner Losh's message of "Tue, 8 Dec 2015 12:58:49 -0700") References: <CAH7qZftSVAYPmxNCQy=VVRj79AW7z9ade-0iogv2COfo2x%2Ba2Q@mail.gmail.com> <201512052002.tB5K2ZEA026540@chez.mckusick.com> <CAH7qZfs6ksE%2BQTMFFLYxY0PNE4hzn=D5skzQ91=gGK2xvndkfw@mail.gmail.com> <86poyhqsdh.fsf@desk.des.no> <CAH7qZftVj9m_yob=AbAQA7fh8yG-VLgM7H0skW3eX_S%2Bv75E-g@mail.gmail.com> <86fuzdqjwn.fsf@desk.des.no> <CANCZdfo=NfKy51%2B64-F_v%2BDh2wkrFYP4gXe=X9RWSSao49gO9g@mail.gmail.com> <CANCZdfqHoduhdCss0b6=UsBPAxfRZv4hF8vyuUVLBdP5gYUduQ@mail.gmail.com> <864mfssxgt.fsf@desk.des.no> <CANCZdfoXdcD%2B9jeVR1Np16gafBf0_4B2wombwxze8DvJwf7cMg@mail.gmail.com> <86wpsord9l.fsf@desk.des.no> <566726ED.2010709@multiplay.co.uk> <0DB97CBA-4DC3-4D52-AE9D-54546292D66F@bsdimp.com> <86d1ugrb7j.fsf@desk.des.no> <CANCZdfrgkA-znp8jL%2BfDgkXwaTSBeNJVTXj6mDKQxdYtht3uzA@mail.gmail.com> <868u54radx.fsf@desk.des.no> <E7F0EECA-724C-4595-AB4A-96E29EF6871B@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh <imp@bsdimp.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86wpsopulm.fsf>