Date: Wed, 17 Aug 2016 11:10:55 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> 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> In-Reply-To: <20160816215355.GB12199@stack.nl> References: <201608151922.u7FJMOmT099410@repo.freebsd.org> <20160816215355.GB12199@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160817081055.GM83214>