Date: Fri, 19 Feb 2016 20:31:53 -0600 From: Eric van Gyzen <vangyzen@FreeBSD.org> To: Bryan Drewery <bdrewery@FreeBSD.org>, Stefan Esser <se@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, dwmalone@FreeBSD.org Subject: Re: svn commit: r295800 - head/usr.bin/cap_mkdb Message-ID: <56C7D019.3020807@FreeBSD.org> In-Reply-To: <56C7B60E.8080002@FreeBSD.org> References: <201602190842.u1J8gDOc015177@repo.freebsd.org> <56C7B60E.8080002@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/19/16 6:40 PM, Bryan Drewery wrote: > On 2/19/2016 12:42 AM, Stefan Esser wrote: >> Author: se >> Date: Fri Feb 19 08:42:13 2016 >> New Revision: 295800 >> URL: https://svnweb.freebsd.org/changeset/base/295800 >> >> Log: >> Remove O_SYNC from the options passed to dbmopen(). > Uh, this is a full revert of r293312's changes to cap_mkdb which were > made for good reason. So this seems simply wrong without a better fix. > >> >> The output file is created as a temporary file that is moved over the >> existing file after completion. Thus there is no need to immediately >> flush all created db records to the temporary file. > This is not right either. Depending on the use of soft updates / > journaling the data and metadata (file name / rename) may be written at > different times. It is entirely possible to get a renamed file with no > or junk content without an fsync. That's exactly what r293312 mentions > in its commit message. dwmalone@ plans to put the fsync() in the db close method, which makes a lot of sense, and would fix this in a better way. https://reviews.freebsd.org/D5186 This commit probably should have waited for D5186 to be committed, but at least that seems imminent. Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56C7D019.3020807>