From owner-svn-src-head@freebsd.org Wed Aug 17 08:11:01 2016 Return-Path: Delivered-To: svn-src-head@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 F080DBBC63A; Wed, 17 Aug 2016 08:11:00 +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 6AC501EB6; Wed, 17 Aug 2016 08:11:00 +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 u7H8AtKg097120 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Aug 2016 11:10:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7H8AtKg097120 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7H8AtER097113; Wed, 17 Aug 2016 11:10:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 17 Aug 2016 11:10:55 +0300 From: Konstantin Belousov To: Jilles Tjoelker Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r304180 - head/sys/ufs/ffs Message-ID: <20160817081055.GM83214@kib.kiev.ua> References: <201608151922.u7FJMOmT099410@repo.freebsd.org> <20160816215355.GB12199@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160816215355.GB12199@stack.nl> User-Agent: Mutt/1.6.1 (2016-04-27) 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: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 08:11:01 -0000 On Tue, Aug 16, 2016 at 11:53:55PM +0200, Jilles Tjoelker wrote: > Hmm, some people interpret POSIX differently than I do, but I think it > is clear that XBD 3.384 Synchronized I/O Data Integrity Completion > requires the indirect blocks to be written (because "all file system > information required to retrieve the data is successfully transferred"). > The Linux man page matches this interpretation except that an fsync of > the parent directory may be required. > > If the whole file is being considered, then any change to indirect > blocks is needed to access some data (because the file was extended, a > hole was filled or snapshotted data was overwritten). For other > overwrites, there is no change to indirect blocks and no conflict with > fdatasync's performance objectives. Note that the same argument is applicable to the inode block: the di_db and di_ib pointers to the direct blocks and to root indirect blocks are required to retrieve the written data. ... > Ideally, a changed i_size would also cause the inode to be written, but > I don't know how to determine that (there is no i_flag for it). Always > writing the inode would defeat the point of fdatasync. Which was my reasoning behind omitting the indirect block flushing. There is no practical difference between inode block and indirect blocks for metadata consistency. Note that the affected case is only the async mounts (not sync mounts, not any variants of softdeps). I can restore indirect block flushing and wait for them for DATA_ONLY sync, but then I should also add ffs_update() call.