From owner-svn-src-head@freebsd.org Thu Aug 18 21:39:45 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 CA62ABBFB40; Thu, 18 Aug 2016 21:39:45 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 94FD61531; Thu, 18 Aug 2016 21:39:45 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 8F008358C5F; Thu, 18 Aug 2016 23:39:42 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 48E8228494; Thu, 18 Aug 2016 23:39:42 +0200 (CEST) Date: Thu, 18 Aug 2016 23:39:42 +0200 From: Jilles Tjoelker To: Konstantin Belousov Cc: Konstantin Belousov , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r304176 - in head: include lib/libc/sys sys/compat/freebsd32 sys/kern Message-ID: <20160818213941.GA1539@stack.nl> References: <201608151908.u7FJ8phh091939@repo.freebsd.org> <20160817202040.GA21263@stack.nl> <20160818075316.GW83214@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160818075316.GW83214@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Thu, 18 Aug 2016 21:39:45 -0000 On Thu, Aug 18, 2016 at 10:53:16AM +0300, Konstantin Belousov wrote: > On Wed, Aug 17, 2016 at 10:20:40PM +0200, Jilles Tjoelker wrote: > > On Mon, Aug 15, 2016 at 07:08:51PM +0000, Konstantin Belousov wrote: > > > /* ISO/IEC 9945-1: 1996 */ > > > #if __POSIX_VISIBLE >= 199506 || __XSI_VISIBLE > > > int fsync(int); > > > +int fdatasync(int); > > > > > > /* > > > * ftruncate() was in the POSIX Realtime Extension (it's used for shared > > Apparently these functions were added closely enough in time that they > > can stay together here :) > Is this a form of suggestion to use other value for POSIX_VISIBLE ? No, no change is necessary. > > > +#if 0 > > > + if (!fullsync) > > > + /* XXXKIB: compete outstanding aio writes */; > > Under the _POSIX_SYNCHRONIZED_IO option, completing outstanding I/O > > requests is in fact required for fsync() as well. The fdatasync() > > function is completely under the _POSIX_SYNCHRONIZED_IO option. > > We do not implement this option, but keeping fdatasync()'s guarantees a > > subset of fsync()'s guarantees seems sensible. > I will consider this if and when the AIO flush would be implemented. > I looked at the AIO code to estimate the needed work, but did not started > coding and quite possible it would be postponed. OK. > > > +%% fdatasync vp L L L > > > + > > > +vop_fdatasync { > > > + IN struct vnode *vp; > > > + IN struct thread *td; > > > +}; > > A waitfor parameter like in vop_fsync may be useful to implement > > aio_fsync(O_DSYNC) later on. > I really do not see how would it be. aio_fsync(O_DSYNC) is equivalent > to fdatasync(2) in the async context. Completion of the aio request > indicates that virtual fdatasync(2) execution did finished in that > context. The use of waitfor in the VOP_FSYNC() is to allow syncer > to initiate flush without waiting, or getting notification for the > completion. > Could you, please, elaborate ? If the KPI change is needed there, it > is obviously desirable to make it right before MFC to stable. Oh, you're right. No change is needed. A MNT_NOWAIT fsync operation does not provide any feedback when it is complete, so it is not useful for AIO. In fact, aio_fsync() eventually calls VOP_FSYNC with MNT_WAIT on a worker thread. -- Jilles Tjoelker