From owner-freebsd-hackers@freebsd.org Sat Apr 13 20:33:25 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F34A215828E6 for ; Sat, 13 Apr 2019 20:33:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D77C6AAC8; Sat, 13 Apr 2019 20:33:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x3DKXGD1062633 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Apr 2019 23:33:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x3DKXGD1062633 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x3DKXGMR062632; Sat, 13 Apr 2019 23:33:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 13 Apr 2019 23:33:16 +0300 From: Konstantin Belousov To: Kirk McKusick Cc: Alan Somers , FreeBSD Hackers Subject: Re: When can a struct buf's b_lblkno field by < 0 ? Message-ID: <20190413203316.GM1923@kib.kiev.ua> References: <20190413154340.GJ1923@kib.kiev.ua> <201904131946.x3DJkPIk097337@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201904131946.x3DJkPIk097337@chez.mckusick.com> User-Agent: Mutt/1.11.4 (2019-03-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 20:33:25 -0000 On Sat, Apr 13, 2019 at 12:46:25PM -0700, Kirk McKusick wrote: > > Date: Sat, 13 Apr 2019 18:43:40 +0300 > > From: Konstantin Belousov > > To: Kirk McKusick > > Cc: Alan Somers , > > FreeBSD Hackers > > Subject: Re: When can a struct buf's b_lblkno field by < 0 ? > > > > On Sat, Apr 13, 2019 at 08:23:54AM -0700, Kirk McKusick wrote: > > > >> I don't have much to add to kib's commentary. The change in -r112182 > >> was not meant to have functional change, just reduce indentation and > >> get rid of unnecessary code. The change should have been to > >> (bp->b_lblkno >= 0), but the effect is that if logical data block 0 > >> is in the cache and dirty it will be unnecessarily written. At that > >> time all partial truncations were done synchronously, hence the > >> flushing of all the meta-data. With the additional of journaled soft > >> updates, it became possible to do partial truncations asynchronously. > > > > Do you agree with the statement that the last loop in vtruncbuf() is > > useless ? Its removal could only make a difference for ffs_truncate(), > > and there, I do not think that b(a)write() is enough to ensure that the > > indirect buffers are clean, due to dependencies. > > When running with soft updates, they will ensure that everything happens > in the right order. When running without them, the last loop is needed > to ensure that the file is consistent before the length is set. This > consistency is ensured because we do a bufobj_wwait() after falling out > of the loop which will wait until all the bawrite()s have completed. Then, should this last loop writing out dirty indirect blocks, be done in the filesystem code (or in some vfs_bio.c helper called from filesystem code) only when needed, instead of being placed in vtruncbuf() ?