From owner-freebsd-hackers@freebsd.org Tue Dec 8 19:06: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 EB4429D40D0 for ; Tue, 8 Dec 2015 19:06: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 831F21866 for ; Tue, 8 Dec 2015 19:06:28 +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 tB8J6Mmo090469 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 Dec 2015 21:06:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tB8J6Mmo090469 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tB8J6MdI090468; Tue, 8 Dec 2015 21:06:22 +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 21:06:22 +0200 From: Konstantin Belousov To: Dag-Erling Sm??rgrav Cc: "freebsd-hackers@freebsd.org" Subject: Re: Fwd: DELETE support in the VOP_STRATEGY(9)? Message-ID: <20151208190622.GE82577@kib.kiev.ua> References: <86poyhqsdh.fsf@desk.des.no> <86fuzdqjwn.fsf@desk.des.no> <864mfssxgt.fsf@desk.des.no> <86wpsord9l.fsf@desk.des.no> <20151208185818.GD82577@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151208185818.GD82577@kib.kiev.ua> 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 19:06:29 -0000 On Tue, Dec 08, 2015 at 08:58:18PM +0200, Konstantin Belousov wrote: > 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. I am sorry for the followup mail, but I probably have to explain more. The freed block, for which BIO_DELETE is issued, is not marked as free in the bitmap, until the BIO_DELETE completion is reported. In other words, we do not reuse the freed block while TRIM command is possibly executed.