From owner-freebsd-hackers@freebsd.org Tue Dec 8 19:46:53 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 25ECF9D425B for ; Tue, 8 Dec 2015 19:46:53 +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 E0185162B for ; Tue, 8 Dec 2015 19:46:52 +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 6B97AD7FA; Tue, 8 Dec 2015 19:46:51 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 0AFE1482F6; Tue, 8 Dec 2015 20:46:50 +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> Date: Tue, 08 Dec 2015 20:46:50 +0100 In-Reply-To: (Warner Losh's message of "Tue, 8 Dec 2015 12:34:16 -0700") Message-ID: <868u54radx.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 19:46:53 -0000 Warner Losh writes: > Dag-Erling Sm=C3=B8rgrav writes: > > My point is that it's wrong to infer anything else from > > GEOM::candelete than the fact that BIO_DELETE requests will be > > accepted and may or may not do something, somewhere, at some point. > > We can easily create a different GEOM attribute which indicates that > > seeks are essentially free, and FFS could use that instead of > > GEOM::candelete to disable relocation. > When this was implemented, we thought about that. But we couldn't come > up with any cases where you'd have one set and not the other. And the > actual thing you'd want isn't that seeks are free, though that's a > good clue. The actual thing you want is to know if there's a > performance benefit to keeping files contiguous, and the extent size > where that stops making sense. I'm having a hard time understanding how the fact that seeks are essentially free is *not* a good indication that there is no benefit to keeping files contiguous, since keeping files contiguous is something we do to avoid the cost of seeking. Support for deletion, on the other hand, is *completely* orthogonal. And my example was not taken entirely out of the blue: I'm sure there would be a huge market for storage devices, whether electromechanical or solid-state, which implemented this in hardware, along with guarantees that reallocated sectors are truly non-recoverable. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no