From owner-freebsd-hackers@freebsd.org Tue Dec 8 19:34:19 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 61F669D596C for ; Tue, 8 Dec 2015 19:34:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16DE11A36 for ; Tue, 8 Dec 2015 19:34:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgea14 with SMTP id a14so32894472qge.0 for ; Tue, 08 Dec 2015 11:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Geih0qs8+eAA3NOc4DAgbLBl9st7wVqpt7uYgzrKBL4=; b=G1TrzZ7Qma25GJO/h2RN20nECRlqlLxear9cqZbseHb64YSX0nx7x+dRZofvTMSKah rBl7j7REh4r8YN9mYI49yG+R0cw5iX/Nlvf2tqKk/roGG5gS44WJsME6qyUgXRyfEpgV Gvh465147jQNHW6goI8Pko3Tgi2YxGpBCcDP4aKw7PeMKGi1Gj3hwUc2Xswzs4qdO0EP 3zRJQNloNN3d/l4OKcBct1sXk7l3T7xzGLQa8MvJNU4Ut9vaZz9wVByiWVlXw3QM0Z4I nXvRuWJhX9ugDKiLTTnQSmu62HcGdNO4moPKI2mbSSZu7D096ZE8y9yyB9mQrvgPDcTq 2bPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Geih0qs8+eAA3NOc4DAgbLBl9st7wVqpt7uYgzrKBL4=; b=G2CLInr9zKXa+R2D3U/e299bWL6daGFDEj0nqD0toNPlpqJ0kfiH9dYL+WX4YMHFwc p21QRngbUYV2st1Piu8NyI4pAhB9CnwDTGU6dUspjJ6ljelSm1pbWFyc5mDnf2iKHLjA VIiF34PblHluU40gm/aqveIDuCEl6w8kF777IHswwVnWUBl3xBiVX6U1z9f9DBaJYD9P 5a47MmGOE0eobuk00VpmKhVDkzj69k1RE9fhYnjFRrc6zy9w/WW92A0B4wjHFbYPaO4o /0gtqAiQt7BObxUdl0isZj6F+GVPUMocyasq5p7XSJY5SFvBQztp7jCO+mF0nZY9HRrc /Tdw== X-Gm-Message-State: ALoCoQlQeg20Tw5BCLEIHq510gV/7WKAFYDRL/glokeaFWRREnmGmNXROcW53a8x2L4uH5nZypmkJuaOH5sx3+JeNMF6McxzlA== MIME-Version: 1.0 X-Received: by 10.140.19.78 with SMTP id 72mr1836090qgg.81.1449603256846; Tue, 08 Dec 2015 11:34:16 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Tue, 8 Dec 2015 11:34:16 -0800 (PST) X-Originating-IP: [2601:280:4900:3700:4d3f:8eba:ea86:7700] In-Reply-To: <86d1ugrb7j.fsf@desk.des.no> 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, 8 Dec 2015 12:34:16 -0700 X-Google-Sender-Auth: UAzj1RRCaEsQO2nM372NHDSGq8g Message-ID: Subject: Re: DELETE support in the VOP_STRATEGY(9)? From: Warner Losh To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Cc: Steven Hartland , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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:34:19 -0000 On Tue, Dec 8, 2015 at 12:29 PM, Dag-Erling Sm=C3=B8rgrav wrot= e: > Warner Losh writes: > > Dag-Erling Sm=C3=B8rgrav writes: > > > The filesystem can ask the layer below if BIO_DELETE is supported, bu= t > > > should not assume anything about what it means. For instance, I coul= d > > > write a gnop-like module that translates BIO_DELETE into an all-zeroe= s > > > 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 wo= rk > > > 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. 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. > > > 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. Actually, I'm wrong here. You are correct. I got carried away a bit. Sorry. Warner