From owner-freebsd-hackers@freebsd.org Tue Dec 8 18:58:28 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 80EEF9D37D4 for ; Tue, 8 Dec 2015 18:58:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F249E1C95 for ; Tue, 8 Dec 2015 18:58:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tB8IwJx3038121 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Dec 2015 20:58:20 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tB8IwJx3038121 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tB8IwImh038095; Tue, 8 Dec 2015 20:58:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Dec 2015 20:58:18 +0200 From: Konstantin Belousov To: Dag-Erling Sm??rgrav Cc: Warner Losh , "freebsd-hackers@freebsd.org" Subject: Re: Fwd: DELETE support in the VOP_STRATEGY(9)? Message-ID: <20151208185818.GD82577@kib.kiev.ua> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86wpsord9l.fsf@desk.des.no> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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 18:58:28 -0000 On Tue, Dec 08, 2015 at 07:44:38PM +0100, Dag-Erling Sm??rgrav wrote: > Warner Losh writes: > > Dag-Erling Sm??rgrav writes: > > > But the filesystem does not know whether the underlying storage is > > > electromechanical or solid-state, nor does it know whether the user > > > cares much about seek times (unless we introduce the heuristic > > > "avoid creating holes unless the file already has them, in which > > > case the userland probably does not care"). > > Actually, the filesystem does know. Or has some knowledge of what > > is supported and what isn't. BIO_DELETE support is a strong indicator > > of a flash or other log-type system. > > 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). I again agree. This is how UFS issues TRIM. When the data block is freed and there are no dandling pointers in the inode copy on disk pointing to the block, BIO_DELETE is issued if volume reports it. Everything else is up to the geom stack and driver. > > Anyway, my point is that Maxim needs to revise his assumptions. Which does not invalidate the fact that a 'punch hole' interface is useful.