From owner-freebsd-hackers@freebsd.org Tue Dec 8 19:29:07 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 6BBE39D5496 for ; Tue, 8 Dec 2015 19:29:07 +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 3082C1170 for ; Tue, 8 Dec 2015 19:29:07 +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 6FF3BD7A6; Tue, 8 Dec 2015 19:29:06 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 04828482F2; Tue, 8 Dec 2015 20:29:05 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Warner Losh Cc: Steven Hartland , freebsd-hackers@freebsd.org 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> Date: Tue, 08 Dec 2015 20:29:04 +0100 In-Reply-To: <0DB97CBA-4DC3-4D52-AE9D-54546292D66F@bsdimp.com> (Warner Losh's message of "Tue, 8 Dec 2015 12:03:11 -0700") Message-ID: <86d1ugrb7j.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:29:07 -0000 Warner Losh writes: > Dag-Erling Sm=C3=B8rgrav writes: > > The filesystem can ask the layer below if BIO_DELETE is supported, but > > should not assume anything about what it means. For instance, I could > > write a gnop-like module that translates BIO_DELETE into an all-zeroes > > BIO_WRITE and passes everything else unmodified. It would provide a > > stronger guarantee than, say, SATA TRIM but would also have a completely > > different performance profile (even on SSDs, since it would do its work > > synchronously whereas TRIM works asynchronously). > That ship has sailed. UFS, at least, assumes that if TRIM is supported > then relocating files to be contiguous is bad. But writing a gnop > module that did the BIO_DELETE thing would be bogus. No less bogus than any other implementation of BIO_DELETE. I could write a gnop-like module that silently discards them. My point is that it's wrong to infer anything else from GEOM::candelete support 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. > BIO_DELETE does not mean that blocks will read back as zeros. It doesn't mean they won't, either. > So, sure you could invent a stupid thing that breaks the rules, and > thus the assumptions of the other code, but why would you want to do > that? It wouldn't break any rules or valid assumptions. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no